Alle 10:17 un’agenzia immobiliare scopre che il nuovo agente ha confermato visite con l’orario sbagliato. Sei messaggi sono già arrivati ai clienti. Altri venti lavori aspettano nella queue. La reazione istintiva è: “Spegniamo tutto”.
Ma cosa significa “tutto”? Il modello? Il workflow? Le email? Le scritture nel CRM? Il form che raccoglie le richieste? E soprattutto: come si gestiscono le sei conferme già viste dai clienti?
Un kill switch utile ferma rapidamente l’effetto pericoloso senza spegnere inutilmente il resto dell’attività. Il rollback è un problema diverso: alcuni stati possono essere ripristinati, mentre gli effetti esterni richiedono una correzione o un contatto umano.
Le linee guida NIST sull’incident response trattano risposta e recovery come capacità preparate in anticipo. È una buona regola anche per gli agenti: il modo di fermarli va progettato prima del primo incidente.
Il kill switch non è un solo pulsante rosso
In una demo basta disattivare lo scenario. In produzione un’automazione attraversa input, modello, queue, CRM, strumenti di invio, calendario, webhook e retry.
Se il problema è il contenuto delle risposte, si può bloccare l’invio esterno e continuare a raccogliere richieste. Se il sospetto riguarda le credenziali, bisogna revocare l’identità tecnica. Se la logica crea doppie prenotazioni, si bloccano le scritture ma si possono mantenere letture e monitoraggio.
Conviene quindi pensare a quattro livelli: intake, decisione, write/esecuzione e credenziali. Più è precisa l’isolazione, meno lavoro sano viene perso.
i modelli consolidati di incident response separano contenimento, ripristino e ritorno controllato al servizio.
Raccomandazione: per agenti importanti costruite interruttori mirati, non soltanto un unico off generale.
Stop e rollback sono promesse differenti
Un campo CRM può spesso tornare alla versione precedente. Una mail inviata non può essere ritirata da ogni casella. Un appuntamento si può cancellare, ma il cliente potrebbe aver già organizzato la giornata. Un ordine può aver attivato altri processi.
Per questo, nelle automazioni reali il rollback spesso significa compensazione.
Una bozza, un tag interno o un valore con storico affidabile sono relativamente semplici da ripristinare. Per effetti esterni servono invece azioni: inviare una correzione, richiamare il cliente, verificare una nota di credito, annullare un processo downstream.
I cloud design pattern descrivono le compensating transactions proprio per workflow distribuiti in cui non tutto può essere annullato atomicamente. La stessa logica vale in piccolo.
Un runbook sensato non scrive “rollback email”. Scrive: pausa outbound, trova destinatari coinvolti, prepara correzione, richiedi approvazione umana, registra la comunicazione.
I primi quindici minuti devono essere semplici
Durante un incidente nessuno vuole leggere un manuale di quaranta pagine. Il flusso deve essere pratico.
- Contenete l’esecuzione. Fermate write e invii rischiosi; mantenete l’intake se è sicuro.
- Congelate la queue. Non eliminate i job pendenti e impedite il replay automatico.
- Limitate l’accesso. Revocate identità o token se il problema può riguardare le credenziali.
- Salvate le prove. Run ID, contesto, tool call, record coinvolti, timestamp e versione.
- Classificate gli effetti. Reversibili, compensabili o irreversibili, con owner e piano di correzione.
- Riavviate gradualmente. Un caso noto, poi un piccolo lotto monitorato; niente apertura totale immediata.
La queue è uno dei punti più pericolosi. Durante lo stop il personale sistema manualmente i casi; dopo il riavvio i vecchi job possono ripartire e duplicare tutto. Il bug originale è risolto, ma il recovery crea il secondo problema.
Chi ha il diritto di riaccendere?
Il tecnico può sapere che la patch funziona, ma non sapere quali clienti abbiano già telefonato. Il responsabile business conosce i casi, ma non può sempre valutare lo stato delle credenziali.
In una PMI basta una regola a due verifiche: il technical owner conferma causa e contenimento; il business owner conferma clienti, queue e correzioni. Nelle microimprese la stessa persona può coprire entrambi, purché controlli entrambi gli aspetti.
Il passaggio umano è particolarmente importante per gli effetti irreversibili. Una promessa di prezzo sbagliata o un cliente arrabbiato non dovrebbe essere gestito automaticamente con una nuova risposta generata.
Per modifiche interne e totalmente reversibili può invece avere senso un rollback automatico. Ma deve essere deterministico e testato, non una presunzione generale.
Un pilota minimo deve includere il test del guasto
Prima di permettere azioni autonome sui clienti, create un errore controllato. Fate scrivere all’agente uno stato invalido in test o inviare una mail solo a un destinatario sandbox. Poi usate il vero kill switch.
Verificate cosa si è fermato, se le richieste nuove sono state conservate, se la queue è leggibile, se gli effetti esterni sono distinguibili e chi può autorizzare il restart.
Le metriche utili sono tempo dall’allarme al contenimento, azioni avvenute dopo il segnale di stop, casi con audit completo, tempo per la correzione business, riavvii controllati riusciti e azioni duplicate durante il recovery.
L’obiettivo di zero duplicati è una misura operativa, non la promessa che un incidente sia impossibile.
La conclusione è semplice: un’automazione è pronta per la produzione quando l’azienda sa sia farla partire sia fermarla. Kill switch, rollback e riconciliazione trasformano un errore potenzialmente caotico in un incidente gestibile.
Prompt, permessi, routing e fonti di conoscenza sono versioni. Il piano di risposta agli incidenti copre la comunicazione; l'inventario degli agenti identifica i sistemi coinvolti.
Fonti
FAQ
Basta disattivare il workflow in Make o Zapier?
Può fermare una parte. Controllate anche job in corso, queue, credenziali e azioni esterne già avviate.
Ogni azione IA è reversibile?
No. Messaggi inviati, prenotazioni confermate e altri effetti esterni possono richiedere compensazioni umane.
Il kill switch deve attivarsi da solo?
Può essere automatico su limiti tecnici chiari. Gli stop con conseguenze business devono essere visibili a un owner.
Durante l’incidente dobbiamo fermare anche l’intake?
Non sempre. Un degraded mode può continuare a raccogliere richieste mentre le azioni rischiose restano bloccate.
Chi autorizza il riavvio?
Una persona o coppia di ruoli predefinita, dopo verifica sia tecnica sia operativa.