Sono le 3 di notte e l’agente AI che gestisce i solleciti ha inviato lo stesso messaggio a tutta l’anagrafica clienti, compresi quelli che hanno già pagato. Oppure l’agente collegato al gestionale ha aggiornato i listini con un valore sbagliato. Domanda: chi se ne accorge, chi lo ferma, e come si rimette tutto a posto? La gestione incidenti agenti AI è esattamente questo: un piano scritto, prima che serva, che risponde a tre domande. Come fermo l’agente in pochi minuti. Come annullo quello che ha fatto. Chi decide e chi avvisa chi.
Il tema non è teorico. Secondo un’indagine IBM ripresa da Bizzit, in Italia il 43% degli intervistati usa già AI agentica in produzione e l’82% si aspetta che entro il 2027 gli agenti abbiano un certo grado di autonomia decisionale, ma solo il 30% delle aziende italiane risulta pronto ad affrontarli. Più autonomia significa più azioni eseguite senza che un umano le guardi una per una. Quindi più bisogno di un piano per quando qualcosa va storto.
Cosa conta come incidente quando c’è un agente AI
Un agente non è un chatbot che risponde e basta: chiama strumenti, scrive su database, invia email, apre ticket. Per questo gli incidenti tipici sono diversi da quelli di un software tradizionale. Nella mia esperienza conviene classificarli così:
- Azione errata su un sistema: record modificati o cancellati nel CRM o nell’ERP, ordini duplicati, prezzi sbagliati.
- Comunicazione errata verso l’esterno: email o messaggi inviati alle persone sbagliate, con contenuti inesatti o in volume anomalo.
- Esposizione di dati: l’agente riporta in una risposta informazioni di un altro cliente o dati interni.
- Manipolazione: un documento o un’email in ingresso contiene istruzioni che dirottano l’agente (prompt injection).
- Loop e costi: l’agente ripete la stessa chiamata all’infinito, consumando token API e quota dei servizi collegati.
Per ogni categoria va definito un livello di gravità. Un esempio semplice a tre livelli: basso (errore interno, nessun impatto su clienti), medio (impatto su clienti ma reversibile), alto (dati personali coinvolti, danno economico o azione irreversibile). Il livello decide chi viene chiamato e in quanto tempo.
Il kill switch: fermare l’agente in un minuto
Il primo errore che vedo è pensare che “basta spegnere il server”. In pratica l’agente spesso gira dentro un workflow su n8n o Make, usa chiavi API di più servizi e può avere job già in coda. Lo stop d’emergenza va progettato su più livelli:
- Flag di disattivazione: una variabile (in un database o in un file di configurazione) che l’agente controlla prima di ogni azione. Se è su “off”, l’agente non esegue nulla e risponde con un messaggio di cortesia o passa la richiesta a una persona.
- Modalità sola lettura: un livello intermedio in cui l’agente può ancora consultare dati e rispondere, ma tutti gli strumenti che scrivono sono bloccati. Utile quando il problema riguarda solo le azioni.
- Svuotamento delle code: i messaggi o le azioni già in coda vanno messi in pausa, non solo quelli futuri. Altrimenti l’agente “spento” continua a inviare email per altri dieci minuti.
- Revoca delle credenziali: l’ultima linea. Si ruotano o disattivano i token che l’agente usa verso CRM, email, gestionale. Funziona solo se l’agente ha credenziali dedicate, non quelle dell’amministratore.
Il flag deve poter essere attivato da una persona non tecnica: un pulsante in una dashboard interna, un comando su un canale di chat aziendale. Se per fermare l’agente serve un accesso SSH, alle 3 di notte non lo fermerà nessuno.
Rollback: rendere le azioni reversibili prima che servano
Annullare un’azione è facile solo se il sistema è stato costruito per permetterlo. Le scelte che faccio in fase di progettazione:
- Registro delle azioni: ogni chiamata a uno strumento viene salvata con input, output, valore precedente e valore nuovo. Senza questo non sai cosa ripristinare. È la base di cui parlo nell’articolo sull’osservabilità degli agenti AI in produzione.
- Cancellazioni logiche: l’agente non elimina record, li marca come archiviati. Il ripristino diventa un aggiornamento, non un recupero da backup.
- Bozze invece di invii dove l’impatto è alto: preventivi, comunicazioni a molti destinatari, modifiche ai listini. L’agente prepara, una persona conferma. Ne ho scritto parlando di human-in-the-loop e supervisione umana.
- Limiti di raggio d’azione: un tetto al numero di email inviate per ora, ai record modificabili in un’esecuzione, all’importo massimo di uno sconto. Se l’agente supera il limite si blocca da solo e notifica.
- Versioni di prompt e modello: prompt di sistema, elenco degli strumenti e versione del modello vanno versionati come il codice. Se un incidente nasce dopo una modifica, si torna alla versione precedente in pochi minuti.
Va detto chiaramente: alcune azioni non sono reversibili. Un’email inviata resta inviata. Per queste il rollback è una procedura di comunicazione (messaggio di rettifica, contatto diretto ai clienti coinvolti), che conviene avere già scritta.
Chi fa cosa: ruoli e runbook
In una PMI non esiste un team di sicurezza dedicato, ed è normale. Servono però nomi precisi, non “l’IT”. Il minimo che consiglio:
- Responsabile del processo: la persona che conosce il processo automatizzato (amministrazione, customer care, commerciale). Decide se un comportamento è un errore e valuta l’impatto sul business.
- Responsabile tecnico: interno o esterno, attiva lo stop, analizza i log, esegue il rollback.
- Referente privacy: DPO se nominato, altrimenti chi segue il GDPR in azienda. Va coinvolto appena ci sono dati personali di mezzo.
- Chi comunica: verso clienti, fornitori, eventualmente autorità.
Tutto questo finisce in un runbook di una o due pagine: come si riconosce l’incidente, chi si chiama e con quale numero, come si attiva lo stop, dove sono i log, come si fa il rollback per ciascuno strumento. Se l’agente è gestito da un fornitore esterno, il contratto deve indicare tempi di intervento e reperibilità. Una risposta “entro il giorno lavorativo successivo” non basta per un agente che opera di notte.
Gli obblighi esterni da tenere presenti
Un incidente con un agente AI può far scattare obblighi che esistono indipendentemente dall’AI:
- GDPR, art. 33: se c’è una violazione di dati personali che presenta un rischio per gli interessati, la notifica al Garante va fatta entro 72 ore da quando se ne è venuti a conoscenza. Anche quando non si notifica, la violazione va documentata internamente.
- NIS2: se l’azienda rientra tra i soggetti del D.Lgs. 138/2024, gli incidenti significativi seguono le tempistiche di segnalazione verso CSIRT Italia. Ne ho parlato nell’articolo su NIS2 per le PMI.
- AI Act: per i sistemi classificati ad alto rischio il regolamento prevede la segnalazione degli incidenti gravi. La maggior parte degli agenti di back office di una PMI non rientra in quella categoria, ma la classificazione va verificata caso per caso con chi segue la compliance, anche perché le date di applicazione di alcuni obblighi sono oggetto di revisione a livello europeo.
- Contratti: alcuni clienti, specie grandi committenti, chiedono nei contratti di essere informati di incidenti che li riguardano entro tempi definiti.
Il runbook dovrebbe contenere una checklist che porta a chiedersi, per ogni incidente, se uno di questi obblighi è scattato.
Provare il piano prima di averne bisogno
Un piano mai testato è un’ipotesi. Due esercizi semplici, da fare almeno una volta prima del rilascio e poi periodicamente:
- Simulazione a tavolino: si prende uno scenario concreto (“l’agente ha inviato 300 solleciti sbagliati”) e si percorre il runbook con le persone coinvolte. Emergono subito i buchi: il numero di telefono che nessuno ha, il log che non registra il destinatario.
- Test reale dello stop: in un ambiente di prova, o in produzione in un momento tranquillo, si attiva il flag e si misura quanto tempo passa prima che l’agente smetta davvero di agire.
Dopo ogni incidente, anche minore, si scrive una breve analisi: cosa è successo, perché, cosa cambia. Spesso la correzione è un nuovo limite, un test aggiuntivo o un passaggio di conferma umana. È un lavoro che si integra con il testing degli agenti AI prima del lancio: ogni incidente diventa un nuovo caso di test.
Domande frequenti
Un piano incidenti serve anche per un solo agente semplice?
Sì, in versione ridotta. Anche per un agente che fa una sola cosa servono uno stop attivabile da una persona non tecnica, un registro delle azioni e un nome di riferimento. Bastano poche ore di lavoro se si fa in fase di progetto.
Il kill switch rallenta l’agente?
In modo trascurabile. Controllare un flag prima di ogni azione è una lettura veloce. Il costo vero è progettuale: decidere quali azioni bloccare e cosa deve succedere alle richieste in arrivo mentre l’agente è fermo.
Se uso n8n o Make, posso gestire tutto lì dentro?
In buona parte sì: workflow disattivabili, nodi di controllo che leggono un flag, limiti di esecuzione e log delle esecuzioni. Le credenziali dedicate e la reversibilità delle azioni vanno però gestite anche sui sistemi collegati, come CRM e gestionale.
Chi è responsabile se l’agente sbaglia?
L’azienda che lo usa resta responsabile verso clienti e autorità. Con il fornitore la ripartizione dipende dal contratto. Per questo conviene definire per iscritto ruoli, tempi di intervento e accesso ai log prima di mettere l’agente in produzione.
Prima di dare autonomia, prepara il freno
Gli agenti AI portano risultati concreti quando possono agire sui sistemi aziendali. Proprio per questo devono avere un freno, una retromarcia e persone che sanno usarli. Se stai per mettere in produzione un agente, o ne hai già uno e non sapresti come fermarlo stanotte, posso aiutarti a progettare stop d’emergenza, registro delle azioni e runbook insieme all’automazione stessa. Contattami per valutare il tuo progetto.
