L’osservabilità LLM e l’audit trail di un agente AI possono condividere un trace ID e rispondere comunque a domande diverse. Una traccia di osservabilità registra come si è svolta una chiamata al modello o un passaggio dell’agente: l’operazione, il modello, il numero di token, la latenza, gli errori e, se l’acquisizione dei contenuti è attiva, i messaggi. Un audit trail di livello audit registra perché un’azione è stata consentita, chi aveva autorità su di essa, quale versione della policy l’ha decisa, che cosa ha modificato lo strumento e come chiunque può verificare il record in seguito. Per un sistema ad alto rischio ai sensi dell’AI Act, l’audit trail garantisce la tracciabilità richiesta dall’articolo 12, e la traccia aiuta gli ingegneri a far funzionare il sistema.
Questa guida confronta i due record campo per campo, registra un’azione sintetica in entrambi i modi, espone che cosa chiede l’AI Act ai log ed elenca che cosa aggiungere a uno stack di osservabilità. Il framework di audit degli agenti AI aziendali colloca il record nel metodo di audit completo, e la sua carta di lavoro di audit compilata verifica un’azione dal permesso all’esito.
Che cosa registra l’osservabilità LLM
Molti strumenti di osservabilità LLM emettono o acquisiscono dati OpenTelemetry. Le convenzioni semantiche OpenTelemetry per l’AI generativa definiscono span per inferenza, embedding, retrieval, memoria ed esecuzione di strumenti, con attributi come gen_ai.operation.name, gen_ai.provider.name, gen_ai.request.model, gen_ai.usage.input_tokens e gen_ai.tool.name. Le convenzioni sono in stato Development, quindi i nomi possono ancora cambiare.
In queste convenzioni i contenuti sono Opt-In. Input e output del modello (gen_ai.input.messages, gen_ai.output.messages), argomenti e risultati degli strumenti (gen_ai.tool.call.arguments, gen_ai.tool.call.result) e documenti recuperati (gen_ai.retrieval.documents) vengono registrati solo se qualcuno li abilita. Una traccia con le impostazioni predefinite può mostrare che uno strumento è stato eseguito e quanto tempo ha impiegato, senza alcuna traccia di che cosa gli è stato chiesto o di che cosa ha restituito.
Questi dati servono bene all’ingegneria: trovare un passaggio fallito, un retrieval lento o un prompt costoso, confrontare versioni dei prompt. L’uso ingegneristico spiega anche le scelte abituali di archiviazione: campionamento per contenere i volumi, retention fissata in base al costo dello storage, archivi che gli operatori possono modificare o svuotare.
Abbiamo incontrato il divario tra i due record nel nostro prodotto. In una proof of concept di onboarding esercenti a settembre, la cronologia del caso collegava ogni passaggio a Lineage Explorer, e i link mostravano «Trace not found» per un’esecuzione in pausa su una firma di approvazione. L’esecuzione pubblicava i propri span solo al termine, mentre la ricevuta del gate per la decisione in sospeso esisteva già. Abbiamo modificato Lineage Explorer perché, quando nessuna traccia è stata pubblicata, legga dal record di esecuzione i passaggi registrati fino a quel momento e indichi che l’esecuzione non è terminata.
Che cosa aggiunge un audit trail di livello audit
Un auditor, un’autorità di vigilanza o un team legale che esamina una singola azione di un agente pone domande a cui una traccia non è progettata per rispondere. La tabella associa ogni domanda a un tipico campo di osservabilità e al campo che risponde nello schema di audit log per agenti AI, indipendente dai fornitori.
| Domanda dell’auditor | Campo di osservabilità tipico | Campo dell’audit trail (audit event v1) | Lacuna nella traccia |
|---|---|---|---|
| Per conto di chi ha agito l’agente, e chi risponde dell’esito? | gen_ai.agent.name, gen_ai.conversation.id, nome del servizio | actors.requester, actors.delegated_user, actors.service_identity, actors.accountable_owner | La traccia indica il processo dell’agente e raramente la persona che ha delegato o il responsabile |
| Quale release era in esecuzione? | gen_ai.request.model, gen_ai.response.model | components.agent.version, components.model.version, components.prompt_template.version, ciascuno con configuration_digest | Il solo nome del modello non riconduce a una release approvata di agente, prompt e orchestratore |
| Quale policy ha deciso, ed è stata verificata prima dell’azione? | Nessuno span GenAI per le decisioni di policy | policy.policy_id, policy.policy_version, policy.policy_digest, policy.inputs_digest, policy.decision, policy.matched_rule_ids, policy.evaluated_at | I controlli di policy compaiono, se compaiono, come span personalizzati senza un significato fisso |
| Ha approvato una persona con l’autorità per farlo? | Nessuno span GenAI per le approvazioni | approval.required_role, approval.reviewer, approval.decision, approval.decided_at, approval.presented_evidence_digest | La traccia non può mostrare che cosa ha visto il revisore né se aveva il ruolo richiesto |
| Che cosa ha modificato lo strumento? | gen_ai.tool.name, gen_ai.tool.call.id; argomenti e risultato se abilitati | tool_calls[].arguments_digest, result_digest, idempotency_key, downstream_effects[].before_state_digest, after_state_digest | Nessun collegamento tra la chiamata e la modifica di stato nel sistema di riferimento |
| Ogni azione è presente nella popolazione? | Tracce campionate | sequence, lineage.ordered_event_ids, riconciliazione con il sistema di origine | Il campionamento scarta record per costruzione |
| Il record è cambiato da quando è stato scritto? | Nessuno | integrity.record_hash, integrity.previous_event_hash, integrity.signature | Gli archivi delle tracce sono di solito modificabili e scadono secondo un calendario di storage |
Un’azione sintetica, registrata in entrambi i modi
L’agente di credito di una banca fittizia registra una decisione su un credito di EUR 24,000. La traccia di osservabilità del passaggio dello strumento è questa. I valori sono sintetici.
{
"name": "execute_tool set_disposition",
"trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
"span_id": "00f067aa0ba902b7",
"start_time": "2026-07-21T09:14:31.944Z",
"end_time": "2026-07-21T09:14:32.433Z",
"attributes": {
"gen_ai.operation.name": "execute_tool",
"gen_ai.tool.name": "set_disposition",
"gen_ai.tool.call.id": "call_01JZ8V4R1E7P3M9C5Q2T6N8D0A",
"gen_ai.agent.name": "Credit review agent"
},
"status": "OK"
}L’audit event della stessa azione
L’audit event della stessa chiamata è il record di esecuzione completo sintetico pubblico. Contiene gli stessi trace_id e span_id, quindi i due record si collegano. Aggiunge ciò che manca allo span: l’utente delegante e il responsabile, la policy credit-disposition-policy 4.2.1 che restituisce require_approval con la regola manual-review-above-20000, l’approvazione del senior underwriter alle 09:14:31.902Z prima della chiamata delle 09:14:31.944Z, i digest di argomenti e risultato, i digest dello stato prima e dopo nel core banking, l’esito di business e un hash del record con firma Ed25519.
Un auditor può verificare la firma, controllare che l’approvazione abbia preceduto la chiamata, rieseguire la policy sugli input registrati e seguire il riferimento all’effetto fino al core banking. Con il solo span, l’auditor può confermare che uno strumento chiamato set_disposition ha restituito un risultato senza errori.
Che cosa chiede l’AI Act ai log
L’articolo 12, paragrafo 1, dell’AI Act impone che i sistemi di IA ad alto rischio consentano tecnicamente la registrazione automatica degli eventi per tutta la durata del ciclo di vita del sistema. L’articolo 12, paragrafo 2, collega tale registrazione all’individuazione di situazioni che possono presentare un rischio o determinare una modifica sostanziale, al monitoraggio successivo all’immissione sul mercato e al monitoraggio del funzionamento da parte del deployer. L’articolo 12, paragrafo 3, fissa campi minimi solo per i sistemi di identificazione biometrica remota.
L’articolo 19, paragrafo 1, impone ai fornitori di conservare i log generati automaticamente sotto il loro controllo per almeno sei mesi, salvo diversa disposizione del diritto dell’Unione o nazionale. L’articolo 26, paragrafo 6, fissa lo stesso minimo per i deployer. Le misure correttive sono all’articolo 20; il sistema di gestione della qualità, comprese le procedure di conservazione delle registrazioni, all’articolo 17.
Per la maggior parte dei sistemi ad alto rischio, l’AI Act lascia al fornitore l’elenco dei campi. Per un agente, la tracciabilità di una decisione significa di solito i campi su attori, release, policy, approvazione, effetto dello strumento ed esito della tabella precedente. Il regolamento (UE) 2026/1744, pubblicato il 24 luglio 2026, ha spostato la data di applicazione per i sistemi ad alto rischio dell’articolo 6, paragrafo 2, e dell’allegato III al 2 dicembre 2027, e per i sistemi dell’articolo 6, paragrafo 1, e dell’allegato I al 2 agosto 2028. La guida all’articolo 12 sulla registrazione tratta l’obbligo in dettaglio.
I quattro livelli di un evidence pack
Un evidence pack raccoglie l’audit trail di una decisione o di un periodo, in modo che un revisore possa verificarlo fuori dal sistema che lo ha prodotto. L’esempio di Evidence Room mostra un export.
- Record decisionale: identificativo, ora, tipo di decisione, esito e classificazione del rischio. Ogni altro artefatto vi fa riferimento.
- Contesto degli input: che cosa ha letto l’agente, con riferimenti e versioni delle fonti; le versioni di modello, prompt e policy in vigore. Come dimostrare che cosa ha letto un agente AI descrive il record di lettura.
- Evidenze di governance: decisioni di policy con le regole corrispondenti, Decision Request con revisore e motivazione, escalation e override.
- Integrità: un manifest degli artefatti con digest SHA-256, firme, ancoraggi temporali e catena di custodia, perché un revisore possa verificare il pacchetto offline.
Pattern architetturali per record di livello audit
Questi pattern stanno sul percorso dell’azione. Richiedono che l’agente chiami gli strumenti attraverso un checkpoint in grado di valutare la policy e registrarne il risultato.
Un campo che manca quando un record viene sigillato non può essere aggiunto dopo. All’inizio di settembre 2026 un’analisi del codice della nostra piattaforma ha rilevato che alcuni record decisionali interni alla piattaforma e alcune ricevute sigillate non indicavano l’agente che aveva agito. Le ricevute sigillate non si possono integrare a posteriori, quindi ogni giorno senza quel campo aggiungeva record che un auditor non avrebbe potuto ricondurre a un agente. Abbiamo aggiunto l’identità dell’agente ai record decisionali e alle ricevute sigillate dei gate entro due giorni. Definite l’elenco dei campi prima del primo record in produzione.
- Scrivere al momento della decisione: registrare la decisione di policy prima che l’azione proceda e l’approvazione prima della chiamata allo strumento. Un record ricostruito in seguito dai log non può dimostrare l’ordine in modo affidabile.
- Storage append-only: archiviare gli eventi dove le voci esistenti non possono essere modificate né cancellate, e concatenare ogni record al precedente tramite hash.
- Firmare e sigillare: firmare ogni record e sigillare gli export con un manifest e una firma che un revisore può verificare con chiavi pubblicate.
- Mantenere i contenuti recuperabili: un digest prova una corrispondenza solo se il contenuto può essere prodotto in seguito. Conservare la versione della fonte o una copia protetta per tutto il periodo di retention.
- Registrare ciò che serve al replay: input della decisione, versione fissata della policy e output del modello registrato. Replay deterministico delle decisioni degli agenti AI elenca l’insieme completo e i suoi limiti.
- Collegarsi alla telemetria: riportare
trace_idespan_idnell’audit event, così ingegneri e auditor possono passare da un record all’altro.
Costruire il livello delle evidenze su uno stack di osservabilità
I team che hanno già il tracing possono aggiungere il livello delle evidenze per fasi.
- Fase 1, definire le domande: elencare i tipi di decisione con esposizione di audit o legale e le domande che un auditor porrà su ciascuno.
- Fase 2, posizionare i checkpoint: far passare le chiamate rilevanti agli strumenti da un checkpoint di policy che registri i campi su attore, release, policy, approvazione ed effetto.
- Fase 3, proteggere l’integrità: spostare gli audit event su storage append-only con hashing, firme ed export sigillati.
- Fase 4, verificare il record: campionare azioni, verificare le firme, riconciliare la popolazione e riprodurre le decisioni. La checklist di audit degli agenti AI e la carta di lavoro di audit forniscono i test.
Domande frequenti
Gli strumenti di osservabilità LLM possono fungere da audit trail ai sensi dell’AI Act?
Le tracce di osservabilità ne coprono una parte. Nelle convenzioni GenAI di OpenTelemetry i contenuti sono Opt-In e non esistono span per decisioni di policy o approvazioni. Un audit trail conforme all’AI Act per un agente richiede anche la persona delegante, la versione e l’esito della policy, l’approvazione, l’effetto dello strumento sul sistema di riferimento, la completezza della popolazione e l’evidenza di manomissione. Collegate la traccia a un audit event che contenga questi campi.
Come si creano audit trail per le azioni degli agenti AI?
Assegnate un unico identificativo di esecuzione e registrate le identità dell’agente e delle persone, le versioni delle release, ciò che l’agente ha letto, chiamate e risultati degli strumenti, decisioni di policy, approvazioni, output, effetti collaterali e timestamp. Scrivete i record al momento della decisione su storage append-only e sigillate gli export con un manifest e firme.
Come si verificano e riproducono le decisioni degli agenti AI?
Selezionate un’esecuzione da una popolazione riconciliata, verificatene l’integrità, risalite alla versione della policy registrata e rieseguite la policy sugli input registrati senza accesso agli strumenti. Confrontate esito e regole corrispondenti con il record. Verificate separatamente l’effetto esterno dello strumento sul sistema a valle, perché una decisione riprodotta non lo dimostra.
Che cos’è un evidence pack?
Un evidence pack raccoglie il record decisionale, il contesto degli input, le evidenze di governance e il materiale di integrità di una decisione o di un periodo, perché un revisore possa verificarlo fuori dal sistema che lo ha prodotto.
Quali articoli dell’AI Act riguardano i log?
L’articolo 12 impone la registrazione automatica degli eventi per i sistemi ad alto rischio. L’articolo 19, paragrafo 1, e l’articolo 26, paragrafo 6, impongono a fornitori e deployer di conservare i log sotto il loro controllo per almeno sei mesi, salvo diversa disposizione di legge. L’articolo 17 riguarda il sistema di gestione della qualità, compresa la conservazione delle registrazioni.
Che cos’è lo storage append-only e perché conta?
Lo storage append-only accetta nuovi record e rifiuta modifiche e cancellazioni di quelli esistenti. Con la concatenazione tramite hash e le firme, permette a un revisore di rilevare qualsiasi modifica al trail dopo la scrittura.
Punti chiave
Usate l’osservabilità per far funzionare il sistema e aggiungete un audit event sul percorso dell’azione per dimostrare come è stata governata una decisione. Collegate i due record tramite trace ID. Per ogni azione rilevante registrate che cosa ha letto l’agente, la versione della policy, l’approvazione, l’effetto e una prova di integrità. Usate la checklist di audit degli agenti AI per verificare quei record, la valutazione di preparazione per trovare le lacune ed Execution Lineage per vedere come KLA collega i record di un’esecuzione.