Introduzione
Il rischio più sottovalutato degli agenti AI non è l’errore singolo. È l’errore operativo ripetuto, eseguito rapidamente, su strumenti reali.
Un chatbot che risponde male crea un problema di comunicazione. Un agente AI con accesso a CRM, email, file, ecommerce o gestionale può creare un problema aziendale: inviare messaggi sbagliati, modificare dati, generare preventivi non coerenti, aprire ticket inutili, sovrascrivere informazioni o attivare workflow non desiderati.
Per questo ogni progetto agentico dovrebbe avere un recovery plan prima del go-live. Non dopo il primo incidente.
Il problema: dare controllo completo troppo presto
Molti progetti AI partono con una buona intenzione: ridurre lavoro manuale. Il problema nasce quando, per accelerare, si concede all’agente accesso diretto a strumenti operativi senza passaggi intermedi.
Esempi:
- l’agente può inviare email senza approvazione;
- può modificare record del CRM;
- può aggiornare prodotti ecommerce;
- può creare o chiudere ticket;
- può generare offerte commerciali e salvarle come definitive;
- può chiamare API che producono effetti reali;
- può leggere più dati di quelli necessari.
Questo non significa che gli agenti AI non debbano mai agire. Significa che l’autonomia va concessa per livelli.
Che cos’è un recovery plan per agenti AI
Un recovery plan è una procedura operativa che definisce cosa fare quando un agente AI:
- produce output errati;
- usa uno strumento in modo non previsto;
- supera il perimetro autorizzato;
- genera costi anomali;
- modifica dati sbagliati;
- invia comunicazioni non approvate;
- entra in loop;
- non rispetta policy aziendali.
Il recovery plan deve rispondere a sei domande:
- Come fermiamo l’agente?
- Come isoliamo il danno?
- Come capiamo cosa è successo?
- Come ripristiniamo dati o comunicazioni?
- Come impediamo che accada di nuovo?
- Chi decide quando riattivare il sistema?
Fase 1: stop immediato
Il primo requisito è un kill switch. Deve essere semplice, documentato e accessibile alle persone autorizzate.
Può essere:
- una variabile di ambiente;
- un flag nel database;
- un’impostazione nel pannello admin;
- la disattivazione di una coda;
- il blocco di una chiave API;
- la sospensione di un job schedulato.
Lo stop deve poter bloccare almeno tre livelli:
- esecuzione dell’agente;
- chiamate agli strumenti;
- azioni con effetto esterno, come email, modifiche CRM o invii via API.
Se non puoi fermare rapidamente l’agente, non dovresti dargli controllo operativo.
Fase 2: isolamento del perimetro
Dopo lo stop, devi capire dove l’agente ha agito.
Le domande sono pratiche:
- quali record ha letto?
- quali record ha modificato?
- quali messaggi ha inviato?
- quali file ha creato?
- quali API ha chiamato?
- quali utenti o clienti sono stati coinvolti?
- quali costi ha generato?
Qui il tracing diventa essenziale. La documentazione dell’OpenAI Agents SDK evidenzia che le trace possono raccogliere generazioni, tool call, handoff e guardrail. In un contesto aziendale questo tipo di tracciamento non è un dettaglio tecnico: è ciò che permette di ricostruire l’incidente.
Fase 3: audit delle azioni
L’audit deve distinguere tra:
- output generati ma non usati;
- azioni proposte ma non approvate;
- azioni eseguite su sistemi interni;
- azioni comunicate all’esterno.
Questa distinzione serve a definire la gravità.
Un suggerimento sbagliato in bozza è un problema minore. Una modifica massiva al CRM è un problema più serio. Una comunicazione errata inviata a clienti o fornitori richiede anche gestione reputazionale.
Fase 4: rollback e correzione
Il rollback dipende dal tipo di azione.
Per dati interni:
- ripristino da backup;
- confronto con storico modifiche;
- ripristino selettivo dei record;
- correzione manuale assistita.
Per comunicazioni esterne:
- invio di rettifica;
- blocco delle campagne successive;
- revisione delle liste coinvolte;
- comunicazione interna al team commerciale o assistenza.
Per automazioni tecniche:
- sospensione job;
- svuotamento code;
- disattivazione webhook;
- rotazione chiavi API;
- ripristino versioni precedenti del workflow.
Fase 5: riduzione dei permessi
Dopo l’incidente, non basta correggere il prompt. Spesso il problema è nei permessi.
La regola è semplice: un agente deve avere il minimo accesso necessario.
Esempi di riduzione:
- da scrittura a sola lettura;
- da invio automatico a bozza da approvare;
- da modifica diretta a proposta di modifica;
- da accesso globale a accesso per singolo reparto;
- da esecuzione immediata a coda con revisione;
- da autonomia completa a human-in-the-loop.
Il prompt non è un sistema di sicurezza. Le istruzioni aiutano, ma il controllo reale deve stare anche nell’architettura.
Fase 6: nuovi guardrail
I guardrail devono essere posizionati dove serve, non solo all’inizio o alla fine.
Secondo la documentazione OpenAI, i guardrail possono controllare input, output e strumenti. Nei workflow con più agenti, i tool guardrail sono particolarmente importanti perché possono validare ogni chiamata a strumenti personalizzati.
In pratica, puoi introdurre controlli come:
- blocco se mancano dati obbligatori;
- limite massimo di record modificabili;
- blocco su parole o condizioni sensibili;
- controllo del margine minimo in un preventivo;
- approvazione umana sopra una certa soglia economica;
- validazione schema prima di chiamare API;
- controllo destinatari prima dell’invio email.
Fase 7: riattivazione graduale
Il sistema non dovrebbe tornare subito alla piena autonomia.
Una riattivazione prudente può seguire quattro livelli:
- solo lettura;
- generazione bozze;
- azioni interne reversibili;
- azioni esterne o non reversibili con soglie e approvazioni.
Ogni livello deve avere metriche:
- tasso di errore;
- casi bloccati dai guardrail;
- interventi umani richiesti;
- costi API;
- tempi di completamento;
- incidenti o quasi incidenti.
Checklist recovery plan
Prima di lasciare controllo operativo a un agente AI, verifica di avere:
- kill switch;
- log e trace consultabili;
- storico delle modifiche;
- backup o versioning;
- permessi granulari;
- guardrail sugli strumenti;
- soglie economiche;
- human-in-the-loop per azioni sensibili;
- procedura di rollback;
- responsabile della riattivazione.
Conclusione
Un agente AI può essere utile solo se l’azienda sa controllarlo, fermarlo e correggerlo.
Il recovery plan non è un segnale di sfiducia nella tecnologia. È una condizione di maturità operativa. Più autonomia concedi agli agenti AI, più devi investire in controllo, tracciabilità, limiti e procedure di recupero.
La domanda da farsi prima del go-live è semplice: se l’agente sbaglia alle 3 di notte, sappiamo fermarlo e ripristinare la situazione?
Se la risposta è no, il sistema non è ancora pronto per avere pieno controllo.
Link interni consigliati:
– Monitoraggio integrazioni: log, alert e controlli per sapere quando qualcosa si rompe
– Agenti AI in azienda: cosa automatizzare davvero e cosa lasciare umano
– Metriche di processo: come misurare automazioni e software custom dopo il rilascio
Fonti tecniche:
– OpenAI Agents SDK – Guardrails
– OpenAI Agents SDK – Tracing
– OpenAI Agents SDK – Agent Orchestration