Dal 30 settembre il giudice può chiedere i parametri della supervisione umana. La vostra piattaforma li registra?
Il D.Lgs. 160/2026 entra in vigore il 30 settembre e dà al giudice il potere di ordinare l'esibizione dei registri del sistema e dei parametri della supervisione umana. Nel frattempo la governance degli agenti passa dall'osservabilità alla provabilità. Due conversazioni separate, messe nella stessa tabella: cosa può essere chiesto in giudizio e quale campo del log risponde.
BlueSky Agent AI ·
Il D.Lgs. 9 settembre 2026 n. 160 è uscito in Gazzetta Ufficiale il 15 settembre ed entra in vigore il 30 settembre 2026. Sul versante civile contiene una frase che riguarda chi gestisce l'infrastruttura, non solo chi firma il modello organizzativo: in giudizio il giudice può ordinare l'esibizione dei registri del sistema, della documentazione di gestione del rischio e dei parametri della supervisione umana.
Nella stessa settimana, il 19 settembre, SiliconANGLE ha descritto uno spostamento che nel mercato anglosassone ha già un nome: dalla observability alla provability. Sapere che un agente ha chiamato un'API non basta più. Serve sapere quale autorità aveva in quel momento.
Sono due conversazioni che in Italia stanno andando avanti separate. Una la fanno gli avvocati, l'altra la fanno gli architetti software. Questo articolo prova a metterle nella stessa tabella: cosa può chiedere un giudice italiano da fine settembre, e quale campo del log risponde a quella richiesta.
Del lato giuridico (reato, modello 231, sanzioni) abbiamo scritto separatamente in D.Lgs. 160/2026: la supervisione umana è una misura di sicurezza. Qui si guarda l'altro lato: il sistema.
Cosa dice il decreto, in tre righe
Il D.Lgs. 160/2026 è il secondo decreto attuativo della legge 132/2025. Introduce un nuovo art. 437-bis del codice penale che punisce l'omissione delle misure tecniche di sicurezza oppure delle misure di supervisione umana previste per un sistema di AI ad alto rischio, quando l'omissione crea pericolo per la vita o l'incolumità delle persone. Pena da uno a cinque anni. L'ente risponde ai sensi del nuovo art. 25-vicies del D.Lgs. 231/2001, con sanzione pecuniaria da 600 a 1.000 quote e sanzioni interdittive.
Sul civile: se il danno deriva dalla violazione di un obbligo dell'AI Act il nesso causale è presunto, salvo prova contraria. La conformità, anche certificata, non funziona come scudo automatico. E il giudice ha il potere di ordinare l'esibizione dei registri.
Una precisazione che raramente si legge negli articoli allarmistici di questi giorni: il 437-bis rinvia agli obblighi previsti per i sistemi ad alto rischio dell'AI Act (Allegato III), e quegli obblighi sono stati spostati al 2027-2028 dal regolamento omnibus. Quando le misure penalmente rilevanti diventino concretamente esigibili è una domanda da porre a un legale, non a noi. Quello che è netto da subito è il resto: responsabilità dell'ente, presunzione del nesso causale, potere di esibizione dei registri.
"Provabilità" è il nome tecnico di quello che il decreto pretende
Il decreto non usa la parola. Ma chiedere i parametri della supervisione umana significa chiedere di dimostrare, dopo, una cosa che è successa prima. In un sistema informativo questa è una proprietà, e ha dei requisiti precisi. SiliconANGLE ne elenca tre.
Autorizzazione contestuale. Non basta sapere che l'agente poteva accedere a un sistema: serve sapere con quale autorità agiva nel momento esatto in cui ha agito, perché i permessi cambiano.
Applicazione della policy. La regola scritta deve essere applicata dal sistema, non ricordata dalle persone. Una policy che vive in un PDF non lascia tracce.
Evidenza verificabile. Il registro deve essere consultabile da qualcuno che non l'ha scritto, e non deve poter essere ricostruito a posteriori.
Il 17 settembre IBM ha pubblicato un intervento tecnico che descrive il livello sotto. Il monitoraggio classico (codici HTTP, tassi d'errore, tempi di risposta) non serve a niente su un sistema multi-agente, perché i guasti sono silenziosi: uno strumento fallisce, l'agente prosegue lo stesso, e la risposta arriva con l'aria di essere corretta. Quello che serve è il tracing distribuito per span, con input, output, conteggio token e latenza a ogni chiamata LLM, a ogni invocazione di strumento, a ogni query. Sopra, un secondo modello che valuta correttezza della chiamata allo strumento, pertinenza, sicurezza e conformità a linee guida scritte in italiano corrente. E un quality gate agganciato alla CI/CD, così che una regressione non arrivi in produzione.
La tabella: richiesta del giudice, campo del sistema
| Cosa può essere chiesto in giudizio | Cosa deve esistere nel sistema |
|---|---|
| Registri del sistema | Log per sessione e per agent, con orario, strumento invocato, esito |
| Parametri della supervisione umana | Quali azioni richiedevano approvazione, chi ha approvato, quando, e cosa vedeva in quel momento |
| Documentazione di gestione del rischio | Configurazione dei guardrail e delle soglie, con lo storico delle modifiche |
| Prova che il sistema applicava la policy | Regole imposte dal software, non affidate alla memoria dell'operatore |
| Autorità dell'agente al momento del fatto | Permessi effettivi di quell'agente in quella data, non i permessi di oggi |
L'ultima riga è quella che più spesso manca. Molte piattaforme sanno dire quali permessi ha un agente adesso. Poche sanno dire quali ne aveva il 14 marzo alle 11:20.
Cosa registra BlueSky Agent AI, e cosa non registra ancora
BlueSky Agent AI nasce come control plane, quindi la parte di registro è dentro il prodotto e non un'aggiunta.
Ogni agent ha i propri log di sessione, interrogabili per agent e non solo per utente, con lo storico delle elaborazioni e il dettaglio di ogni sessione. I ruoli sono tre (Admin, Owner, User) e l'Owner dell'azienda vede analytics e log di sessione di tutti i propri utenti: l'evidenza è consultabile da qualcuno che non l'ha prodotta, che è il requisito di verificabilità.
I guardrail sono configurati per agent e lasciano traccia della configurazione: mascheramento o blocco dei dati personali, rilevamento delle risposte non verificate con soglia di confidenza, rilevamento dei tentativi di aggiramento con soglia propria. La policy è applicata dal software.
Le azioni sensibili richiedono un'autorizzazione esplicita prima di partire, e il motore di autoapprendimento può essere tenuto in modalità "solo report": propone i piani, ognuno con il suo livello di rischio, e li applica solo su approvazione puntuale. È la forma tecnica di quello che il decreto chiama supervisione umana, con la differenza che qui resta scritto chi ha approvato cosa.
Sui permessi, la gerarchia di credenziali è a tre livelli (template dell'agent, singolo agent, utente) e un amministratore può bloccare le sovrascritture ai livelli inferiori. Gli URL dei server di integrazione non sono visibili agli utenti standard.
Va detto anche cosa non c'è. Il tracing distribuito per span nel senso di MLflow, con token e latenza su ogni singola invocazione ricostruibili in un grafico, e la valutazione automatica della conformità con un secondo modello giudice agganciato alla CI/CD, sono strati che oggi non offriamo come funzione di prodotto. Chi vende una piattaforma agentica dicendo che ha già tutto questo in italiano, a settembre 2026, probabilmente sta descrivendo una roadmap. Per il potere di esibizione previsto dal decreto i log di sessione, la configurazione dei guardrail e la traccia delle approvazioni sono quello che serve. Per il debugging fine di uno sciame di agenti, no.
Le tre cose da fare prima del 30 settembre
Non sono compiti da reparto legale, sono compiti da chi tiene i sistemi.
- Fare l'elenco degli agenti attivi e, per ciascuno, scrivere quali azioni può compiere senza chiedere niente a nessuno. Se l'elenco non esiste, è quello il primo problema.
- Verificare che di ogni approvazione umana resti una riga con data, persona e oggetto. Un'approvazione data a voce in riunione, o via chat, non è un parametro esibibile.
- Decidere per quanto tempo i log vengono conservati, e scriverlo. Un registro cancellato dopo trenta giorni non copre un contenzioso che parte a marzo.
In sintesi
- Il D.Lgs. 160/2026 entra in vigore il 30 settembre 2026 e dà al giudice il potere di chiedere registri, documentazione di rischio e parametri della supervisione umana.
- Sul penale il rinvio agli obblighi AI Act per i sistemi ad alto rischio complica i tempi: quella parte va verificata con un legale, non data per scontata.
- La richiesta tecnica corrispondente si chiama provabilità: autorizzazione contestuale, applicazione della policy da parte del software, evidenza verificabile da terzi.
- Il campo che manca più spesso è quale autorità aveva l'agente nel momento del fatto, non quale ha adesso.
- BlueSky Agent AI copre log per agent, configurazione dei guardrail, approvazione esplicita delle azioni sensibili e gerarchia dei permessi. Il tracing per span e il giudizio automatico di conformità non sono ancora funzioni di prodotto, e lo diciamo.