Logging per agenti AI: cosa registrare prima di un incidente

Un agente di assistenza clienti invia a una persona il listino riservato di un'altra azienda. Per capire che cosa è successo servono i log, cioè i registri delle operazioni: quale versione del sistema era attiva, quali dati ha letto, chi ha autorizzato l'invio e quale risultato ha confermato il servizio di posta.

Per iniziare, scegli una sola operazione e chiedi a chi gestisce i log di ricostruirla: richiesta, autorizzazione, chiamata e risultato confermato. I log sono registri degli eventi; il trace collega gli eventi di una stessa esecuzione.

Il collegamento fra questi eventi permette di ricostruire la sequenza. Conservare l'intera conversazione, invece, può aggiungere dati personali senza dare le informazioni necessarie su permessi e invio. La guida mostra quali informazioni cercare e come provarne l'utilità.

Cosa registrare, e cosa lasciare fuori

Devi poter ricostruire le operazioni conservando solo i dati necessari. Il GDPR richiede che dati e durata della conservazione siano adeguati alla finalità. DORA impone alle entità finanziarie processi di gestione e comunicazione degli incidenti, che il fornitore può dover supportare per contratto. Nessuna delle due norme chiede di conservare tutto. La guida AI Act e DORA distingue gli obblighi del cliente dalle prove richieste al fornitore.

Parti dall'azione: registra, per esempio, che l'agente ha interrogato Salesforce, con quali permessi e con quale esito. Il contenuto completo scambiato con il servizio, spesso chiamato payload, può contenere dati personali o informazioni commerciali. Conservalo soltanto per una finalità precisa, rimuovi i dati non necessari e limita chi può leggerlo.

OpenTelemetry è uno standard aperto per registrare l'attività dei sistemi. Un trace raggruppa una sequenza di operazioni; uno span descrive una singola operazione. I suoi eventi appartengono allo span e non hanno automaticamente una durata di conservazione diversa. Per contenuti con accessi e cancellazione propri, usa un archivio separato e collega il record al trace mediante un identificativo. Verifica la cancellazione nel sistema reale.

Nove gruppi di informazioni da cui partire

Adatta questi nove gruppi alle domande a cui la procedura di gestione degli incidenti deve rispondere. Chi mantiene il sistema deve verificare quali campi tecnici permettono di raccoglierli.

Timestamp normalizzato. Usa ISO 8601, conserva offset o UTC e mantieni la precisione necessaria a ordinare gli eventi. Il punto è correlare sistemi diversi senza ambiguità.

Agente e versioni. Registra identificativo dell'agente, modello, istruzioni, strumenti e configurazione. L'hash è un'impronta che permette di riconoscere un contenuto: quello del solo prompt non identifica tutto il sistema.

Trace ID + span ID + parent span ID. Gli identificativi collegano le operazioni: esecuzione complessiva, passaggio corrente e passaggio che lo ha avviato. Servono anche quando vengono chiamati altri agenti.

Strumento e permessi. Registra il nome dello strumento chiamato e le azioni e risorse effettivamente consentite, spesso indicate come scope. Devi poter verificare se l'agente avesse il permesso di eseguire proprio quell'azione in quel momento. La guida ai permessi minimi mostra come limitarli e provarli.

Riferimento al contenuto ricevuto. L'hash dell'ingresso consente di confrontarlo con una copia disponibile e verificarne l'integrità. Aggiungi un riepilogo senza dati superflui, per esempio «email del cliente di 850 caratteri, contiene nomi di persone». Se serve il testo completo, collegalo all'archivio con accessi e cancellazione indipendenti descritto sopra.

Riferimento al risultato. Registra anche l'hash del contenuto prodotto e un riepilogo senza dati superflui. Applica al risultato gli stessi criteri di necessità, accesso e cancellazione usati per il contenuto ricevuto.

Motivo dell'azione. Conserva la regola o il codice che spiega perché il sistema ha scelto quello strumento e autorizzato l'operazione. Il ragionamento interno del modello, detto chain of thought, può non essere disponibile e non è un registro stabile: può inoltre contenere dati che non servono alla ricostruzione.

Esito e durata. Registra successo, errore o interruzione per tempo scaduto, insieme alla durata in millisecondi.

Approvazione umana. Se l'azione richiedeva una conferma, registra chi l'ha data e quando. Se l'azione è partita senza attraversare il controllo previsto, segnala il fatto e l'eventuale causa nota.

Una sequenza da ricostruire

In una prova con dati fittizi, il modello propone di inviare un listino. Il sistema autorizza soltanto il cliente A, lo strumento invia il documento e il servizio esterno conferma la presa in carico. Registra proposta, autorizzazione e conferma separatamente. Se una risposta HTTP 200 non conferma l'esito finale, segna quell'esito come sconosciuto, senza dedurre la consegna. Ripeti con un destinatario vietato: l'invio deve essere negato e registrato.

Queste informazioni sono un punto di partenza. Misurane il volume sul tuo traffico e prova a ricostruire un incidente simulato: la prova mostra che cosa manca e che cosa puoi evitare di raccogliere. Il semplice elenco dei campi non dimostra la conformità del sistema.

Dove conservare i registri e chi può leggerli

Per l'archivio dei registri servono tre decisioni esplicite.

Cifratura e gestione delle chiavi. Usa la cifratura offerta dalla piattaforma e separa chiavi, permessi e dati. Il controllo utile non è scrivere “AES-256” in una policy: è provare chi può decifrare i log, come ruotano le chiavi e cosa succede quando revochi un accesso.

Integrità e manomissione rilevabile. Per i log usati come evidenza, impedisci o rendi rilevabili modifiche e cancellazioni non autorizzate. Append-only, firme, hash chain o object lock sono opzioni diverse: scegli in base a minaccia, obblighi e costo, poi testa il recupero.

Indicizzato per le domande reali. Durante un incidente, un log che non riesci a interrogare in tempo è presente ma poco operativo. Parti da trace ID, agent ID, timestamp e tool name, poi prova una ricostruzione come “tutte le azioni dell'agente in questa finestra”. Misura il tempo e fissalo in base al processo di risposta.

Il costo dipende da volume, payload, retention, replica e motore di ricerca. Fai un test su traffico reale e metti un alert di spesa: senza questi dati qualsiasi cifra “da PMI” è solo una supposizione.

Tempi di conservazione diversi per dati diversi

Il GDPR richiede di limitare dati e tempi di conservazione. Per un cliente finanziario, il contratto può anche chiedere al fornitore di conservare prove utili alla gestione degli incidenti DORA. Devi motivare la durata sul caso concreto: queste norme non forniscono un numero valido per ogni registro.

Una soluzione pratica è separare quattro categorie, ciascuna con i propri accessi e tempi di cancellazione.

1. Identificativi ed esiti delle operazioni. Conserva quelli necessari per il periodo documentato. Anche un identificativo può essere un dato personale: verifica se consente di risalire a una persona.

2. Riepiloghi senza dati superflui. Se richiedono una durata diversa, usa un archivio con cancellazione indipendente. Aggiungere un evento allo stesso span non crea da solo questa separazione. Prova sia la rimozione dei dati sia la cancellazione alla scadenza.

3. Contenuti completi per cercare un errore. Limita gli accessi e conserva i testi per il tempo più breve giustificato dalla necessità reale. Se bastano un hash, un valore fittizio riconoscibile usato nei test o un riepilogo, evita di conservare il contenuto completo.

4. Conversazioni complete per addestramento o valutazione. Evita di raccoglierle automaticamente. Se sono necessarie, definisci base giuridica, informativa, accessi, durata e diritti di opposizione o revoca dove applicabili. Il consenso è una possibilità, non una formula universale.

Questa separazione permette a chi gestisce sicurezza, privacy e contratti di valutare gli stessi dati e le stesse necessità. La guida alla sicurezza agentica per le PMI collega i registri agli altri controlli del sistema.

Un obiettivo operativo per la prima ora

Nella prima ora potresti non conoscere ancora la causa. L'obiettivo è fermare il danno, conservare le prove disponibili e assegnare una persona che decida i passi successivi. Le scadenze legali restano distinte.

1. Ferma il danno e annota l'intervento. Secondo il caso, sospendi l'agente, revoca una credenziale o isola uno strumento. Registra chi ha fatto cosa e quando. Conserva copie della configurazione e registri quando è sicuro farlo; un accesso compromesso va comunque disattivato senza aspettare una fotografia perfetta del sistema.

2. Raccogli le prove disponibili. Identifica l'intervallo dell'incidente, le esecuzioni e le identità coinvolte. Salva configurazione, documenti recuperati, chiamate agli strumenti e risultati disponibili, senza cercare un ragionamento interno del modello che potresti non avere. Separa i fatti osservati dalle ipotesi sulla causa. MITRE ATLAS, un catalogo di tecniche di attacco ai sistemi AI, può aiutare a classificare il tentativo. Il rapporto sull'incidente deve riportare tempi, gravità, sistemi, interventi, impatto noto, informazioni mancanti e prossime verifiche.

3. Assegna i passi successivi. Stabilisci chi conduce l'analisi, quali altre misure di contenimento servono e quali comunicazioni vanno valutate. Se l'organizzazione è un'entità finanziaria, attiva il processo DORA applicabile; se sono coinvolti dati personali, valuta l'articolo 33 GDPR. Coinvolgi chi deve decidere anche quando la causa non è ancora chiara.

Alla fine dei primi 60 minuti dovresti avere un danno contenuto per quanto possibile, prove conservate, una persona responsabile e una prima ipotesi da verificare. Registri utili permettono di cominciare dai fatti disponibili.

Il logging paga quando risponde a una domanda

Il criterio che userei per valutare i log è una ricostruzione concreta: quale versione, quale strumento, quali permessi, quale risultato e chi ha approvato. Prova a rispondere senza aprire conversazioni complete. Togli i dati che non servono e verifica la cancellazione prevista. Le evidenze possono supportare sicurezza, privacy e impegni contrattuali, che mantengono requisiti distinti.

Per applicare queste verifiche al tuo caso, porta descrizione del flusso, permessi e risultati delle prove al servizio di controllo e sicurezza degli agenti AI. Partiamo dalla prima lacuna concreta e definiamo come verificarne la correzione.