Per dimostrare cosa ha letto un agente IA prima di agire, registrate ogni lettura come evento a sé e collegate ogni fatto della decisione a uno di quegli eventi. Un evento di lettura indica il sistema sorgente, lo strumento o il recupero che lo ha prodotto, un digest della richiesta e del risultato, la versione del record sorgente, l’ora e il confine dei dati. Una mappa di provenienza dei campi indica poi, per ogni valore usato dall’agente, se proviene dal risultato di uno strumento, da un documento o dal modello. Con entrambi, un auditor può prendere una decisione e ricondurre ogni input a un record sorgente esistente in quel momento.
Questo articolo tratta i quattro tipi di lettura che un agente esegue, una forma di registrazione per ciascuno, un esempio KYC sintetico, la scelta tra conservare il contenuto e conservare un digest, e ciò che KLA registra oggi. La guida agli audit trail degli agenti IA copre la registrazione dell’esecuzione nel suo insieme. La riproduzione deterministica si basa sulle stesse registrazioni di lettura.
Perché gli auditor chiedono da dove provengono le informazioni
Un agente che esamina il fascicolo di un cliente, redige una relazione di credito o chiude un alert agisce sulla base di ciò che ha letto. Quando l’esito viene contestato, le prime domande riguardano gli input: quali record l’agente ha visto, se erano aggiornati, se era autorizzato a leggerli e quali fatti del suo output ha inventato.
La normativa sulla privacy pone una variante della stessa domanda. Ai sensi dell’articolo 15, paragrafo 1, lettera g), del GDPR, l’interessato che chiede l’accesso ha diritto, qualora i dati personali non siano raccolti presso di lui, a "tutte le informazioni disponibili sulla loro origine". L’articolo 14, paragrafo 2, lettera f), impone al titolare del trattamento di comunicare all’interessato "la fonte da cui hanno origine i dati personali". Un agente che attinge dati del cliente da più sistemi rende queste risposte più difficili, a meno che ogni lettura non sia registrata.
L’EU AI Act cita gli input nei log per una categoria. Per i sistemi di identificazione biometrica remota di cui all’Allegato III, punto 1, lettera a), l’articolo 12, paragrafo 3, richiede la registrazione della "banca dati di riferimento utilizzata dal sistema per verificare i dati di input" e dei "dati di input per i quali la ricerca ha portato a una corrispondenza". Per gli altri sistemi ad alto rischio, l’articolo 12, paragrafi 1 e 2, richiede una registrazione automatica che supporti la tracciabilità, l’identificazione dei rischi e il monitoraggio successivo all’immissione sul mercato, lasciando i campi al fornitore. Le registrazioni di lettura sono un modo per garantire questa tracciabilità per un agente.
Cosa mostra una traccia predefinita sulle letture
Molti team partono dai dati di tracing. Le convenzioni semantiche OpenTelemetry per l’IA generativa, in stato Development, definiscono uno span di recupero con gen_ai.data_source.id e gen_ai.retrieval.top_k, e uno span di esecuzione di strumento con gen_ai.tool.name e gen_ai.tool.call.id.
Gli attributi di contenuto sono Opt-In: gen_ai.retrieval.query.text, gen_ai.retrieval.documents, gen_ai.tool.call.arguments, gen_ai.tool.call.result e l’input del modello in gen_ai.input.messages. Una traccia con le impostazioni predefinite può mostrare che un recupero o una chiamata a uno strumento è avvenuto e quanto è durato, senza registrare cosa ha chiesto né cosa è tornato. Quando la cattura del contenuto è attiva, la traccia conserva valori grezzi in un archivio di solito dimensionato e conservato per il debug, senza versione della fonte e senza protezione dell’integrità.
Il tracing resta utile per la registrazione di lettura. trace_id e span_id collegano un evento di lettura allo span che ne ha misurato la durata.
Quattro tipi di lettura e cosa richiede ciascuno
Gli agenti leggono in quattro modi. Ciascuno richiede una registrazione leggermente diversa, e ciascuno ha una lacuna tipica che interrompe l’audit trail.
| Tipo di lettura | Esempio | Registrazione minima | Lacuna abituale |
|---|---|---|---|
| Lettura da sistema strutturato | Ricerca cliente nel CRM, saldo dal core banking, query SQL tramite connettore | ID e versione dello strumento, digest degli argomenti, riferimenti ai record, digest del risultato, versione del record sorgente o data di riferimento | Viene registrato solo il nome dello strumento; il risultato viene scartato dopo la fase |
| Lettura di documento | Scansione del passaporto, estratto conto, mandato firmato | ID del documento, checksum SHA-256, versione dell’oggetto in archivio, ora di ricezione, pagina e area di ogni valore citato | Il file viene sostituito sul posto con lo stesso nome, quindi il checksum non trova più corrispondenza |
| Recupero | Passaggi del manuale delle policy da un indice vettoriale | ID dell’indice e versione della build, digest della query, ID dei chunk restituiti, punteggi e digest del contenuto dei chunk, top_k | L’indice viene ricostruito e i vecchi ID dei chunk non esistono più |
| Modello o memoria | Un valore scritto dal modello senza fonte citata; un fatto richiamato dalla memoria dell’agente | Un’etichetta di fonte esplicita model o memory; per la memoria, l’ID dell’elemento di memoria e quando è stato scritto | I valori senza fonte sono conservati accanto a quelli con fonte senza nulla che li distingua |
Una registrazione di lettura e una mappa di provenienza dei campi
La registrazione di lettura qui sotto è sintetica e indipendente dal fornitore. Descrive una ricerca nel CRM durante una revisione KYC periodica. I digest sono abbreviati.
{
"read_id": "read_syn_0193_02",
"execution_id": "run_syn_0193",
"tool_call_id": "call_syn_0193_02",
"occurred_at": "2026-10-09T08:12:03.418Z",
"source": {
"system": "crm-eu",
"kind": "api",
"tool_id": "crm.customer.get",
"tool_version": "2026-09-30"
},
"request": {
"arguments_digest": "sha256:3b9e…41d0",
"record_refs": ["cust_syn_55120"]
},
"response": {
"result_digest": "sha256:c07a…9e12",
"source_record_version": "v41",
"as_of": "2026-10-09T08:12:03.390Z"
},
"boundary": {
"data_boundary_ref": "boundary_eu_kyc",
"purpose": "kyc-periodic-review"
},
"retention": {
"content_stored": "digest_only",
"content_location": "crm-eu record history"
}
}Collegare ogni fatto alla sua fonte
Le registrazioni di lettura mostrano cosa l’agente avrebbe potuto usare. La mappa di provenienza dei campi mostra cosa ha effettivamente usato. Allegatela alla registrazione della decisione, così che ogni campo di output rimandi a una sola fonte.
"field_provenance": {
"residence_country": {
"source": "tool",
"tool_call_id": "call_syn_0193_02",
"path": "$.address.country"
},
"id_document_expiry": {
"source": "document",
"document_id": "doc_syn_771",
"checksum_sha256": "8f14…a3c2",
"page": 1
},
"source_of_funds_summary": {
"source": "model"
}
}- Fonte strumento: il valore è letto da un percorso nel risultato registrato di uno strumento. Il revisore ricalcola il digest del risultato e verifica il valore a quel percorso.
- Fonte documento: il valore cita un documento che l’agente ha ricevuto in quella fase, tramite ID e checksum, con una pagina e, se disponibile, un’area della pagina.
- Fonte modello: il valore non ha una fonte esterna. Etichettatelo perché il revisore lo tratti come affermazione propria dell’agente e lo verifichi come tale.
Esempio svolto: una revisione KYC periodica sintetica
Una banca UE fittizia usa un agente di aggiornamento KYC. L’agente legge il profilo del cliente, l’ultimo documento d’identità e il riepilogo delle transazioni, poi propone un rating di rischio che un analista KYC deve approvare. Tutti gli identificativi e i valori qui sotto sono inventati.
| Input della decisione | Valore usato | Fonte | Prova di provenienza | Verifica dell’auditor e risultato |
|---|---|---|---|---|
| Paese di residenza | FR | Strumento: crm.customer.get | call_syn_0193_02, digest del risultato, versione del record v41 | Lo storico del CRM mostra v41 corrente alle 08:12:03Z; il valore corrisponde. Superata |
| Scadenza del documento d’identità | 2031-04-30 | Documento: doc_syn_771 | Checksum, pagina 1, area individuata tramite livello di testo | La versione dell’oggetto archiviato corrisponde al checksum; la data stampata corrisponde. Superata |
| Depositi in contanti, ultimi 90 giorni | EUR 18.400 | Strumento: txn.summary.get | call_syn_0193_03, digest del risultato | Il ricalcolo sul libro contabile del core banking per la stessa finestra dà EUR 18.400. Superata |
| Professione | Lavoratore autonomo | Strumento: crm.customer.get | call_syn_0193_02, versione del record v41 | Il CRM è passato a "Lavoratore dipendente" nella v43 due giorni dopo. L’agente ha usato il valore corrente in quel momento. Superata, con una nota per l’analista |
| Sintesi sull’origine dei fondi | Paragrafo narrativo | Modello | source: model | Nessuna fonte. La registrazione dell’approvazione dell’analista deve mostrare che il paragrafo è stato esaminato come testo scritto dall’agente. Eccezione: la schermata di approvazione non lo etichettava |
Conservare il contenuto o conservare un digest
Un digest è piccolo, si può conservare senza rischi in una registrazione sigillata e basta a dimostrare una corrispondenza. Da solo non dimostra nulla: l’auditor ha bisogno dei byte originali per ricalcolarlo. Decidete per ogni fonte dove quei byte resteranno per il periodo di conservazione.
- Digest più versione della fonte: da usare quando il sistema sorgente conserva lo storico dei record almeno per tutto il tempo in cui le prove devono essere verificabili. Registrate la versione o la data di riferimento, così che la lettura possa essere risolta in seguito.
- Digest più copia nell’archivio delle prove: da usare quando la fonte è modificabile, ha una conservazione più breve delle prove o è presso un terzo.
- Cattura a livello di campo: conservate solo i valori usati dalla decisione, con i loro percorsi. Così i dati personali nella registrazione delle prove si limitano a ciò che serve alla decisione.
- Oscuramento e accesso: applicate al contenuto di lettura conservato la stessa classificazione e la stessa policy di accesso della fonte. Registrate il profilo di oscuramento insieme alla lettura.
Cosa registra oggi KLA sulle letture
KLA registra le letture quando passano per un percorso governato. I punti seguenti descrivono il comportamento attuale e i suoi limiti.
Chiamate governate agli strumenti. Quando un agente chiama uno strumento tramite il runtime KLA, le ricevute firmate della chiamata contengono un digest SHA-256 degli argomenti dello strumento e del risultato rilasciato. Le ricevute sono scritte nel registro delle prove append-only per tenant e raccolte nel Sealed Evidence Bundle. Il registro conserva il digest; il contenuto letto resta nel sistema sorgente e nell’archivio del runtime.
Provenienza dei campi del Process. Un Process può dichiarare una fonte per ogni campo prodotto. Per una fonte strumento, KLA cattura il valore a un percorso del risultato rilasciato dello strumento e scrive quel valore. Per una fonte documento, l’agente cita un documento della fase, e il transition gate verifica la citazione rispetto ai documenti che la fase ha effettivamente ricevuto con contenuto. Una fonte dichiarata senza prove blocca la transizione con missing_field_provenance. La decisione del gate registra la mappa solo come riferimenti: {source: "tool", toolKey, callId}, {source: "document", documentId, documentType, checksumSha256, page, region} oppure {source: "model"}.
Document Intake. Ogni documento sorgente reca checksum_sha256, object_version_id e received_at. L’estrazione registra per ogni campo un hash del testo sorgente, il modello estrattore e la versione del contratto del campo, e gli eventi di acquisizione sono append-only. Quando il worker individua un valore citato, la registrazione conserva la pagina, le coordinate del riquadro e il metodo (text_layer o vision), mai il testo.
Limiti. Oggi KLA non cattura i chunk del recupero vettoriale né l’intera finestra di contesto del modello. Un recupero che un agente esegue nel proprio codice, fuori da una chiamata governata a uno strumento, non lascia alcuna registrazione di lettura in KLA; instradatelo tramite uno strumento governato per registrarlo. I Data Boundaries sono registrati per l’esecuzione nel suo insieme, senza una versione del confine per singola lettura.
Cosa abbiamo imparato costruendo campi con fonte documentale
Abbiamo costruito i campi con fonte documentale per una prova di concetto di onboarding degli esercenti a settembre 2026. Un campo come il numero di iscrizione al registro delle imprese doveva citare il documento di onboarding da cui proveniva, e il gate del Process rifiutava la transizione quando la citazione mancava.
La revisione della prima implementazione ha rilevato che le citazioni venivano verificate rispetto a tutti i documenti dell’esecuzione. Un agente poteva citare un documento che non gli era stato mostrato in quella fase, e il controllo passava. Abbiamo limitato il controllo ai documenti che la fase ha effettivamente ricevuto con contenuto. La stessa revisione ha rilevato che i valori catturati dai risultati degli strumenti andavano persi quando un’esecuzione si sospendeva in attesa di una risposta via email; abbiamo corretto il problema in modo che le catture sopravvivano all’attesa.
Abbiamo messo per iscritto un limite e lo abbiamo mantenuto. Una citazione dimostra che alla fase è stato mostrato il documento citato. Se il valore compare in quel documento è una questione distinta. Per rendere rapida questa seconda verifica, a fine settembre abbiamo aggiunto le aree di citazione: il worker individua il valore citato sulla pagina e la pagina del caso lo evidenzia per il revisore.
Individuare il testo con un modello ha posto un problema a sé. Un modello a cui si chiede se il proprio riquadro è corretto tende a confermare. Usiamo un controllo alla cieca: una seconda chiamata trascrive il riquadro ritagliato senza vedere il testo atteso, e il riquadro viene conservato solo se la trascrizione corrisponde. Le aree sono un ausilio alla lettura costruito da contenuto di pagina non attendibile, quindi non decidono mai una transizione.
Procedura di audit per la provenienza delle letture
Eseguite questi passaggi su un campione di decisioni scelto in base al rischio. La carta di lavoro per l’audit degli agenti IA mostra lo stesso metodo per autorità, approvazione ed esito.
- Elencare gli input: per ogni decisione campionata, elencate ogni fatto usato dall’agente a partire dal suo output e dalla registrazione della decisione.
- Risolvere la fonte: associate ogni fatto a un evento di lettura, a un documento o a un’etichetta
model. Un fatto senza voce è un’eccezione. - Ricalcolare i digest: recuperate il contenuto della fonte alla versione registrata e ricalcolate il digest del risultato o il checksum.
- Verificare la tempistica: confermate che ogni lettura precede la decisione e che la versione della fonte era corrente al momento della lettura.
- Verificare l’autorizzazione: confrontate ogni fonte e ogni record con il confine dei dati e la finalità in vigore per l’esecuzione.
- Verificare le etichette: confermate che i fatti con fonte modello siano stati mostrati al revisore umano come scritti dall’agente.
Domande frequenti
Come posso verificare da dove un agente IA ha preso le informazioni su un cliente?
Prendete una decisione, elencate ogni fatto sul cliente che ha usato e riconducete ciascuno a una lettura registrata: la chiamata allo strumento o il documento, la versione del record sorgente e un digest del risultato. Ricalcolate il digest dalla fonte a quella versione. Ogni fatto senza registrazione di lettura, o etichettato come scritto dal modello, è un’eccezione oppure un valore che il revisore deve verificare come affermazione propria dell’agente.
Come verifico quale contenuto ha usato un agente IA per prendere una decisione?
Separate ciò che l’agente ha letto da ciò che ha usato. Gli eventi di lettura mostrano ogni recupero e ogni risultato di strumento; una mappa di provenienza dei campi sulla registrazione della decisione collega ogni valore di output a uno di essi. Campionate le decisioni, ricalcolate i digest e confermate che il contenuto rientrasse nel confine dei dati approvato.
Una traccia LLM mostra cosa ha letto un agente IA?
Solo se la cattura del contenuto è attiva. Nelle convenzioni GenAI di OpenTelemetry, i documenti recuperati, gli argomenti e i risultati degli strumenti e i messaggi di input del modello sono attributi Opt-In. Una traccia predefinita mostra che una lettura è avvenuta, senza registrare il contenuto, la versione della fonte né la sua integrità.
Una registrazione di audit dovrebbe conservare il contenuto letto da un agente o solo un hash?
Conservate un digest nella registrazione sigillata e mantenete il contenuto dove può essere prodotto per l’intero periodo di conservazione: nel sistema sorgente con un riferimento di versione, oppure nell’archivio delle prove quando la fonte è modificabile. Un digest senza contenuto recuperabile non può essere verificato.
Punti chiave
La provenienza di una decisione di un agente si riduce a due registrazioni: un evento per ogni lettura e una mappa da ogni fatto della decisione a una lettura, a un documento o al modello. Mantenete il contenuto recuperabile per tutto il tempo in cui la registrazione deve poter essere verificata, e instradate i recuperi tramite chiamate governate perché vengano registrati. Per il formato della registrazione, partite dallo schema del registro di audit degli agenti IA e dalla registrazione dell’esecuzione degli agenti IA. Per come KLA collega le letture alle decisioni e agli effetti, vedete Execution Lineage.