Da qualche parte nel tuo stack, un agente ha già prodotto il numero che un giorno si troverà davanti a un revisore. Ha calcolato la cifra — o l'ha generata; potresti non saperlo — qualcuno l'ha incollata in una presentazione, e la presentazione è stata distribuita. Mesi dopo arriva la domanda che ogni sistema AI in produzione riceve prima o poi: da dove viene questo numero, e lo otterremmo di nuovo oggi?
La maggior parte dei team risponde con una trascrizione. In un sondaggio del primo trimestre 2026 su 420 organizzazioni che eseguono agenti AI in produzione, solo il 17% era in grado di ricostruire a posteriori la sequenza completa di chiamate agli strumenti, input e output di uno specifico task dell'agente (AgentNode, 2026). L'83% restante disponeva di log parziali, nessun log, o log che catturavano il ragionamento del modello ma non ciò che aveva effettivamente invocato. Una trascrizione e una sensazione.
Il registro sta diventando legge
Per un certo periodo si è trattato di un imbarazzo ingegneristico. Sta per diventare un problema legale.
L'EU AI Act richiede che i sistemi AI ad alto rischio consentano tecnicamente — integrato nella progettazione, non aggiunto in seguito — «la registrazione automatica degli eventi (log) per tutta la durata del sistema» (European Commission, 2024). La tenuta manuale dei registri non soddisfa l'articolo 12. I log devono essere sufficientemente dettagliati da identificare situazioni che possono presentare rischi o modifiche sostanziali, supportare il monitoraggio post-commercializzazione e documentare il funzionamento effettivo del sistema. Per il riconoscimento biometrico remoto, l'articolo indica esplicitamente il minimo: ogni periodo di utilizzo, il database di riferimento consultato, i dati di input che hanno portato a una corrispondenza, le persone fisiche che hanno verificato il risultato. Non si tratta di «conservare qualche log». Si tratta di ricostruire la decisione.
Le date sono vicine. L'Atto è entrato in vigore il 1° agosto 2024; i divieti si applicano da febbraio 2025, gli obblighi per i modelli di uso generale da agosto 2025 — e gli obblighi per i sistemi ad alto rischio, articolo 12 incluso, si applicano dal 2 agosto 2026 (Future of Life Institute, 2026). Otto giorni dalla data di questo articolo. I sistemi ad alto rischio integrati in prodotti regolamentati (Allegato I) seguiranno nell'agosto 2027.
Anche la conservazione ha un limite minimo. I fornitori devono conservare i log generati automaticamente per almeno sei mesi, e l'articolo 26(6) pone il medesimo obbligo speculare sui deployer — più a lungo laddove altre normative come il GDPR lo richiedano, e in ogni caso in misura adeguata alla finalità prevista del sistema, non solo al minimo (artificialintelligenceact.eu, 2024).
Nulla di tutto ciò arriva nel vuoto. L'articolo 30 del GDPR richiede registrazioni scritte delle attività di trattamento — finalità, categorie di dati, destinatari, termini di cancellazione, misure di sicurezza — dal 2018, producibili all'autorità di controllo su richiesta (gdpr-info.eu, 2016). Il CC7.2 di SOC 2 richiede di monitorare i componenti del sistema per rilevare anomalie e analizzare i risultati; il CC7.3 richiede di valutare se un evento abbia compromesso gli obiettivi (AICPA, 2022). In un audit di Tipo II tali criteri vengono verificati rispetto a prove documentali che coprono l'intero periodo di revisione — tipicamente dodici mesi (AgentNode, 2026) — non uno screenshot del giorno in cui il revisore ha effettuato la visita.
Perché «loggare di più» non basta
La risposta istintiva è la verbosità: attivare il tracing, conservare tutto, acquistare una dashboard. Tre problemi sopravvivono a questo approccio.
Le trascrizioni registrano ciò che è stato detto, non ciò che è stato eseguito. Un log di chat è il modello che narra il proprio comportamento. Tra l'83% citato sopra, un gruppo è esattamente questo: ragionamento catturato, invocazioni agli strumenti no. Quando la narrazione e l'esecuzione divergono, la trascrizione mantiene un'espressione impassibile — calcolato e generato si leggono in modo identico sulla pagina. Non sono la stessa cosa.
Un log che non puoi rieseguire è una testimonianza, non una prova. Anche i team che catturano ogni chiamata agli strumenti di solito non riescono a eseguirne una di nuovo e confrontarla, perché nulla ha fissato il contesto in cui è stata eseguita. L'SQL è stato generato quel giorno, su un database che nel frattempo è cambiato; l'aritmetica è stata campionata da un modello che non è mai stato stabile in partenza. Conservare tutto ciò per sei mesi — o dodici — significa conservare affermazioni più a lungo, non renderle verificabili. La formulazione dell'articolo 12 è precisa: il sistema deve tecnicamente consentire la registrazione. La riproducibilità che non è stata progettata ab initio non può essere aggiunta in seguito da una libreria di logging.
I metadati non sono correttezza. Il record di audit minimo vitale — sei campi fondamentali, tra cui trace ID, timestamp e identità dell'agente (AgentNode, 2026) — stabilisce chi e quando. Non dice nulla su se il numero fosse corretto, o se verrebbe fuori uguale oggi. La ricerca sull'osservabilità degli agenti LLM giunge alla stessa conclusione: la tracciabilità deve coprire gli artefatti dell'intero ciclo di vita dell'agente, non solo i messaggi (CSIRO Data61, 2024).
Il fallimento è strutturale. L'esecuzione in forma libera — un modello che emette stringhe che qualcos'altro esegue — non produce nulla di abbastanza stabile da registrare, indipendentemente da quanto se ne scriva.
La provenienza come proprietà del risultato
La risposta di SQAI è rendere il registro una proprietà dell'esecuzione piuttosto che una funzionalità del logging. Ogni risultato eseguito porta quattro hash, ciascuno dei quali risponde a una distinta domanda di audit:
contract_hash— cosa poteva essere eseguito: l'esatto contratto di capability in vigore (sha256:79f1c5a6c716…).plan_hash— a cosa si è risolto la richiesta: il piano validato, con la sua risoluzione registrata (decision_path: "exact_spec").invocation_hash— cosa è stato eseguito, su cosa: la capability più gli input canonicalizzati, incluso uninput_hashdei dati così come si trovavano.computation_hash— cosa è uscito: legato all'invocazione e al valore insieme.
Le costruzioni sono domain-separated, così nessun artefatto può impersonarne un altro:
invocation_hash = sha256("sqai:invocation:v1\0" + canonicalJson(identity))
computation_hash = sha256("sqai:computation:v1\0" + invocation_hash + canonicalJson(value))
Accanto agli hash viaggia l'envelope di determinismo — l'ambiente di esecuzione registrato: runtime_bundle_version 0.1.0 e il suo sha256, piattaforma e architettura, precision_mode: float64, thread_count: 1, e il seed dove richiesto. Le dieci capability di simulazione che ne hanno bisogno si rifiutano di essere eseguite senza — seed_required, non una risposta silenziosamente diversa. Tutto ciò che potrebbe modificare il numero è o fissato o documentato.
Ecco cosa comporta concretamente. A marzo, un agente calcola un valore attuale netto:
finance.npv(0.1, [-1000, 300, 420, 560, 680])
→ 505.020148896933
computation_hash b74f67d0d7a594aa…
A luglio, il revisore chiede. Riproduci l'invocazione — stessa spec tipizzata, stesso runtime fissato — e confronti gli hash: b74f67d0d7a594aa… di nuovo, identico byte per byte. Non importa se la riproduzione viene eseguita in TypeScript o Python. canonicalJson e canonical_json sono un contratto di serializzazione cross-linguaggio — chiavi ordinate, -0 normalizzato a 0, escaping unicode fisso — così lo stesso valore produce gli stessi byte e lo stesso hash in entrambi. La pagina sul determinismo mostra due di questi envelope, a mesi di distanza, affiancati.
E quando la riproduzione non corrisponde, quello è un segnale. Una sorgente modificata fallisce in modo esplicito con schema_revision_mismatch — il motore si rifiuta di calcolare silenziosamente un numero diverso su dati diversi e di attribuirlo al passato. Il mismatch indica cosa è cambiato.
Ricondotto agli obblighi. Registrazione automatica per tutta la durata del sistema: ogni risultato eseguito si registra da solo, per costruzione — non esiste un percorso non registrato, perché la superficie di esecuzione è composta da 4.574 capability di sola lettura con input tipizzati, non da stringhe in forma libera. Sei o dodici mesi di conservazione: conserva gli envelope dei risultati; la conservazione diventa una decisione di storage invece che un'operazione archeologica. Prove che coprono un periodo di revisione SOC 2: gli artefatti sono la prova — la risposta al revisore è una riproduzione, non un'indagine. La stessa pipeline produce il registro per ogni capability, e l'audit trail persistente è incluso nel tier Pro di SQAI.
Otto giorni, poi ogni audit successivo
La data di agosto vincola formalmente i sistemi ad alto rischio nell'UE. Ma scadenze come questa stabiliscono il modello per ogni revisione successiva — il revisore SOC 2, il questionario di procurement, il tuo stesso CFO a marzo che chiede di un numero di gennaio. Agli agenti verrà chiesto di giustificare le proprie risposte come si fa con i dipendenti: con i registri. La maggior parte degli stack non è in grado di produrli, perché SQL generato e aritmetica campionata non lasciano nulla di abbastanza stabile da registrare — un problema che inizia ben prima dell'audit.
Una risposta che puoi riprodurre è una risposta che puoi difendere. Tutto il resto è uno screenshot.