[AI] - Il rollback che non può annullare le conseguenze

 L’AI ha ripristinato il file precedente. Il controllo conferma che i dati sono tornati al loro posto. Intanto, qualcuno sta ancora lavorando sulla comunicazione sbagliata ricevuta poco prima.

È una situazione nella quale il recupero tecnico può essere riuscito e il problema operativo essere ancora aperto. La frase «abbiamo fatto rollback» descrive una parte di ciò che è accaduto. Per capire se il lavoro è davvero recuperato, occorre seguire anche gli effetti usciti dal sistema.

Il foglio torna corretto, il fornitore ha già organizzato la consegna

Immaginiamo un assistente AI autorizzato ad aggiornare un prospetto delle consegne e a inviare le conferme ai fornitori, dopo i controlli concordati. Nel file di partenza una colonna contiene disponibilità provvisorie. L’assistente le interpreta come definitive e comunica una data di ricezione che l’ufficio non è ancora in grado di garantire.

Il responsabile individua l’errore. L’assistente ripristina il prospetto precedente, confronta i valori e riferisce: «Ripristino completato».

Nel frattempo un fornitore potrebbe aver riservato un mezzo, un magazziniere preparato lo spazio e un collega aggiornato il proprio programma. Ripristinare il file non aggiorna automaticamente chi lo ha già usato.

Serve quindi un secondo lavoro: identificare le comunicazioni partite, verificare quali siano state ricevute e utilizzate, concordare le rettifiche e accertare che le attività dipendenti siano state riallineate. Una parte del tempo già impiegato potrebbe non essere recuperabile.

Lo scenario è didattico e costruito per questo articolo. Non descrive un incidente reale, un cliente o un risultato misurato.

Che cosa copre davvero un rollback

Nel linguaggio dei database, il rollback ha un significato preciso. All’interno di una transazione ancora aperta può annullare le modifiche comprese in quella transazione, invece di confermarle. La documentazione Oracle Database descrive il comando ROLLBACK come annullamento delle modifiche della transazione corrente. Il ripristino di un file o di un backup è un’operazione diversa: va descritto indicando quali contenuti, versioni e sistemi coinvolge. [1]

In un’attività assistita dall’AI, una sola richiesta può attraversare confini differenti:

Parte del lavoro	Che cosa verificare dopo la correzione
Prospetto locale	La versione corretta è stata recuperata? Sono stati preservati eventuali aggiornamenti legittimi successivi?
Registrazioni in un servizio	Quali operazioni risultano effettivamente completate e quali richiedono una correzione specifica?
Comunicazioni inviate	Chi le ha ricevute? Esistono inoltri o risposte? Quali rettifiche servono?
Attività delle persone	Qualcuno ha già organizzato il proprio lavoro sulla base dell’informazione errata?

Questa tabella è una proposta di controllo per lo scenario, non un elenco di operazioni automaticamente annullabili. Un confronto tra file può rispondere alla prima domanda; non dimostra, da solo, che il fornitore abbia fermato la consegna.

Rimediare può richiedere nuove azioni

Nei sistemi distribuiti si usano anche azioni di compensazione: operazioni aggiuntive che affrontano gli effetti di passaggi già completati. Oracle Database documenta il modello Saga e distingue le compensazioni automatiche supportate dal database dalle azioni di finalizzazione definite dall’applicazione. Il recupero richiede quindi di specificare quali effetti trattare e con quali operazioni. [2]

Nel nostro esempio, una rettifica al fornitore sarebbe un’azione di recupero. L’effetto concreto dipende però da ciò che il fornitore può ancora cambiare. Non possiamo dedurre dal solo invio della rettifica che ogni conseguenza sia stata eliminata.

Anche le funzioni di richiamo delle email hanno condizioni e limiti. Microsoft distingue la richiesta di richiamo dal suo esito e prevede una comunicazione che indica se il tentativo è riuscito. La disponibilità del comando non va quindi trattata come una garanzia universale di recupero. [3]

L’agente dovrebbe rendere esplicito questo confine: «Il prospetto è stato ripristinato. La comunicazione risulta già inviata. La rettifica è predisposta, ma non inviata; gli effetti sul destinatario non sono ancora verificati».

Una dichiarazione del genere consente a chi supervisiona di decidere che cosa fare. «Tutto risolto» nasconderebbe invece attività ancora necessarie.

Ripetere una richiesta può aggravare il problema

Esiste un altro caso da distinguere dal rollback: il sistema non risponde e l’AI propone di riprovare. L’assenza di una risposta non dimostra che l’operazione non sia stata eseguita.

Un approfondimento Oracle sugli agenti AI nei processi aziendali spiega che un timeout può lasciare l’esito sconosciuto e che ripartire può duplicare effetti già prodotti. Richiama per questo idempotenza, politiche di ritentativo e tracciamento delle operazioni. L’idempotenza è la proprietà per cui ripetere una stessa operazione non aggiunge effetti rispetto alla prima esecuzione: deve essere supportata dal servizio. Scrivere «evita i duplicati» nelle istruzioni dell’AI non la implementa. [4]

Nel caso delle consegne, prima di inviare nuovamente una conferma dovremmo cercare una prova dell’esito precedente. Il controllo dei duplicati può prevenire una seconda comunicazione indesiderata; non cancella la prima, se era sbagliata.

Il piano di recupero si prepara prima dell’esecuzione

Per un agente che può agire sui sistemi, proporrei di associare alle operazioni rilevanti alcune informazioni verificabili:

• Perimetro: quali file, servizi, destinatari e attività possono essere coinvolti.
• Confine del ripristino: che cosa si può annullare con la procedura tecnica e che cosa resta fuori.
• Prove dell’esito: versioni, registrazioni e identificativi necessari a distinguere un’azione proposta da una completata.
• Gestione dell’incertezza: quando fermarsi per controllare anziché ripetere un’operazione.
• Responsabile del recupero: chi valuta e autorizza rettifiche o altre azioni verso persone e sistemi esterni.

Metterei inoltre una verifica esplicita prima dell’azione che porta le informazioni fuori dall’ambiente di preparazione. Nel nostro scenario, aggiornare il prospetto e inviare le conferme sono due momenti distinti. La conferma dovrebbe riguardare il contenuto effettivo, i destinatari e le condizioni della consegna.

Questa separazione non richiede di approvare ogni gesto dell’assistente. Serve a collocare il controllo dove un errore può cominciare a coinvolgere altri soggetti.

Dove mettere il piano e le regole per non aggravare l’errore

Il piano deve essere disponibile prima dell’esecuzione, nel progetto e negli strumenti che svolgono il lavoro. Lasciarlo soltanto nella chat rende difficile ritrovarlo, applicarlo e verificarlo. Per un ambiente che utilizza AGENTS.md, proporrei questa distribuzione:

Dove	Che cosa inserire	Esempio per le consegne
AGENTS.md globale Regole comuni ai progetti	Fermarsi davanti a un esito incerto; conservare le prove; distinguere ripristino tecnico ed effetti esterni; rispettare le autorizzazioni.	«Non ripetere un invio dall’esito incerto prima di averne verificato lo stato.»
AGENTS.md locale Vincoli del singolo progetto	Indicare file e servizi interessati, azioni consentite, controlli obbligatori e percorso del playbook da consultare.	«Le disponibilità provvisorie non autorizzano conferme. Prima degli invii leggere il playbook di recupero consegne.»
Playbook di recupero del progetto Procedura operativa versionata	Descrivere come accertare gli esiti, ripristinare senza perdere modifiche legittime, valutare le compensazioni e coinvolgere il responsabile.	Identificare messaggio e destinatari; controllare l’esito; preparare la rettifica; ottenere l’autorizzazione prevista; verificarne il risultato.
Codice, servizi e workflow Controlli effettivi dell’esecuzione	Implementare permessi, blocchi prima degli invii, identificativi delle operazioni, gestione dei duplicati e dei ritentativi, registrazione degli esiti.	Se l’invio ha esito sconosciuto, bloccare il nuovo tentativo e richiedere una verifica o l’intervento dell’operatore.

Questa distribuzione è una proposta organizzativa dell’autore su Codex. 

AGENTS.md e playbook guidano il comportamento dell’assistente; non sostituiscono i controlli del software. 

Anche Oracle distingue le istruzioni al modello dai controlli di esecuzione che governano accessi, approvazioni e attività tracciate. [4]

Il playbook dovrebbe essere conservato nella documentazione versionata del progetto e richiamato esplicitamente dalle istruzioni locali. Per essere utilizzabile deve indicare prerequisiti, passi, verifiche, responsabile ed escalation: deve poterlo seguire anche un operatore senza ricostruire la conversazione con l’AI.

Esempio pratico: 

l’invio al fornitore va in timeout. 

La regola dice di non riprovare alla cieca. Il workflow conserva l’identificativo dell’operazione e sospende il nuovo invio; il playbook indica dove cercare la prova dell’esito. Se il messaggio risulta partito con una data errata, il responsabile valuta la rettifica prevista. Se l’esito resta sconosciuto, si segnala l’incertezza e si richiede una verifica manuale. Non si dichiara «non inviato» solo perché manca una risposta.

Anche le azioni di recupero possono modificare dati o coinvolgere altre persone: vanno eseguite soltanto entro le autorizzazioni previste. Nel nostro esempio la rettifica viene prima preparata, poi inviata dopo l’approvazione richiesta; il ripristino del foglio non autorizza da solo una nuova comunicazione.

Un resoconto di recupero deve lasciare visibile ciò che manca

Dopo un errore, chiederei all’AI un resoconto breve e concreto: quali contenuti sono stati ripristinati, quali effetti esterni risultano prodotti, quali correzioni sono state eseguite e quali restano proposte. Le verifiche non effettuate devono rimanere riconoscibili.

Conserverei anche la traccia dell’operazione originaria e della correzione. Sostituire il file sbagliato senza poter ricostruire dove sia stato utilizzato rende più difficile capire chi debba essere avvisato.

Il ripristino del sistema non certifica il recupero del processo. Per chi lavora con un agente AI, la domanda operativa diventa allora concreta: 

• quali effetti dell’errore abbiamo verificato e quali richiedono ancora un intervento?

Fonti consultate

Fonti verificate il 5 novembre 2026. I collegamenti sostengono i concetti tecnici indicati; lo scenario delle consegne e le proposte di controllo sono elaborazioni editoriali dell’autore.

1. Oracle, Oracle AI Database 26 SQL Language Reference — ROLLBACK. Ambito del rollback della transazione corrente.
2. Oracle, Developing Applications with Sagas. Compensazioni automatiche e finalizzazione specifica dell’applicazione.
3. Microsoft Support, Can I undo / recall a sent email?. Richiamo soggetto a condizioni, con un esito da verificare.
4. Pruthvithej Ramesh Kumar, Oracle Database Insider, When AI Agents Meet Enterprise Reality: Workflows, Transactions, and Runtime Controls, 23 giugno 2026. Effetti esterni, esiti incerti, compensazione e controlli dell’esecuzione.