[AI] – La decisione senza storia: quando il log racconta cosa è successo, ma non perché

Alle 10:42 un agente di intelligenza artificiale esegue un comando sul database.

Il sistema registra:

• identità utilizzata;
• data e ora;
• comando eseguito;
• oggetto interessato;
• esito dell’operazione.

Il comando termina correttamente. Nessun errore.

Dopo qualche giorno, però, qualcuno domanda:

Perché è stata eseguita proprio quell’operazione?

Il log può raccontare che cosa è successo, ma potrebbe non contenere la risposta.

Non sappiamo necessariamente:

• quale problema fosse stato rilevato;
• quali evidenze fossero disponibili;
• quali alternative fossero state considerate;
• quale parte della conclusione fosse un fatto e quale un’ipotesi dell’AI;
• chi avesse autorizzato l’intervento;
• quale risultato fosse atteso;
• se l’operazione abbia realmente risolto il problema.

L’azione è registrata. La decisione che l’ha prodotta, invece, non ha più una storia.

Registrare un comando non equivale a documentare una decisione

Il tracciamento tecnico è indispensabile.

La documentazione OpenAI sul tracing degli agenti descrive la possibilità di registrare le risposte del modello, le chiamate agli strumenti, gli argomenti utilizzati, i risultati, la durata e lo stato delle diverse operazioni. OpenAI – Tracing

Anche un database può registrare molte informazioni sulle operazioni eseguite. Oracle, per esempio, definisce l’auditing come il monitoraggio e la registrazione delle attività del database e mette a disposizione lo Unified Audit Trail per consultare gli eventi raccolti. Oracle – Introduction to Auditing

Queste registrazioni possono dirci:

• chi ha eseguito l’operazione;
• quando è stata eseguita;
• quale strumento è stato utilizzato;
• quali parametri sono stati trasmessi;
• quale risposta è stata ricevuta;
• se l’operazione sia terminata correttamente.

Non contengono necessariamente il contesto che ha reso quella decisione ragionevole o autorizzata.

Un audit trail e una traccia dell’agente documentano principalmente gli eventi osservati. La storia decisionale deve collegare quegli eventi alle evidenze, al mandato ricevuto e al risultato che si voleva ottenere.

Un esempio sul database

Immaginiamo che un agente analizzi le prestazioni di un database Oracle e proponga:

ALTER INDEX IND_ORDINI_DATA REBUILD;

L’operatore autorizza l’esecuzione e il comando viene completato.

Nel log rimangono il comando, l’orario e l’esito positivo. Ma, senza una documentazione aggiuntiva, potremmo non sapere:

• quale query presentasse il problema;
• quale piano di esecuzione fosse stato esaminato;
• quali metriche indicassero una criticità;
• perché fosse stato scelto il rebuild;
• se fossero state valutate statistiche, selettività, concorrenza o altre cause;
• quale miglioramento fosse previsto;
• quali misurazioni successive dovessero confermarlo.

Il comando può essere tecnicamente valido e, contemporaneamente, non essere la soluzione corretta per quel problema.

Il suo completamento senza errori dimostra soltanto che Oracle ha accettato ed eseguito l’istruzione. Non dimostra che l’intervento fosse necessario o che abbia migliorato le prestazioni.

Quattro livelli che non devono essere confusi

Per ricostruire un’attività svolta da un agente AI bisogna distinguere almeno quattro livelli.

Livello	Domanda
Traccia operativa	Che cosa ha fatto l’agente?
Provenienza delle evidenze	Su quali dati e fonti si è basato?
Motivazione documentata	Perché ha proposto quella scelta?
Autorizzazione e verifica	Chi ha approvato e quale risultato è stato ottenuto?

Una traccia degli strumenti copre soprattutto il primo livello.

Il secondo riguarda la provenienza delle informazioni. Il W3C descrive la provenance come l’insieme delle informazioni relative a entità, attività e soggetti coinvolti nella produzione di un dato o di un risultato, utilizzabili per valutarne qualità, affidabilità e attendibilità. W3C – PROV Overview

Gli ultimi due livelli appartengono alla governance del processo: decisione, responsabilità, autorizzazione e controllo dell’esito.

Non serve conservare ogni pensiero interno del modello

Documentare una decisione non significa pretendere la registrazione completa di ogni passaggio interno compiuto dal modello.

Una trascrizione estesa del ragionamento potrebbe:

• contenere informazioni riservate;
• aumentare inutilmente la quantità di dati conservati;
• includere passaggi provvisori o non verificati;
• essere difficile da controllare;
• creare l’illusione che una spiegazione dettagliata sia automaticamente corretta.

Serve invece una giustificazione strutturata e verificabile.

L’agente dovrebbe produrre una sintesi che distingua:

• fatti ricavati dalle fonti;
• misurazioni oggettive;
• ipotesi;
• alternative;
• raccomandazione;
• informazioni mancanti;
• rischio della scelta;
• verifica prevista.

Non dobbiamo archiviare tutto ciò che il modello ha elaborato. Dobbiamo conservare ciò che permette a un tecnico competente di verificare la decisione.

La scheda di tracciabilità decisionale

Una possibile soluzione consiste nell’associare alle operazioni rilevanti una scheda sintetica.

La struttura potrebbe contenere:

Campo	Contenuto
Identificativo	Codice univoco della decisione
Richiesta	Obiettivo assegnato dall’utente
Perimetro	Sistemi, dati e oggetti autorizzati
Evidenze	Query, log, metriche e documenti utilizzati
Fatti	Elementi direttamente dimostrati
Ipotesi	Interpretazioni ancora da verificare
Alternative	Soluzioni considerate e non applicate
Raccomandazione	Intervento proposto dall’agente
Rischi	Possibili effetti e condizioni di ripristino
Autorizzazione	Soggetto, data e perimetro dell’approvazione
Azione	Comando o operazione effettivamente eseguita
Risultato atteso	Effetto misurabile previsto
Verifica	Controllo effettuato dopo l’operazione
Esito	Risultato osservato e problemi ancora aperti

Questa scheda è una proposta operativa, non uno standard obbligatorio.

Il suo valore consiste nel collegare ciò che è stato eseguito alle condizioni che ne avevano giustificato l’esecuzione.

Un’autorizzazione senza contesto può diventare ambigua

Immaginiamo che l’utente risponda semplicemente:

Procedi.

La conferma può essere valida nella conversazione in cui viene data. Se viene isolata dal contesto, però, non permette più di capire:

• quale operazione fosse stata autorizzata;
• su quali oggetti;
• con quali limiti;
• fino a quale fase;
• se comprendesse anche modifiche successive;
• quale rischio fosse stato presentato prima della conferma.

Per questo l’autorizzazione dovrebbe essere collegata alla proposta precisa che l’ha preceduta.

Una registrazione più solida potrebbe indicare:

Autorizzata l’esecuzione del comando X sull’oggetto Y, nell’ambiente Z, con verifica W. Non sono autorizzate ulteriori modifiche.

Non serve obbligare l’utente a scrivere ogni volta una formula complessa. È il sistema che dovrebbe conservare il collegamento tra la risposta e la proposta autorizzata.

La documentazione non è soltanto burocrazia

Il NIST AI Risk Management Framework considera la documentazione uno strumento capace di aumentare trasparenza, revisione umana e accountability. Il framework richiede inoltre di rendere chiari ruoli e responsabilità e di documentare modalità di supervisione e limiti del sistema. NIST – AI RMF Core

Il NIST AI RMF è un framework volontario e, alla data di consultazione, risulta in fase di revisione. Non rappresenta quindi un obbligo generale applicabile indistintamente a qualsiasi utilizzo dell’AI. I suoi principi offrono però un riferimento utile per organizzare la governance.

Anche il Regolamento europeo sull’intelligenza artificiale prevede, per i sistemi classificati ad alto rischio, capacità di registrazione automatica degli eventi adeguate a garantirne la tracciabilità. L’articolo 12 collega i log all’identificazione dei rischi, al monitoraggio successivo e al controllo del funzionamento. Regolamento UE 2024/1689 – articolo 12

Questo requisito riguarda uno specifico perimetro normativo e non significa che ogni agente utilizzato in qualsiasi contesto sia automaticamente classificato come sistema ad alto rischio.

Il principio generale rimane comunque utile: più un’azione può produrre conseguenze, più diventa importante poterla ricostruire.

Quando la ricostruzione fallisce

La storia decisionale può diventare inaffidabile in diversi modi.

La motivazione viene scritta dopo l’evento

Se la spiegazione viene ricostruita soltanto quando nasce un problema, potrebbe essere influenzata dal risultato già conosciuto.

La motivazione dovrebbe essere registrata prima dell’esecuzione.

Le fonti sono indicate genericamente

Scrivere “analizzati i log” non permette di ripetere la verifica.

Servono almeno origine, periodo, versione, query o identificativo dell’evidenza pertinente.

Fatti e ipotesi vengono mescolati

“L’indice è la causa del rallentamento” può sembrare un fatto, anche quando deriva soltanto da un’interpretazione.

Una formulazione corretta dovrebbe indicare il grado di certezza:

I dati mostrano tempi elevati sulla query X. Il ruolo dell’indice è un’ipotesi da verificare confrontando i piani di esecuzione.

L’autorizzazione non è collegata alla proposta

Un semplice “sì” conservato fuori dalla conversazione non chiarisce che cosa sia stato approvato.

Il test finale controlla soltanto l’esecuzione

L’assenza di errori non dimostra il raggiungimento dell’obiettivo.

Se l’intervento doveva ridurre il tempo di risposta, la verifica deve misurare il tempo di risposta nelle condizioni concordate.

Dal comando alla decisione verificabile

Un processo più affidabile potrebbe seguire questa sequenza:

Richiesta
   ↓
Perimetro e vincoli
   ↓
Evidenze raccolte
   ↓
Fatti e ipotesi separati
   ↓
Alternative valutate
   ↓
Raccomandazione
   ↓
Autorizzazione collegata alla proposta
   ↓
Azione registrata
   ↓
Verifica del risultato
   ↓
Esito e limiti residui

Ogni passaggio aggiunge una parte diversa della storia.

• Il tracing dell’agente mostra l’attività registrata.
• L’audit del sistema conferma gli effetti realmente osservati.
• La provenienza collega il risultato alle fonti.
• La scheda decisionale conserva motivazione e alternative.
• L’autorizzazione identifica la responsabilità umana.
• La verifica stabilisce se l’obiettivo sia stato raggiunto.

Quanto bisogna registrare?

Non tutte le decisioni richiedono lo stesso livello di documentazione.

Una richiesta informativa priva di effetti esterni può essere gestita con una traccia minima. Una modifica a un database, l’invio di una comunicazione, la pubblicazione di un documento o un’operazione economica richiedono invece evidenze più complete.

La profondità della registrazione dovrebbe dipendere da:

• reversibilità dell’azione;
• sensibilità dei dati;
• impatto economico;
• possibilità di arrecare danni;
• difficoltà di verificare il risultato;
• necessità di attribuire responsabilità;
• obblighi normativi applicabili.

Bisogna anche rispettare il principio di minimizzazione: conservare le evidenze necessarie senza duplicare dati personali, credenziali o informazioni riservate non indispensabili.

Conclusione

Un sistema non diventa realmente tracciabile soltanto perché conserva l’elenco dei comandi eseguiti.

La tracciabilità diventa utile quando permette di collegare ogni azione rilevante:

• alla richiesta che l’ha originata;
• alle evidenze disponibili;
• alle ipotesi dichiarate;
• alle alternative considerate;
• all’autorizzazione ricevuta;
• al risultato atteso;
• alla verifica finale.

Il log ci dice che l’agente ha agito.

La storia decisionale ci permette di capire se avesse ragioni sufficienti, se fosse autorizzato e se l’azione abbia ottenuto il risultato richiesto.

Quando questa storia manca, rimane soltanto una sequenza di operazioni tecnicamente registrate ma difficili da valutare.

E una decisione che non può più essere ricostruita rischia di diventare, con il passare del tempo, una decisione senza responsabile.

Fonti consultate

• OpenAI, Tracing, documentazione ufficiale, consultata il 27 settembre 2026.
• Oracle, Introduction to Auditing, Oracle Database Security Guide 19c, consultata il 27 settembre 2026.
• NIST, AI Risk Management Framework Core, AI Resource Center, consultato il 27 settembre 2026. Il sito segnala che AI RMF 1.0 è in revisione.
• Parlamento europeo e Consiglio dell’Unione europea, Regolamento (UE) 2024/1689, EUR-Lex, consultato il 27 settembre 2026.
• W3C, PROV Overview, W3C Recommendation family, consultato il 27 settembre 2026.