L’intelligenza artificiale agentica modifica il perimetro della prova digitale. Quando un sistema non si limita a generare un testo, ma consulta archivi, usa credenziali, invoca strumenti, interagisce con applicazioni e produce effetti nel mondo esterno, l’output finale non è più sufficiente a spiegare l’accaduto. Diventa necessario ricostruire la sequenza composta da obiettivo, istruzioni di sistema e dell’utente, contesto recuperato, memoria, configurazione, identità, deleghe, autorizzazioni, chiamate agli strumenti, risposte dei servizi e modifiche effettivamente registrate nei sistemi destinatari.
Si può considerare questa sequenza come una nuova catena probatoria e delinea un metodo per acquisirla, preservarla e valutarla senza confondere la traccia osservabile con il presunto ragionamento interno del modello. La forensics degli agenti non dovrebbe cercare una spiegazione psicologica dell’IA, ma una ricostruzione tecnica, verificabile e contestualizzata del rapporto tra istruzioni ricevute, capacità conferite, azioni eseguite ed effetti prodotti.
Indice degli argomenti
Quando l’IA agisce, cambia la prova digitale
La diffusione dei sistemi di intelligenza artificiale generativa ha abituato operatori, imprese e professionisti a concentrare l’attenzione sull’output: il testo prodotto, l’immagine generata, il riepilogo restituito, il codice suggerito. Con l’IA agentica questo approccio non è più sufficiente.
Un agente può ricevere un obiettivo, scomporlo in attività, recuperare informazioni, scegliere uno strumento, utilizzare un account di servizio, inviare una comunicazione, aggiornare un database, modificare un file, eseguire codice o interagire con altri agenti. Il risultato non è soltanto una risposta. È una sequenza di operazioni che può incidere su persone, patrimoni, sistemi informativi e processi decisionali.
NIST ha avviato nel febbraio 2026 una specifica AI Agent Standards Initiative, indicando sicurezza, interoperabilità, identità e autorizzazione tra i problemi centrali dell’adozione degli agenti. Il relativo concept paper dell’NCCoE pone domande che hanno una rilevanza immediatamente forense: come identificare un agente, come provare l’autorità conferitagli, come legare la sua azione all’autorizzazione umana e come rendere i log verificabili e resistenti alle alterazioni.¹
Il cambio di paradigma è netto. Quando l’IA agisce, la domanda probatoria non è più soltanto “che cosa ha prodotto?”, ma “quale catena di istruzioni, dati, poteri e interazioni ha determinato l’azione, e quale effetto è stato davvero registrato nel sistema esterno?”. È in questo spazio che nasce la forensics delle istruzioni e delle azioni.
Agenti e chatbot: le differenze che contano per l’indagine
La distinzione non dipende dall’etichetta commerciale utilizzata dal fornitore. Un sistema può essere descritto come “assistente”, “copilot” o “agente”, ma il dato tecnicamente rilevante è il suo grado di capacità operativa.
Un chatbot tradizionale riceve un input e restituisce un contenuto. Un sistema agentico, invece, tende a combinare più componenti: un modello generativo, un orchestratore, uno stato della sessione, una memoria, fonti informative recuperate dinamicamente, regole di controllo e strumenti attraverso i quali il sistema può agire. L’autonomia non è assoluta: può essere circoscritta, supervisionata o subordinata a conferme umane. Resta però la possibilità che tra l’istruzione iniziale e il risultato si sviluppi un percorso non interamente predefinito.
Questo percorso può includere più chiamate al modello, tentativi falliti, correzioni, passaggi ad altri agenti, richieste di autorizzazione, risposte asincrone e azioni effettuate da servizi esterni. Il singolo screenshot della conversazione rappresenta solo la superficie visibile di un processo più ampio.
In ambito forense, pertanto, l’unità di analisi non dovrebbe essere il messaggio isolato, ma l’esecuzione identificata nel suo complesso: sessione, workflow, trace, run o task, secondo la terminologia della piattaforma esaminata.
La catena agentica da ricostruire oltre l’output
La catena agentica può essere descritta come una successione di livelli che concorrono alla produzione dell’effetto finale. Il primo livello è l’obiettivo assegnato: ciò che l’utente o un altro sistema chiede di ottenere. Il secondo è costituito dalle istruzioni di sistema e di sviluppo, spesso non visibili all’utente, che definiscono ruolo, limiti, priorità e comportamento dell’agente.
Seguono il contesto operativo e le fonti recuperate: documenti, e-mail, pagine web, risultati di ricerca, record aziendali, dati presenti in un sistema RAG. A questi si aggiungono la memoria della sessione o di interazioni precedenti, le policy applicate, le definizioni degli strumenti disponibili, la versione dell’agente e del modello, i parametri di esecuzione e gli eventuali filtri di sicurezza.
Il passaggio successivo è l’azione: selezione dello strumento, argomenti della chiamata, credenziale utilizzata, decisione del sistema di autorizzazione, risposta ottenuta, eventuale retry e gestione dell’errore. Infine vi è l’effetto esterno: il messaggio spedito, il file modificato, il record creato, l’ordine inserito, il pagamento disposto, il codice distribuito o il dato eliminato.
Non tutti i sistemi conservano ogni livello e non tutti i livelli hanno lo stesso valore probatorio. La ricostruzione, tuttavia, deve partire da questa architettura. Fermarsi all’output significa osservare l’ultimo fotogramma senza ricostruire la sequenza che lo ha preceduto.
Dove cercare le tracce dell’esecuzione
La prova relativa a un agente è normalmente distribuita tra più infrastrutture. Una parte può trovarsi nella piattaforma di orchestrazione, una parte nei log del provider del modello, una parte nel sistema di identità e accesso, una parte nei servizi invocati e una parte nel dispositivo o nell’applicazione dell’utente.
Tra le fonti tecniche assumono rilievo gli identificativi della sessione e della singola esecuzione, le istruzioni applicate, la cronologia dei messaggi, i documenti recuperati, le definizioni degli strumenti, le chiamate con i relativi argomenti, i risultati restituiti, gli errori, i tentativi ripetuti, i passaggi tra agenti, le conferme umane e gli eventi di policy. A queste tracce devono essere correlati i log IAM, OAuth e API gateway, gli audit log cloud, i log applicativi e le registrazioni del sistema destinatario.
Le convenzioni semantiche di OpenTelemetry per la GenAI mostrano concretamente questa evoluzione. Tra gli attributi previsti figurano identificativo e versione dell’agente, identificativo della conversazione, istruzioni di sistema, dati recuperati, definizioni degli strumenti, identificativo della tool call, argomenti e risultato. Le tracce possono rappresentare l’esecuzione dell’agente come una struttura composta da chiamate al modello e invocazioni di strumenti.²
Si tratta di telemetria nata principalmente per osservabilità, sicurezza e diagnosi, non automaticamente di prova forense. Può essere incompleta, campionata, modificabile o soggetta a differenti politiche di conservazione. Tuttavia, se raccolta e preservata correttamente, costituisce una fonte essenziale per ricostruire l’esecuzione.
Identità e delega: attribuire le azioni degli agenti
L’attribuzione è uno dei problemi più delicati. In un sistema agentico l’azione può risultare formalmente eseguita da un account di servizio, materialmente avviata da un agente e originariamente richiesta da una persona. Tra questi soggetti possono inserirsi un orchestratore, un secondo agente, un’automazione temporizzata e un servizio esterno.
Occorre quindi distinguere almeno quattro elementi: l’identità dell’utente, l’identità dell’istanza agentica, la credenziale utilizzata e l’ambito della delega. L’esistenza di un token valido prova che una richiesta è stata autenticata, ma non dimostra da sola chi l’abbia voluta, se rientrasse nell’autorizzazione conferita o se la credenziale sia stata usata in modo improprio.
La questione è particolarmente evidente nelle azioni “per conto di”. Un agente autorizzato a leggere la posta può avere anche la possibilità tecnica di inoltrare messaggi; un agente abilitato a predisporre un pagamento può disporre di privilegi superiori a quelli necessari; un agente di sviluppo può ereditare chiavi che consentono di intervenire sull’ambiente di produzione. La capacità tecnica non coincide con l’autorizzazione sostanziale.
La ricostruzione probatoria deve documentare il legame tra identità umana e identità agentica, gli scope della credenziale, il momento del rilascio, le condizioni applicate, le approvazioni richieste, le eventuali revoche e la corrispondenza tra azione compiuta e mandato conferito. L’attribuzione non può essere dedotta dal solo nome dell’account.
Dalla tool call alla prova dell’effetto esterno
Uno degli errori più frequenti sarà considerare la chiamata a uno strumento come prova sufficiente dell’azione. La tool call documenta una richiesta formulata dall’agente; non dimostra necessariamente che il servizio l’abbia accettata, che l’operazione sia stata completata o che il risultato sia rimasto invariato.
Una chiamata può fallire, essere bloccata da una policy, produrre un errore parziale, entrare in una coda, richiedere un secondo passaggio o essere annullata. Anche un messaggio di successo restituito al modello può non coincidere con lo stato finale del sistema destinatario.
Per verificare un invio di e-mail, ad esempio, occorre correlare la richiesta dell’agente con l’autorizzazione utilizzata, la risposta dell’API, il record nella posta inviata, i log del server e, se rilevante, la consegna al destinatario. Per una modifica a un database servono la query o l’operazione richiesta, l’esito della transazione, il record precedente e successivo e gli eventuali rollback. Per un pagamento occorrono i passaggi autorizzativi e la registrazione presso il sistema finanziario.
La prova più robusta nasce quindi dalla correlazione tra traccia dell’agente e traccia indipendente dell’effetto. La prima spiega l’iniziativa tecnica; la seconda conferma ciò che è realmente avvenuto.
Prompt injection e memoria avvelenata: risalire all’istruzione
Gli agenti ampliano la superficie di attacco perché elaborano contenuti provenienti da fonti esterne e possono trasformarli in azioni. Un’istruzione ostile può essere inserita direttamente dall’utente oppure indirettamente in una e-mail, in un documento, in una pagina web, in un record recuperato o nella descrizione di uno strumento.
Se l’agente tratta quel contenuto come istruzione anziché come dato, può deviare dall’obiettivo originario. Altri scenari comprendono l’uso improprio di strumenti legittimi, l’abuso di privilegi, l’avvelenamento della memoria, la comunicazione insicura tra agenti e la propagazione di un errore lungo una catena di deleghe. OWASP ha raccolto questi problemi nel Top 10 for Agentic Applications 2026 e, nel settembre 2026, ha pubblicato l’Agent Control Standard, che insiste sulla necessità di agenti ispezionabili, tracciabili e controllabili durante l’esecuzione.³
Da un punto di vista forense, l’origine dell’istruzione diventa decisiva. Non basta sapere quale testo il modello abbia ricevuto; occorre stabilire da dove provenisse, quando sia stato acquisito, se fosse attendibile, quale priorità gli sia stata attribuita e se abbia alterato il comportamento dell’agente.
Si consideri un agente incaricato di esaminare la posta di uno studio professionale. Un allegato apparentemente ordinario contiene un’istruzione nascosta che induce il sistema a recuperare altri documenti e inviarli a un indirizzo esterno. Il solo messaggio finale non spiega l’incidente. Servono l’e-mail originaria, l’allegato, il contenuto estratto, le istruzioni di sistema, la query di recupero, i file selezionati, la tool call di invio, i token utilizzati e i log del server di posta.
I limiti dei log nella ricostruzione forense
La forensics dell’IA agentica deve evitare una scorciatoia concettuale: presentare i log come se consentissero di leggere il ragionamento interno del modello. Ciò che può essere acquisito è una traccia tecnica dell’esecuzione, nei limiti di quanto il sistema ha effettivamente registrato.
Istruzioni, messaggi, fonti recuperate, chiamate agli strumenti, risultati, approvazioni, errori e timestamp sono eventi osservabili. Un piano esplicito o una motivazione generata possono essere documenti utili, ma non coincidono necessariamente con il processo interno che ha determinato l’output. Una spiegazione prodotta a posteriori dal modello non diventa, per questo, una registrazione contemporanea della causa dell’azione.
Anche il conteggio di token destinati al reasoning, quando disponibile, segnala l’uso di risorse computazionali ma non fornisce automaticamente il contenuto di un ragionamento. La relazione tecnica deve quindi distinguere tra evento registrato, interpretazione compatibile e ipotesi causale.
Il compito del consulente non è attribuire intenzioni psicologiche alla macchina. È ricostruire le condizioni tecniche che hanno reso possibile l’azione e valutare quali passaggi risultino provati, quali siano solo inferibili e quali restino non determinabili.
Acquisire le tracce e preservare la catena di custodia
Le tracce agentiche sono volatili e distribuite. Possono essere soggette a rotazione, campionamento, cancellazione, mascheramento, aggregazione o conservazione differenziata. La prima esigenza è quindi la preservazione tempestiva, prima che l’uso ordinario del sistema o le politiche del provider alterino il quadro disponibile.
L’acquisizione dovrebbe comprendere, ove disponibili:
• identificativi di sessione, esecuzione, agente, modello e workflow;
• istruzioni applicate, cronologia dei messaggi, fonti recuperate e stato della memoria;
• versioni di prompt, policy, strumenti, connettori, applicazioni e configurazioni;
• identità, credenziali, scope, deleghe, approvazioni e decisioni di accesso;
• tool call, argomenti, risultati, errori, retry e passaggi tra agenti;
• log del sistema destinatario e stato precedente e successivo all’azione;
• timestamp originari, fuso orario, fonte temporale e possibili latenze;
• formato di esportazione, schema dei dati, hash, manifest e soggetto che ha eseguito la raccolta.
Le buone pratiche della digital forensics restano valide: identificazione della fonte, raccolta documentata, conservazione dell’integrità e possibilità di controllo.⁴ Cambia però l’oggetto. Non si acquisisce soltanto un dispositivo, ma un insieme di eventi distribuiti tra componenti che possono appartenere a soggetti differenti.
La ripetibilità richiede una precisazione. Un agente può produrre risultati diversi a causa della natura non deterministica del modello, dell’aggiornamento delle fonti o del mutamento dello stato esterno. L’obiettivo realistico non è sempre rigenerare lo stesso comportamento, ma rendere verificabili le condizioni dell’esecuzione originaria e la provenienza delle tracce utilizzate.
Logging degli agenti tra AI Act e protezione dei dati
Il quadro normativo europeo offre un riferimento importante, ma deve essere letto con precisione. L’articolo 12 dell’AI Act richiede che i sistemi di IA ad alto rischio consentano la registrazione automatica degli eventi per assicurare una tracciabilità adeguata alla finalità. Gli articoli 19 e 26 disciplinano, rispettivamente, la conservazione dei log sotto il controllo del provider e gli obblighi dei deployer in relazione ai log generati dal sistema.⁵
Queste disposizioni non costituiscono una disciplina generale della prova degli agenti e non si applicano indistintamente a ogni soluzione agentica. Inoltre, dopo la revisione del calendario europeo, gli obblighi relativi ai sistemi ad alto rischio dell’allegato III sono destinati ad applicarsi dal 2 dicembre 2027, mentre quelli per i sistemi incorporati in prodotti regolamentati dell’allegato I dal 2 agosto 2028. Il principio resta però rilevante: senza registrazioni adeguate non vi sono controllo effettivo, monitoraggio né ricostruzione affidabile.⁶
Il logging deve essere bilanciato con la protezione dei dati. Prompt, documenti recuperati, risultati degli strumenti e memorie possono contenere informazioni personali, segreti professionali, dati sanitari o credenziali. Conservare tutto senza criterio non aumenta automaticamente la qualità probatoria e può generare un ulteriore rischio.
Minimizzazione, limitazione della finalità, durata di conservazione, segregazione degli accessi, cifratura e tracciamento delle consultazioni devono essere progettati insieme alla capacità forense.⁷ La forensic readiness non coincide con una sorveglianza indiscriminata: consiste nel conservare gli eventi necessari, con garanzie adeguate e regole note prima dell’incidente.
Un protocollo operativo per la forensics degli agenti
Per affrontare un incidente o una contestazione che coinvolga un agente è utile adottare un protocollo per fasi. La prima è la mappatura dell’architettura: modello, orchestratore, memorie, fonti RAG, strumenti, identità, connettori, sistemi destinatari e soggetti che li controllano.
La seconda è il congelamento logico dell’ambiente. Devono essere preservate le versioni delle istruzioni, delle policy, delle definizioni degli strumenti, dell’agente e delle configurazioni applicate al momento dell’evento. Una modifica successiva può rendere impossibile comprendere il comportamento originario.
La terza è l’identificazione dell’esecuzione. Occorre legare tra loro session ID, run ID, trace ID, tool call ID, request ID e identificativi presenti nei sistemi esterni. Senza questa correlazione, i log restano frammenti non necessariamente riferibili allo stesso episodio.
La quarta è la ricostruzione della provenienza delle istruzioni. Ogni contenuto rilevante deve essere classificato: istruzione di sistema, input umano, dato recuperato, memoria, output di altro agente, risultato di uno strumento o contenuto esterno potenzialmente ostile.
La quinta è la verifica di identità e poteri. Devono essere ricostruiti autenticazione, credenziali, scope, deleghe, approvazioni e controlli applicati. La domanda non è soltanto se l’agente potesse compiere l’azione, ma se fosse autorizzato a compierla in quella specifica esecuzione.
La sesta è la correlazione tra tool call ed effetto esterno. La richiesta dell’agente deve essere confrontata con l’esito registrato dal servizio destinatario, distinguendo comando, accettazione, esecuzione e stato finale.
La settima è la normalizzazione temporale e l’analisi delle discontinuità: fusi orari, clock differenti, code, latenze, retry, eventi mancanti e intervalli di raccolta devono essere resi espliciti.
L’ottava è la valutazione probatoria. Il rapporto finale dovrebbe separare fatti tecnici osservati, inferenze supportate, scenari alternativi, limiti di acquisizione e dati non disponibili. Questa distinzione è decisiva per il contraddittorio e impedisce che una timeline tecnicamente incompleta venga presentata come una narrazione certa.
Questo approccio è coerente con il NIST AI 600-1, che collega provenienza, monitoraggio e documentazione degli incidenti alla possibilità di risalire dagli impatti alle rispettive fonti.⁸
Una prova verificabile tra istruzioni, poteri ed effetti
L’IA agentica non introduce soltanto un nuovo tipo di software. Introduce un nuovo oggetto forense. L’evento da ricostruire non è più contenuto in un singolo file né coincide con una conversazione: è distribuito tra istruzioni, contesto, memoria, identità, autorizzazioni, strumenti e sistemi esterni.
Questa trasformazione rende insufficiente l’analisi del solo output. Un testo può essere innocuo mentre l’azione sottostante ha modificato un archivio; una tool call può apparire decisiva ma non essere mai stata eseguita; un account può risultare autenticato senza dimostrare che l’azione rientrasse nella delega; una risposta del modello può offrire una spiegazione a posteriori, ma non colmare ciò che i log contemporanei non documentano.
La qualità dell’accertamento dipenderà dalla capacità di ricostruire una catena verificabile: chi ha definito l’obiettivo, quali istruzioni erano operative, quali fonti hanno alimentato il contesto, quale identità e quali poteri sono stati utilizzati, quali strumenti sono stati invocati e quale effetto è stato registrato indipendentemente.
La sfida, ancora una volta, non è raccogliere più dati, ma produrre prove migliori. Una prova agentica è solida quando distingue l’evento dall’interpretazione, conserva il contesto dell’esecuzione, documenta i vuoti informativi e consente a un soggetto terzo di controllare il percorso tecnico.
La forensics delle istruzioni e delle azioni non cerca il “pensiero” della macchina. Ricostruisce, con metodo, il rapporto tra istruzione ricevuta, capacità conferita, azione eseguita ed effetto prodotto. È questo rapporto, non il fascino dell’autonomia artificiale, a dover entrare nel processo e nei sistemi di accountability.
Note
1. NIST, Announcing the AI Agent Standards Initiative for Interoperable and Secure Innovation, 17 febbraio 2026; NIST NCCoE, Accelerating the Adoption of Software and AI Agent Identity and Authorization – Concept Paper, febbraio 2026. ↩
2. OpenTelemetry, Generative AI semantic conventions – attribute registry; James Newton-King, Inside the LLM Call: GenAI Observability with OpenTelemetry, 14 maggio 2026. Le convenzioni tecniche costituiscono un riferimento di interoperabilità e osservabilità; la loro adozione non rende automaticamente i log completi o forensicamente affidabili. ↩
3. OWASP GenAI Security Project, OWASP Top 10 for Agentic Applications for 2026, 9 dicembre 2025; Agent Control Standard (ACS), 1 settembre 2026. Si tratta di framework tecnici e non di fonti normative vincolanti. ↩
4. ISO/IEC 27037:2012, Information technology – Security techniques – Guidelines for identification, collection, acquisition and preservation of digital evidence. Si richiamano i principi generali di identificazione, raccolta, acquisizione e conservazione, da adattare alla natura distribuita delle tracce agentiche. ↩
5. Regolamento (UE) 2024/1689 (AI Act), in particolare artt. 12, 19 e 26, testo consolidato disponibile su EUR-Lex. L’art. 12 riguarda i sistemi di IA ad alto rischio e non stabilisce un obbligo generalizzato di logging per ogni agente. ↩
6. Commissione europea, The enforcement framework of the AI Act, aggiornamento del 6 ottobre 2026; Commissione europea, Guidelines for providers and deployers of AI high-risk systems. Il calendario indicato riflette le modifiche intervenute con l’AI Omnibus. ↩
7. Regolamento (UE) 2016/679 (GDPR), con particolare riferimento all’art. 5 – minimizzazione, limitazione della finalità, limitazione della conservazione, integrità e riservatezza – e all’art. 32 sulla sicurezza del trattamento, testo disponibile su EUR-Lex. ↩
8. NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1, 26 luglio 2024. Il documento richiama il valore della provenienza, del monitoraggio e della documentazione degli incidenti per risalire dagli impatti alle rispettive fonti. ↩
Partecipa alla community