Prima o poi un agente AI aziendale sbaglia: propone un'azione basata su un dato obsoleto, interpreta male una richiesta, trae una conclusione che il contesto non giustificava. La differenza tra un incidente gestito e un incidente subito non sta nell'evitare l'errore — nessun sistema lo garantisce — ma nell'avere un percorso già deciso per ricostruirlo, correggerlo e trasformarlo in un aggiornamento dei limiti. Questo articolo segue un caso pratico dall'inizio alla fine.
Lo scenario: una proposta errata approvata in fretta
Esempio illustrativo. Il caso seguente è inventato a scopo didattico; non descrive un cliente né un incidente reale.
Venerdì pomeriggio, un'azienda riceve la proposta di revocare l'accesso di rete a un piccolo server che l'inventario segnala come dismesso da mesi. La proposta dell'agente è ordinata: elenca il server, la fonte (l'inventario), l'assenza di traffico recente osservato e la misura — disattivare la regola del firewall che lo raggiunge. Il responsabile, di corsa prima del weekend, approva.
Lunedì mattina il servizio di prenotazione interno non risponde: quel server era stato riattivato due settimane prima per un progetto temporaneo, e nessuno aveva aggiornato l'inventario. La regola del firewall va ripristinata, ma la domanda vera è un'altra: com'è potuto succedere, e come si fa a non ripeterlo?
Ricostruzione: timeline, fonti e autorizzazioni
La prima tentazione dopo un errore è cercare un colpevole: il modello che ha proposto male, il responsabile che ha approvato in fretta, chi non ha aggiornato l'inventario. È una strada sterile, perché l'errore quasi mai vive in un solo punto: vive nella catena. La ricostruzione serve a vedere la catena intera, e per questo occorrono tre elementi conservati mentre gli eventi accadono, non ricostruiti a memoria dopo.
La timeline. Quando è stata formulata la proposta, quando è stata approvata, quando è stata eseguita, quando è emerso il problema. La sequenza temporale mostra subito il primo fatto rilevante del caso: tra proposta e approvazione sono passati pochi minuti, in un orario di chiusura della settimana.
Le fonti. Su quale base l'agente ha ragionato. Qui la risposta è chiara e istruttiva: la fonte era l'inventario, e l'inventario era obsoleto. L'agente non ha inventato nulla — ha usato correttamente un dato scorretto. Questo distingue due tipi di errore che richiedono correzioni diverse: un errore di ragionamento si corregge sui limiti del sistema; un errore di fonte si corregge sul processo che mantiene aggiornata la fonte.
Le autorizzazioni. Chi ha approvato, con quale contesto visibile al momento della decisione. La proposta mostrava l'inventario come fonte, ma non segnalava che il dato era vecchio di mesi né che il server non aveva un proprietario registrato — due segnali che, se visibili, avrebbero potuto suggerire una verifica in più. La responsabilità della decisione resta della persona che approva — ne parliamo nell'articolo su proposta dell'agente, approvazione umana e responsabilità — ma la qualità della decisione dipende da ciò che la persona vede.
Ricostruita la catena, la correzione tecnica è la parte semplice: ripristinare la regola del firewall, verificare che il servizio torni raggiungibile, registrare l'esito. La decisione sulla correzione spetta al responsabile del servizio, non all'agente: il sistema propone il ripristino, la persona autorizza. Vale lo stesso principio del funzionamento ordinario — il silenzio non autorizza, ogni intervento attivo richiede l'approvazione prevista — che è esattamente ciò che rende possibile la ricostruzione: ogni passaggio ha un nome, un orario e un contenuto conservati, come descritto nell'articolo sulla tracciabilità delle azioni degli agenti.
Lezioni apprese: limiti, policy e persone
Un errore ricostruito e corretto non è ancora un errore utile. Lo diventa quando cambia qualcosa nel sistema che lo ha reso possibile. Nel caso illustrato, le lezioni riguardano tre livelli distinti — ed è importante non confonderli, perché ciascuno ha un proprietario diverso.
I limiti operativi. La proposta di revoca può richiedere condizioni più strette: per esempio, nessuna disattivazione se la fonte inventariale supera una certa età o se l'asset non ha un proprietario registrato. Non è una regola universale — la soglia giusta dipende dal rischio e dal ritmo dei cambiamenti della propria azienda — ma il principio sì: un limite si aggiorna quando un caso reale ne mostra il bordo scoperto.
Le policy. Chi mantiene l'inventario? Con quale cadenza si verifica che ciò che risulta dismesso lo sia davvero? Se la fonte è il punto debole, la correzione vive nel processo documentale e organizzativo, non nel modello AI. Un aggiornamento dei limiti senza un aggiornamento del processo che alimenta le fonti lascia la porta aperta allo stesso errore con un dettaglio diverso.
Le persone. L'approvazione del venerdì pomeriggio in tre minuti non è una colpa individuale da punire: è un sintomo. Se approvare in fretta è la norma, il problema è nel carico, negli orari o nella quantità di contesto mostrato — per esempio, l'età della fonte dovrebbe comparire nella proposta senza doverla andare a cercare. La «caccia al colpevole» produce un solo effetto documentato dall'esperienza di chi gestisce incidenti: le persone smettono di segnalare, e gli errori diventano invisibili invece che rari.
Questo ciclo — osservare l'errore, ricostruirlo, aggiornare limiti e processo — è coerente con l'impostazione del NIST AI Risk Management Framework, riferimento volontario del National Institute of Standards and Technology statunitense, che tratta la gestione del rischio AI come attività continua e non come verifica una tantum. Dopo ogni cambiamento rilevante, le verifiche sui limiti vanno ripetute: ne parliamo nell'articolo su come aggiornare un agente AI e riverificarne i limiti.
Il contributo di Odysseus, Mnemosyne e Themis
Nel progetto OverZeus, tre agenti di governance coprono le fasi di questo percorso. Mnemosyne conserva fonti, timeline, proposte, autorizzazioni ed esiti: è ciò che permette la ricostruzione descritta sopra senza affidarsi alla memoria di chi c'era, e segnala le lacune — per esempio una modifica senza approvazione associata — senza inventare ricostruzioni. Va detto chiaramente cosa Mnemosyne non fa: conservare le evidenze non significa annullare gli effetti. Il ripristino di una configurazione è un intervento a sé, che richiede una proposta e un'autorizzazione nuove.
Odysseus coordina il riesame: collega le evidenze, coinvolge i moduli pertinenti e riunisce analisi e proposta di correzione in un piano comprensibile, indicando anche le informazioni ancora mancanti — nel caso illustrato, per esempio, chi aveva riattivato il server e perché l'inventario non lo sapeva. Themis applica i limiti aggiornati fuori dal modello: se la nuova regola dice che una revoca richiede un inventario recente e un proprietario registrato, è il controllo applicativo a fermare la proposta che non li ha, non la buona volontà del modello.
Nessuno dei tre elimina l'errore possibile: lo rendono visibile, ricostruibile e utile. Che è ciò che si può chiedere onestamente a un sistema di governance.
La domanda giusta dopo ogni errore
Dopo un malfunzionamento, la domanda «di chi è la colpa?» chiude la conversazione; la domanda «quale anello della catena ha ceduto?» la apre. Un agente AI ben governato non è quello che non sbaglia mai — è quello i cui errori si possono ricostruire passo per passo, correggere con una decisione umana e trasformare in limiti e processi migliori. Se il tuo sistema non ti permette questa ricostruzione, il problema non è l'errore appena accaduto: è il prossimo.
Vuoi vedere come si ricostruisce un intervento, dalla proposta all'esito? Guarda come vengono presentati e autorizzati gli interventi degli agenti.
Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.