Blog · Guida · 28 ottobre 2026
Una checklist di tracciabilità per agenti di IA in produzione: cosa registrare, cosa firmare, cosa mostrare al revisore
Trasparenza: 100monkeys.ai sviluppa AEGIS, un orchestratore di agenti open source, e cura la lista awesome-agent-traceability citata più sotto. Questa checklist è neutrale rispetto ai fornitori: ogni voce si può soddisfare con strumenti aperti e nessuna richiede i nostri prodotti. L'ha scritta in bozza uno dei nostri agenti di IA e l'azienda l'ha rivista; questa edizione italiana è una traduzione della guida originale in inglese.
Quando un agente di IA agisce su un sistema reale, prima o poi qualcuno chiederà che cosa ha fatto e perché. Questa checklist è il lavoro da fare prima che arrivi la domanda: cosa registrare a ogni esecuzione, cosa firmare perché il log sia affidabile e cosa mettere davanti alla persona che lo esamina. Ogni voce indica uno standard o uno strumento aperto della lista awesome-agent-traceability.
Il quadro viene dal nostro paper Red levers: traceable, deterministic agents in production (in inglese), che definisce sicuro in produzione un sistema di agenti quando una persona può vedere ogni decisione che ha preso, il perché, e fermarlo. Il logging serve la prima cosa, il motivo registrato la seconda, il passaggio di revisione la terza.
Parte 1. Cosa registrare
Passo 1. Dare un'identità a ogni esecuzione
Assegnate a ogni esecuzione un id all'inizio e portatelo con sé in ogni chiamata al modello, chiamata a strumento ed effetto collaterale. Senza, un log è un mucchio di eventi che nessuno sa raggruppare. Usate gli id di trace e di span delle convenzioni semantiche OpenTelemetry per l'IA generativa, che definiscono nomi condivisi per chiamate al modello, passi dell'agente e invocazioni di strumenti, così che le tracce di framework diversi si leggano allo stesso modo. Le convenzioni per gli span degli agenti coprono la creazione e l'invocazione degli agenti.
Passo 2. Registrare la richiesta e l'intento, a parole
Registrate cosa è stato chiesto all'agente, da chi e con quale motivazione. Poi, a ogni atto con conseguenze, registrate la frase con cui l'agente stesso spiega il perché. Un motivo scritto nel momento dell'atto è una prova; un motivo ricostruito dopo è un racconto.
Passo 3. Registrare il modello e le sue impostazioni
Per ogni chiamata al modello: provider, nome e versione del modello, i parametri che cambiano l'output (temperature, massimo di token, strumenti offerti) e il conteggio dei token. Un comportamento che non si può legare a una versione del modello non si può riprodurre dopo che il provider lo aggiorna.
Passo 4. Registrare ogni chiamata a strumento con input e output
Nominate lo strumento, gli argomenti, il risultato e l'ora. Oscurate i dati personali prima di salvarli, non dopo; Presidio è un'opzione aperta. Una chiamata che ha scritto da qualche parte dovrebbe anche registrare cosa ha cambiato: il diff, l'id del record, l'id del messaggio.
Passo 5. Registrare ogni decisione di policy
Se un motore di policy ha permesso o rifiutato una chiamata, registrate la decisione e la regola che l'ha presa. Open Policy Agent tiene log delle decisioni proprio per questo. Un rifiuto è importante da conservare quanto un permesso: mostra che il limite ha tenuto.
Passo 6. Registrare identità e portata
Registrate quale credenziale o token ha usato l'esecuzione e cosa quella credenziale poteva raggiungere, non il suo valore segreto. La domanda del revisore è spesso "poteva fare di peggio?", e la risposta è la portata che aveva.
Passo 7. Rendere l'esecuzione riproducibile
Conservate abbastanza per rieseguire il lavoro: gli input, lo stato a ogni passo e l'ordine degli eventi. I motori di esecuzione durevole come Temporal conservano una cronologia degli eventi del workflow che permette di rieseguirlo in modo deterministico.
Parte 2. Cosa firmare
Passo 8. Rendere il log append-only e concatenato
Un registro che si può riscrivere a posteriori non prova nulla. Scrivete gli eventi in un archivio append-only e concatenate ogni voce alla precedente tramite hash, così che una voce rimossa o modificata spezzi la catena. Il gruppo di lavoro IETF SCITT definisce dichiarazioni firmate registrate in servizi di trasparenza append-only, una forma già pronta per questo.
Passo 9. Firmare ciò che l'agente ha prodotto
Quando un'esecuzione produce un artefatto (una build, un report, un file rilasciato), allegate una dichiarazione firmata di come è stato fatto. L'in-toto Attestation Framework trasporta dichiarazioni di questo tipo, e SLSA definisce livelli di provenienza della build. Per i contenuti multimediali, la specifica C2PA allega manifesti di provenienza firmati, anche per contenuti prodotti o modificati dall'IA.
Passo 10. Firmare l'approvazione
Se una persona ha approvato un atto, registrate chi l'ha approvato, quando e che cosa esattamente ha visto. Legate l'approvazione al contenuto: se l'atto cambia dopo l'approvazione, l'approvazione non vale più.
Parte 3. Cosa mostrare al revisore
Passo 11. Mostrare l'atto, non un riassunto
Il revisore dovrebbe vedere l'e-mail, il diff o il comando che verrà eseguito, resi a partire dall'output stesso dell'esecuzione. Un riassunto scritto dallo stesso modello che vuole l'approvazione non è una superficie di revisione.
Passo 12. Mostrare il motivo accanto all'atto
Mettete l'intento registrato dall'agente accanto alla modifica che ha fatto. "Perché questa riga è qui" dovrebbe trovare risposta nella frase scritta quando la riga è stata integrata.
Passo 13. Mostrare i limiti in cui ha operato
Mostrate la policy e la portata delle credenziali accanto all'esecuzione. Un revisore che vede che l'agente poteva scrivere solo su un branch legge l'esecuzione in modo diverso da uno che deve presumere che potesse raggiungere tutto.
Passo 14. Dare al revisore un modo per fermare
Ogni schermata di revisione ha bisogno di un modo per rifiutare, e il rifiuto deve tenere. L'articolo 14 dell'AI Act dell'UE, come citato in Red levers, chiede che le persone che sorvegliano i sistemi ad alto rischio possano "intervene in the operation of the high-risk AI system or interrupt the system" (intervenire sul funzionamento del sistema di IA ad alto rischio o interromperlo). Citarlo qui riguarda la forma del controllo, non una dichiarazione di conformità.
Verificarsi da soli
Prendete un'esecuzione della settimana scorsa e provate a rispondere solo con i registri: chi l'ha chiesta, cosa ha chiamato l'agente, cosa ha cambiato, con quale policy, chi ha approvato e se il registro avrebbe potuto essere modificato nel frattempo. Ogni domanda a cui non sapete rispondere corrisponde a un passo qui sopra.
Come lo applichiamo
Costruiamo strumenti per parti di questa lista. AEGIS by 100monkeys.ai, in beta, è un orchestratore self-hosted che esegue agenti in runtime isolati, con policy applicate e stato persistente; How to give an orchestrator an approval step (in inglese) mostra il suo gate di approvazione come esempio concreto, e questa guida all'installazione lo mette in funzione su un server. Carbon Forge tiene codice e testo in un unico registro, dove il blame mostra l'intento scritto al momento dell'integrazione.