The Pulse

Esperti elaborano regole per segnalare gli incidenti che coinvolgono agenti di IA

Un nuovo articolo su arXiv raccoglie il contributo di 23 esperti del mondo accademico e industriale per proporre quali informazioni dovrebbero registrare le segnalazioni di sicurezza quando gli agenti di IA vengono compromessi. Il quadro pr

AI.info Team · 2026-09-22

Le segnalazioni degli incidenti che coinvolgono l’IA descrivono spesso ciò che un sistema di IA ha prodotto. Un nuovo articolo sostiene che, quando si tratta di agenti autonomi, le segnalazioni debbano anche ricostruire il percorso seguito dal sistema tra memoria, strumenti, attività delegate e servizi esterni prima che si verificasse un danno.

«Oltre i percorsi prevedibili: ridefinire la segnalazione degli incidenti di sicurezza dell’IA per gli agenti», presentato ad arXiv il 21 settembre 2026, sintetizza i contributi di 23 esperti del mondo accademico e industriale. Gli autori affermano che gli approcci attuali alla segnalazione non documentano adeguatamente gli incidenti di sicurezza che coinvolgono sistemi capaci di perseguire obiettivi attraverso più passaggi, anziché restituire un singolo risultato.

La proposta non è uno standard definitivo. L’articolo è contrassegnato come «in fase di valutazione» e la scheda arXiv specifica che la paternità dell’articolo non implica l’approvazione di ogni sua sezione. Il suo valore consiste nell’individuare le prove di cui gli investigatori potrebbero aver bisogno prima che le azioni di un agente scompaiano da un contesto di breve durata o dai log distribuiti del sistema.

Perché un singolo risultato non racconta più tutta la storia

L’articolo distingue i sistemi di IA convenzionali dagli agenti moderni basati su modelli linguistici di grandi dimensioni. Un sistema ordinario può essere analizzato attraverso una coppia input-output; un agente può arrivare allo stesso risultato dannoso attraverso una sequenza di passaggi di ragionamento, chiamate a strumenti, accessi alla memoria e interazioni con altri sistemi.

Questa differenza cambia l’oggetto dell’indagine. Una segnalazione di sicurezza potrebbe dover spiegare non solo che cosa ha fatto un agente, ma anche quali dati ha letto, quali istruzioni sono state inserite nel suo contesto, quali strumenti ha invocato, quale identità ha autorizzato ogni chiamata e se un altro agente o sottosistema ha influenzato il risultato.

Gli autori descrivono la sicurezza degli agenti come un problema di sistema. Un modello può comportarsi come previsto, mentre una vulnerabilità emerge dall’interazione tra il modello, la sua memoria, un orchestratore, un sistema di recupero delle informazioni, uno strumento esterno o un sistema operativo connesso. In questa prospettiva, una segnalazione che si concentri solo sul risultato prodotto dal modello può non rilevare la condizione che ha reso possibile l’incidente.

La documentazione proposta segue il percorso dell’agente

Lo schema preliminare di segnalazione dell’articolo organizza le prove attorno al percorso e alle capacità dell’agente. Prevede la registrazione della cronologia dei messaggi, dei token di ragionamento, della provenienza o della versione dei dati esterni, delle letture e scritture dei dati, nonché della differenza tra il livello di autonomia consentito in fase di progettazione e quello effettivamente esercitato durante l’incidente.

Questa distinzione è importante perché le autorizzazioni teoriche di un agente possono essere più ampie di quelle che usa nella pratica. L’articolo afferma che gli investigatori dovrebbero registrare gli strumenti effettivamente invocati, gli argomenti trasmessi e le risposte ricevute, anziché affidarsi a un elenco di strumenti semplicemente disponibili. Le segnalazioni dovrebbero inoltre documentare gli effetti dell’agente sul sistema operativo sottostante, la sua identità durante ogni azione, i token di autenticazione e l’intera catena di delega, da una persona o da un altro agente.

La delega può complicare l’attribuzione delle responsabilità. Un agente potrebbe agire con le autorizzazioni di un utente, operare con un’identità macchina distinta o affidare il lavoro a un altro agente con accessi diversi. La documentazione proposta include quindi i confini di fiducia e le identità associate alle singole chiamate agli strumenti: informazioni che possono aiutare a distinguere una decisione impropria sul controllo degli accessi da un input malevolo, da uno strumento compromesso o da un problema di comunicazione.

I sistemi multi-agente aggiungono un secondo livello di prove

Gli autori estendono il modello di segnalazione ai sistemi che includono sotto-agenti, modelli di recupero delle informazioni, filtri classificatori e modelli valutatori. La segnalazione dovrebbe descrivere sia l’architettura definita prima della distribuzione sia i componenti effettivamente invocati durante l’incidente.

Anche i log delle comunicazioni e i protocolli di orchestrazione diventano parte della documentazione di sicurezza. L’articolo indica possibili problemi legati a una debole integrità dei messaggi, alla mancanza di informazioni sulla provenienza, a una serializzazione non sicura, all’autorità non chiaramente definita e alla confusione tra istruzioni e dati. Le istruzioni malevole possono passare da un agente all’altro attraverso normali canali di comunicazione, mentre i problemi di coordinamento o la collusione possono emergere solo durante l’esecuzione.

Questi incidenti potrebbero non essere riconducibili a un singolo componente difettoso. Una vulnerabilità può essere una proprietà emergente delle modalità di interazione del sistema, anche quando ogni modello o sottosistema sembra funzionare come previsto se considerato isolatamente. Registrare la sequenza e le relazioni tra i componenti offre agli investigatori maggiori possibilità di individuare il problema.

La segnalazione dell’incidente può creare una nuova superficie di attacco

Una documentazione più dettagliata può agevolare la ricostruzione, ma l’articolo avverte che il processo di segnalazione può esporre informazioni sensibili. Le tracce di esecuzione possono contenere dati proprietari, informazioni personali, credenziali o istruzioni riservate. Un sistema che richieda una registrazione estesa può quindi creare un secondo problema: decidere che cosa gli investigatori debbano conservare e quali informazioni debbano effettivamente essere comunicate a un’autorità di regolamentazione, a un cliente o al pubblico.

Gli autori individuano anche attacchi rivolti al meccanismo di segnalazione stesso. Un agente compromesso potrebbe manipolare i log o alterare i modelli di accesso per nascondere le proprie attività. Un aggressore che conosca le regole di segnalazione potrebbe mettere a punto comportamenti in grado di eludere il rilevamento, mentre un sistema usato per presentare o analizzare le segnalazioni potrebbe a sua volta divulgare informazioni o inserire contenuti fuorvianti.

Questi rischi lasciano irrisolte diverse questioni di progettazione. L’articolo non stabilisce quali campi debbano essere obbligatori, quali prove siano sufficienti per riprodurre un incidente o condurre un esame giuridico, come le segnalazioni debbano tutelare la privacy o quando gli incidenti osservati in un agente debbano essere considerati prova di una vulnerabilità più ampia.

La legge impone obblighi di segnalazione, ma non definisce tutti i campi

L’articolo affianca la propria proposta alle normative e agli standard esistenti, senza presentarla come un loro sostituto. Esamina gli obblighi di segnalazione previsti dall’AI Act dell’Unione europea, compreso l’articolo 73, e osserva che i requisiti attuali non specificano i campi relativi alle chiamate agli strumenti, alle scritture in memoria o alla delega con il livello di dettaglio ritenuto necessario dagli autori.

Gli autori sostengono che le decisioni sulla registrazione dei dati debbano essere prese prima che si verifichi un incidente. La memoria di un agente può cambiare, il contesto esterno può essere temporaneo e una compromissione potrebbe diventare visibile solo dopo una lunga sequenza di azioni. Se si aspetta di scoprire l’evento, gli investigatori potrebbero non disporre più delle prove necessarie per ricostruirlo.

Il quadro proposto è quindi tanto un programma di ricerca quanto un modello di segnalazione. Il suo contributo immediato consiste nello spostare l’unità di analisi dalla risposta del modello all’intero percorso operativo dell’agente: che cosa sapeva, che cosa poteva fare, che cosa ha effettivamente fatto, chi o che cosa ha autorizzato ogni passaggio e in che modo gli altri componenti hanno influenzato il risultato.