Quando un agente AI agisce nei processi aziendali, bisogna poter ricostruire chi ha deciso cosa, su quali dati e con quale esito. Un buon registro di audit annota attore, input, output, decisione, versione di modello e prompt, costo e risultato, in forma non alterabile. Va progettato insieme al GDPR (General Data Protection Regulation), che chiede di conservare il minimo indispensabile, e tenendo conto di cosa prevede l'AI Act.
Risposta breve
Un registro di audit per l’AI è l’elenco cronologico e non alterabile di ciò che fa un agente AI: chi ha agito, su quali dati, con quale risultato, chi ha approvato, con quale versione di modello e prompt. Serve a ricostruire le decisioni contestate e a dimostrare la conformità al GDPR. Per i sistemi ad alto rischio l’AI Act rende i log obbligatori.
Perché un agente AI ha bisogno di un registro
Un software tradizionale fa sempre la stessa cosa con lo stesso input. Un agente AI no. Usa un LLM (Large Language Model, modello linguistico di grandi dimensioni) che interpreta testi, sceglie quali strumenti usare e produce risposte che possono variare anche a parità di richiesta. Il comportamento dipende dal modello, dalle istruzioni ricevute (il prompt), dai dati letti in quel momento e dalle regole di autonomia.
Se tre mesi dopo un cliente contesta una risposta, o un revisore chiede perché una pratica è stata approvata, il codice non basta a spiegarlo. Serve la registrazione di quello specifico episodio: cosa è entrato, cosa è uscito, chi ha approvato.
La tracciabilità è quindi un requisito di prodotto, come la sicurezza degli accessi: senza registro, un sistema di agenti AI è difficile da correggere, difendere e migliorare. Il registro serve anche a dare sostanza al controllo umano: se una persona approva le azioni dell’agente, il registro dimostra quando e su quali basi lo ha fatto. Sul tema vedi anche Human in the loop: quanta autonomia dare a un agente AI.
Registro di audit per l’AI: cosa registrare
Non esiste un formato unico obbligatorio, ma c’è un nucleo di informazioni senza le quali la ricostruzione è incompleta. La tabella è un modello riusabile.
| Campo | Cosa contiene | Perché serve |
|---|---|---|
| Identificativo e marca temporale | Codice univoco dell’evento, data e ora | Ordinare gli eventi e citarli senza ambiguità |
| Attore | Persona (con ruolo) o agente (con nome e configurazione) | Distinguere ciò che ha fatto il sistema da ciò che ha fatto una persona |
| Processo e pratica | Processo, fase, riferimento alla pratica o al ticket | Collegare l’evento al contesto di business |
| Input | I dati ricevuti, o un riferimento sicuro a essi | Capire su quali informazioni si è basata l’azione |
| Output | La risposta o l’azione prodotta | Sapere cosa è stato generato |
| Decisione | Approvato, modificato, respinto, eseguito in autonomia; da chi | Ricostruire la catena di responsabilità |
| Versione del modello | Fornitore, modello, versione | Spiegare differenze di comportamento nel tempo |
| Versione del prompt e delle regole | Identificativo delle istruzioni e delle soglie in vigore | Sapere con quali regole lavorava l’agente |
| Strumenti usati | Sistemi interrogati o modificati (gestionale, posta, CRM, Customer Relationship Management) | Tracciare gli effetti sui sistemi aziendali |
| Costo | Token consumati o costo stimato della chiamata | Controllare la spesa e calcolare il rendimento |
| Esito | Completato, errore, escalation, annullato | Misurare la qualità e individuare i punti deboli |
Due accorgimenti rendono il modello più robusto.
Separare i metadati dai contenuti. I metadati (chi, quando, quale versione, quale esito) sono leggeri e utili a lungo. I contenuti (il testo di un’email, un allegato) spesso contengono dati personali: conviene conservarli in un archivio distinto, con regole proprie, collegato al registro da un riferimento.
Versionare prompt e configurazioni. Le istruzioni dell’agente vanno gestite come il codice: con versioni, data di entrata in vigore e autore della modifica. Altrimenti il campo “versione del prompt” non dice nulla.
Rendere il registro non alterabile: la catena di hash
Un registro è utile in una contestazione solo se si può dimostrare che non è stato modificato dopo i fatti. Lo strumento è la catena di hash.
Un hash è un’impronta digitale di un testo. Una funzione crittografica, per esempio SHA-256 (Secure Hash Algorithm), trasforma qualsiasi contenuto in una stringa di lunghezza fissa; basta cambiare una virgola perché l’impronta cambi completamente.
Una catena di hash è una sequenza di impronte in cui ognuna incorpora la precedente. Funziona così:
- Si calcola l’impronta del primo evento registrato.
- Per il secondo evento si calcola l’impronta del suo contenuto più l’impronta del primo.
- Per il terzo si usa l’impronta del secondo, e così via.
Ogni riga porta con sé la memoria delle precedenti. Se qualcuno modifica un evento passato, cambiano la sua impronta e tutte le successive: ricalcolando la catena, la manomissione emerge.
In inglese si dice tamper-evident: il registro non impedisce in assoluto la modifica, ma la rende evidente. Due misure rafforzano la garanzia:
- Ancoraggio periodico. A intervalli regolari si salva l’ultima impronta in un luogo indipendente: un archivio separato o una marca temporale rilasciata da un prestatore qualificato.
- Scrittura in sola aggiunta. Si possono aggiungere righe, non modificarle; le correzioni sono nuovi eventi che rimandano a quello corretto.
Non serve una blockchain: nella maggior parte dei contesti aziendali basta una catena di hash ben implementata, con ancoraggi e permessi di scrittura limitati.
Conservazione e minimizzazione: il compromesso con il GDPR
Per ricostruire gli eventi si vorrebbe conservare tutto, a lungo. Il GDPR chiede invece di trattare solo i dati adeguati, pertinenti e limitati a quanto necessario (art. 5, par. 1, lett. c) e di conservarli in forma identificabile non oltre il tempo necessario (art. 5, par. 1, lett. e) (GDPR). Allo stesso tempo, lo stesso regolamento chiede al titolare di essere in grado di dimostrare la conformità (art. 5, par. 2): e il registro è proprio uno strumento di dimostrazione.
La tensione si risolve con la progettazione, coerentemente con il principio di protezione dei dati fin dalla progettazione (art. 25).
- Tempi diversi per livelli diversi. I metadati possono restare più a lungo; i contenuti con dati personali si conservano per il tempo legato alla finalità, poi si cancellano o si riducono.
- Pseudonimizzazione nel registro. Al posto del nome di un cliente si registra un codice; la tabella di corrispondenza sta altrove, con accessi ristretti. Attenzione: i dati pseudonimizzati restano dati personali, perché l’identificazione è ancora possibile. Diventano anonimi solo se il collegamento non è più ragionevolmente ricostruibile (considerando 26). Il tema è approfondito in Pseudonimizzazione e modelli linguistici.
- Cancellazione compatibile con la catena. Se si cancella il contenuto di un evento, la catena si rompe. Per questo è utile che la catena includa l’impronta del contenuto, non il contenuto stesso: il contenuto può essere eliminato alla scadenza, mentre la riga del registro e la sua impronta restano verificabili.
- Accessi tracciati. Anche chi consulta il registro lascia una traccia, misura coerente con l’art. 32 del GDPR.
Le scelte su tempi e contenuti vanno documentate e condivise con il DPO (Data Protection Officer, responsabile della protezione dei dati), se nominato. Per un quadro più ampio vedi la pagina Privacy by design.
Cosa dice l’AI Act su tracciabilità e log
Il Regolamento (UE) 2024/1689, noto come AI Act (testo su EUR-Lex), dedica alla tracciabilità norme precise, ma per una categoria specifica: i sistemi ad alto rischio.
- L’art. 12 chiede che i sistemi ad alto rischio consentano tecnicamente la registrazione automatica degli eventi per tutta la loro durata, con log utili a individuare situazioni di rischio, a supportare il monitoraggio successivo all’immissione sul mercato e a sorvegliare il funzionamento.
- L’art. 19 chiede ai fornitori di conservare i log generati automaticamente, se sotto il loro controllo, per un periodo adeguato alla finalità e di almeno sei mesi, salvo diversa disposizione di legge, in particolare in materia di protezione dei dati.
- L’art. 26, par. 6 prevede un obbligo analogo per i deployer, cioè le organizzazioni che usano il sistema.
Dopo il cosiddetto “Digital Omnibus” (Regolamento UE 2026/1744, pubblicato in Gazzetta ufficiale dell’UE il 24 luglio 2026), gli obblighi per i sistemi ad alto rischio dell’Allegato III si applicano dal 2 dicembre 2027 e quelli dell’Allegato I dal 2 agosto 2028 (Reg. UE 2026/1744; Future of Privacy Forum, 2026; Gibson Dunn, 2026). Per il dettaglio delle scadenze vedi AI Act: cosa cambia per chi usa agenti AI nei processi aziendali, scadenza per scadenza.
Va detto con chiarezza: la maggior parte degli agenti AI di back office, per esempio per smistare email o preparare documenti, non è ad alto rischio, e per essi l’AI Act non impone un registro come quello dell’art. 12. Alcuni usi elencati nell’Allegato III, come quelli in materia di occupazione e gestione dei lavoratori o di accesso a servizi essenziali, vanno invece valutati con attenzione e con un consulente.
Perché adottarlo comunque? Il GDPR chiede di dimostrare la conformità per qualsiasi trattamento; un registro ben fatto facilita il passaggio se un uso diventa ad alto rischio; e senza registro non si governa un sistema che prende iniziative.
Il registro alla prova: contestazioni e ispezioni
Contestazione di un cliente. Un cliente sostiene di aver ricevuto un’informazione sbagliata. Dal registro si vede quale fonte ha usato l’agente, con quali istruzioni, e se una persona ha approvato l’invio. Si risponde sui fatti, e si corregge la causa se l’errore c’è stato.
Verifica interna o audit. Un revisore chiede di campionare un gruppo di pratiche gestite dall’agente nel trimestre. Il registro permette di estrarle, mostrare le approvazioni e verificare il rispetto delle soglie di autonomia; la catena di hash dimostra che i dati sono quelli originali.
Ispezione di un’autorità. In un’ispezione privacy, il registro dimostra quali dati sono stati trattati, da chi e per quanto tempo. Un registro minimizzato è anche più facile da esibire.
Una buona pratica è la prova a freddo: scegliere un evento a caso e ricostruirlo per intero in pochi minuti. Per come il registro si inserisce in un’architettura di agenti, vedi la pagina Architettura.
Da ricordare
- Il comportamento di un agente AI dipende da modello, prompt, dati e regole: per ricostruirlo serve un registro degli eventi.
- I campi essenziali sono attore, input, output, decisione, versione di modello e prompt, costo ed esito.
- Una catena di hash con ancoraggi periodici rende evidente ogni modifica successiva ai fatti.
- Metadati e contenuti vanno separati: i contenuti con dati personali seguono tempi brevi e la pseudonimizzazione.
- L’AI Act impone log specifici ai sistemi ad alto rischio; per gli altri il registro resta una buona pratica e un aiuto a dimostrare la conformità al GDPR.
Domande frequenti
Che cos’è un registro di audit per l’intelligenza artificiale?
Un registro di audit per l’intelligenza artificiale è l’elenco cronologico degli eventi prodotti da un sistema di AI, come un agente che smista email o prepara pratiche. Per ogni evento annota chi ha agito, su quali dati, quale risposta o azione è stata prodotta, chi l’ha approvata, con quale versione di modello e di prompt, a quale costo e con quale esito. Serve a ricostruire a posteriori una decisione contestata e a dimostrare come il sistema è governato.
Per quanto tempo vanno conservati i log di un sistema di AI ad alto rischio?
L’AI Act chiede ai fornitori (art. 19) e ai deployer, cioè le organizzazioni che usano il sistema (art. 26, par. 6), di conservare i log generati automaticamente dai sistemi ad alto rischio, se sono sotto il loro controllo, per un periodo adeguato alla finalità e comunque di almeno sei mesi. Restano salve le diverse disposizioni di legge, in particolare quelle sulla protezione dei dati personali.
Da quando si applicano gli obblighi di log dell’AI Act?
Gli obblighi di registrazione e conservazione dei log riguardano i sistemi di AI ad alto rischio. Dopo il Digital Omnibus sull’AI, il Regolamento (UE) 2026/1744 pubblicato nella Gazzetta ufficiale dell’UE il 24 luglio 2026, si applicano dal 2 dicembre 2027 ai sistemi elencati nell’Allegato III e dal 2 agosto 2028 a quelli dell’Allegato I. Le date vanno ricontrollate sui testi ufficiali prima di pianificare gli adeguamenti.
Serve una blockchain per rendere un registro di log non modificabile?
Nella maggior parte dei contesti aziendali no. Basta una catena di hash: ogni evento registrato porta l’impronta crittografica, per esempio SHA-256, del proprio contenuto unita a quella dell’evento precedente, così che ogni modifica successiva diventi evidente. La garanzia si rafforza salvando periodicamente l’ultima impronta in un luogo indipendente, come una marca temporale, e consentendo solo l’aggiunta di righe, mai la loro modifica.
Come si cancellano i dati personali da un registro senza rompere la catena di hash?
Si separano i metadati dai contenuti. La riga del registro conserva chi, quando, quale versione ed esito, insieme all’impronta del contenuto; il contenuto vero e proprio, come il testo di un’email, sta in un archivio distinto con regole proprie. Alla scadenza del periodo di conservazione il contenuto si elimina, mentre la riga e la sua impronta restano verificabili e la catena rimane integra.
I dati pseudonimizzati in un registro di audit sono ancora dati personali?
Sì. Se al posto del nome di un cliente si registra un codice e la tabella di corrispondenza è conservata altrove, l’identificazione resta possibile: per il GDPR sono quindi ancora dati personali. Diventano anonimi solo quando il collegamento con la persona non è più ragionevolmente ricostruibile, come chiarisce il considerando 26. La pseudonimizzazione riduce il rischio, ma non esonera dagli obblighi del regolamento.
Un registro di audit serve anche se l’agente AI non è ad alto rischio?
Sì. La maggior parte degli agenti AI di back office non è ad alto rischio e l’AI Act non impone loro il registro previsto dall’art. 12. Il GDPR però chiede al titolare di saper dimostrare la conformità di ogni trattamento (art. 5, par. 2), e un registro ben progettato è uno strumento di dimostrazione. Aiuta inoltre a rispondere alle contestazioni e semplifica l’adeguamento se un uso diventa ad alto rischio.
Bibliografia e fonti
- Parlamento europeo e Consiglio dell’Unione europea, Regolamento (UE) 2024/1689 che stabilisce regole armonizzate sull’intelligenza artificiale (AI Act), artt. 12, 19 e 26, Gazzetta ufficiale dell’Unione europea, 12/07/2024 (testi degli articoli consultati anche su artificialintelligenceact.eu). https://eur-lex.europa.eu/eli/reg/2024/1689/oj, consultato il 10/10/2026.
- Parlamento europeo e Consiglio dell’Unione europea, Regolamento (UE) 2026/1744 (Digital Omnibus sull’AI), che modifica tra l’altro il Regolamento (UE) 2024/1689, EUR-Lex, adottato l’08/07/2026, pubblicato nella GUUE il 24/07/2026. https://eur-lex.europa.eu/eli/reg/2026/1744/oj, consultato il 10/10/2026.
- Andreea Șerban, Bianca-Ioana Marcu (Future of Privacy Forum), The AI Act Implementation Timeline: What Changes Under the AI Omnibus?, fpf.org, 28/07/2026 (aggiornato il 05/08/2026). https://fpf.org/blog/the-ai-act-implementation-timeline-what-changes-under-the-ai-omnibus, consultato il 10/10/2026.
- Gibson Dunn, EU AI Act Omnibus Agreement — Postponed High-Risk Deadlines and Other Key Changes, gibsondunn.com, 27/05/2026. https://www.gibsondunn.com/eu-ai-act-omnibus-agreement-postponed-high-risk-deadlines-and-other-key-changes/, consultato il 10/10/2026.
- Parlamento europeo e Consiglio dell’Unione europea, Regolamento (UE) 2016/679 (GDPR), art. 5, art. 25, art. 32 e considerando 26, Gazzetta ufficiale dell’Unione europea, 04/05/2016. https://eur-lex.europa.eu/eli/reg/2016/679/oj, consultato il 10/10/2026.
Approfondisci
- AI Act: cosa cambia per chi usa agenti AI nei processi aziendali, scadenza per scadenza: le date di applicazione del regolamento dopo il Digital Omnibus e cosa fare oggi.
- Human in the loop: quanta autonomia dare a un agente AI, e quando: i livelli di autonomia e le approvazioni che il registro deve documentare.
- Pseudonimizzazione e modelli linguistici: usare l’AI senza esporre dati personali: come ridurre i dati personali che arrivano ai modelli e ai registri.
- Privacy by design negli agenti AI: come la protezione dei dati entra nella progettazione dei processi.
- L’architettura di un sistema di agenti AI: dove si collocano registro delle operazioni, modelli e integrazioni.