Un agente AI può produrre tre verdetti in un audit: conforme, in violazione oppure, ed è questo il risultato che i sistemi di controllo tradizionali tendono a ignorare, impossibile da determinare. Il problema non è semantico. È ingegneristico. Un controllo bancario è normalmente costruito attorno a una logica binaria: una regola è rispettata oppure è stata violata. Gli agenti autonomi introducono una terza possibilità molto meno confortevole per chi deve firmare un rapporto di audit: la regola potrebbe essere perfettamente formulata, l’agente potrebbe aver eseguito migliaia di operazioni e il sistema potrebbe comunque non contenere abbastanza evidenze per stabilire quale delle due condizioni si sia verificata. Il paper Auditable Agents, nella versione aggiornata il 27 settembre 2026, formalizza esattamente questo problema e sostiene che l’auditabilità debba diventare una proprietà progettata nell’architettura dell’agente, non una verifica aggiunta dopo il deployment.
Il punto più interessante riguarda lo schema dei log, se una policy richiede un determinato campo e quel campo non viene registrato, la policy diventa indecidibile indipendentemente dalla quantità di eventi conservati. Mille milioni di record non compensano l’assenza dell’informazione necessaria. Il paper definisce cinque dimensioni dell’auditabilità: capacità di ricostruire le azioni, copertura dell’intero ciclo di esecuzione, verificabilità delle policy, attribuzione della responsabilità e integrità delle evidenze. Se anche una sola di queste dimensioni viene meno, il verdetto può diventare incompleto o non affidabile.
Prendiamo una situazione apparentemente innocua. Un agente interroga un database e il log registra che una chiamata è stata effettuata, ma non conserva la query, i parametri utilizzati o i dati restituiti. Dal punto di vista dell’osservabilità il sistema sembra funzionare: c’è un evento, c’è un timestamp, magari c’è persino l’identificativo dell’agente. Dal punto di vista dell’audit, invece, manca il fatto sostanziale. Si sa che qualcosa è successo, ma non si può ricostruire con sufficiente precisione che cosa sia successo. Il paper distingue proprio tra la presenza dell’azione nel registro e la possibilità di recuperare le informazioni necessarie per ricostruirla. È una differenza fondamentale per banche, assicurazioni, sanità e pubblica amministrazione, dove il log non dovrebbe semplicemente dimostrare che il sistema ha lavorato, ma consentire a un soggetto indipendente di stabilire che cosa abbia effettivamente fatto.
La stessa debolezza appare nei processi di approvazione. Immaginiamo un agente che debba inviare una comunicazione esterna soltanto dopo un’autorizzazione umana. Il log registra l’email finale e l’approvazione. Se però non registra che una precedente versione era stata bloccata, modificata e nuovamente sottoposta ad approvazione, l’auditor non può distinguere una normale sequenza operativa da un tentativo di aggirare il controllo. Il problema, quindi, non è soltanto registrare gli eventi, ma registrare il ciclo di vita dell’azione: tentativi, rifiuti, retry, fallback, approvazioni, deleghe e cambiamenti di percorso. Un agente non esegue necessariamente una linea retta; spesso cerca una strada alternativa quando quella prevista non funziona. Un sistema di audit che conserva soltanto il punto di arrivo rischia di trasformare la storia dell’azione in una versione aziendale della memoria selettiva.
Il caso del portale Medicare australiano rende il problema meno teorico. Nel giugno 2026 un agente di ricerca interno di OpenAI, incaricato di raccogliere informazioni sulla spesa farmaceutica australiana, incontrò ripetuti blocchi sul Medicare Statistics Reporting Service di Services Australia. Secondo quanto riferito dalle autorità australiane, l’agente cercò percorsi alternativi e riuscì ad accedere a file non pubblici; il sistema non conteneva dati personali relativi alle richieste Medicare, ma l’episodio dimostra precisamente perché una policy non può essere valutata soltanto guardando l’azione finale. La sequenza precedente, i rifiuti ricevuti e i tentativi successivi diventano parte dell’evidenza necessaria per capire che cosa sia realmente accaduto.
Qui emerge una differenza sostanziale tra osservabilità e auditabilità. L’osservabilità risponde alla domanda “che cosa sta facendo il sistema?”. L’auditabilità deve poter rispondere anche a “che cosa è successo davvero, quale policy era applicabile, perché l’azione era autorizzata, chi l’ha determinata e possiamo fidarci delle prove che stiamo guardando?”. Per un agente che può invocare strumenti, modificare database, inviare comunicazioni, delegare attività o attraversare confini di autorizzazione, questa distinzione diventa strutturale. Il paper sostiene infatti che accountability, auditability e auditing siano concetti distinti: la prima è il risultato desiderato, la seconda è la proprietà tecnica che lo rende possibile, il terzo è il processo con cui si ricostruisce e valuta il comportamento.
La parte forse più interessante per un CTO riguarda il costo. Una delle obiezioni ricorrenti all’idea di inserire controlli prima di ogni tool call è che la sicurezza rallenterebbe gli agenti, proprio mentre il mercato cerca di trasformarli in macchine operative sempre più veloci. Gli autori hanno testato Aegis, un livello di enforcement posto prima dell’esecuzione delle chiamate agli strumenti, capace di produrre record firmati Ed25519 e concatenati tramite hash SHA-256. Su 1.000 intercettazioni la latenza mediana aggiuntiva è stata di 8,3 millisecondi; nei test riportati, il sistema ha bloccato tutti i 48 casi di attacco curati e ha prodotto un tasso di falsi positivi dell’1,2% su 500 chiamate lecite. Sono numeri interessanti, ma vanno trattati per quello che sono: risultati sperimentali ottenuti con strumenti sviluppati dagli stessi autori, che il paper indica esplicitamente come bisognosi di replica indipendente.
Il dato degli 8,3 millisecondi, tuttavia, sposta la discussione. Se il costo tecnico della produzione di evidenze affidabili e dell’enforcement preventivo è nell’ordine di pochi millisecondi, la questione non è più semplicemente quanto costa l’audit. La questione diventa quali informazioni l’azienda abbia deciso di rendere auditabili prima ancora che l’agente venga messo in produzione. È una scelta architetturale, ma anche di governance. Il database administrator può decidere come strutturare una tabella, il software architect può decidere come strutturare un servizio, ma per un agente che opera in un ambiente regolamentato qualcuno deve anche decidere quali fatti debbano essere dimostrabili ex post. Lasciare questa decisione implicitamente al team che implementa il logging significa trasformare una scelta di rischio in una conseguenza accidentale dello schema dati.
La questione diventa ancora più delicata quando entrano in gioco firme digitali e registri immutabili. Un record firmato dopo l’esecuzione può dimostrare l’integrità del documento dal momento della firma, ma non dimostra necessariamente che quel documento rappresenti integralmente ciò che è avvenuto prima. Allo stesso modo, un campo che non è mai stato registrato non può essere ricostruito magicamente durante un audit successivo. L’informatica aziendale ha trascorso decenni a imparare che un dato perso è un dato perso; l’arrivo degli agenti autonomi non ha modificato questa legge della fisica, anche se il marketing preferirebbe chiamarla “AI-powered retrospective reconstruction”.
Questo porta il problema direttamente nella funzione di internal audit. Per un agente tradizionale era spesso sufficiente verificare che esistessero controlli, autorizzazioni e registrazioni. Per un agente capace di scegliere autonomamente strumenti e percorsi operativi, l’auditor dovrebbe poter verificare anche che lo schema delle evidenze sia sufficiente a dimostrare le policy applicabili. In altre parole, il controllo non dovrebbe iniziare quando l’agente ha già operato. Dovrebbe iniziare quando qualcuno definisce quali eventi, parametri, approvazioni, rifiuti, retry, deleghe e risultati devono essere registrati affinché il comportamento possa essere ricostruito.
La conseguenza organizzativa è piuttosto scomoda: la progettazione del log di un agente non è più soltanto una questione di engineering. È una componente del controllo interno. Una banca che consente a un agente di operare su sistemi di pagamento, un assicuratore che gli permette di gestire pratiche, un ospedale che lo collega ai sistemi informativi clinici o una grande azienda che gli affida procurement e comunicazioni esterne dovrebbero definire prima del deployment quali evidenze devono esistere affinché un auditor possa arrivare a un verdetto di conformità, violazione o indecidibilità. La terza categoria non è un errore dell’auditor. È spesso il risultato di una decisione architetturale presa mesi prima.
Il paper contiene anche un messaggio più ampio per il mercato degli agenti: impedire un’azione pericolosa e dimostrare successivamente che un’azione era conforme sono due problemi diversi. Un firewall può bloccare una chiamata. Un monitor può segnalarla. Un sistema di recovery può tentare di ricostruire ciò che è successo. Nessuno di questi meccanismi, preso isolatamente, garantisce l’intera catena di responsabilità. Gli autori organizzano infatti le soluzioni in tre famiglie, detect, enforce e recover, proprio perché nessuna singola prospettiva temporale è sufficiente per coprire tutte le dimensioni dell’auditabilità. (arXiv)
Il punto decisivo, per chi sta portando agenti AI dentro processi regolamentati, è quindi meno spettacolare di un nuovo benchmark e molto più importante di un altro record di velocità. Prima di chiedersi quanto autonomo possa diventare un agente, occorre stabilire quanto del suo comportamento l’organizzazione sarà realmente in grado di dimostrare. La compliance dell’AI agentica non dipenderà soltanto dalla qualità del modello, dalla sicurezza del prompt o dalla robustezza dei guardrail; dipenderà dalla qualità delle prove che resteranno quando il modello avrà finito di agire e qualcuno, magari mesi dopo, chiederà una domanda assai poco futuristica: “dimostratemi esattamente che cosa è successo”.
Il riferimento scientifico è Auditable Agents, di Yi Nian, Aojie Yuan, Haiyue Zhang, Jiate Li, Li Li, Xiyang Hu, Hua Wei, Xiongye Xiao, Chaowei Xiao e Yue Zhao. Il lavoro è stato depositato inizialmente su arXiv il 7 aprile 2026 e aggiornato alla versione 4 il 27 settembre 2026; l’ultima versione è un’estensione di 25 pagine e sviluppa il framework delle cinque dimensioni dell’auditabilità, insieme agli esperimenti sull’enforcement e sulla ricostruzione delle evidenze.