L’automazione AI ha bisogno di classi di errore

L’automazione AI ha bisogno di classi di errore, non solo di retry. Questa è la tesi, ed è importante perché molti team scoprono la fragilità dei workflow solo quando il workflow è già entrato nel lavoro ricorrente dell’azienda.

All’inizio un’automazione AI è spesso controllata a vista. Il founder la lancia a mano. Il product lead legge l’output prima di inviarlo. L’ops lead guarda le prime esecuzioni perché il sistema è ancora un esperimento. Poi il workflow diventa normale amministrazione. Classifica lead, riassume ticket, arricchisce record nel CRM, prepara email, aggiorna fogli, instrada eccezioni.

A quel punto un errore non è più un fastidio tecnico. È un evento operativo. Può creare duplicati, mandare informazioni sbagliate a un cliente, nascondere un problema nei dati, consumare tempo del team o far passare un’azione che avrebbe dovuto essere approvata.

La reazione più comune è aggiungere retry. Se l’API non risponde, riprova. Se il modello restituisce JSON non valido, riprova. Se il CRM rifiuta la richiesta, riprova. I retry sono utili, ma non sono un modello di affidabilità. Sono una risposta possibile a una classe specifica di errore.

I retry non bastano

Un retry funziona bene quando il problema è transitorio. Un provider restituisce 502. Una chiamata di rete cade. Un rate limit si libera dopo pochi secondi. In questi casi ha senso riprovare con un limite, un intervallo crescente e un log leggibile.

Ma i workflow AI non falliscono solo così. La fonte può essere vecchia. Un webhook può partire due volte. Lo schema di un record può cambiare dopo una modifica nel CRM. Un documento recuperato dalla retrieval può non essere abbastanza recente. Il modello può produrre una classificazione incerta. Il workflow può tentare un’azione fuori dal perimetro dei permessi. Un messaggio al cliente può essere valido nella forma, ma non sicuro da inviare.

Riprovare in questi casi può peggiorare la situazione. Un trigger duplicato riprovato tre volte produce tre azioni duplicate. Una fonte vecchia rimane vecchia anche dopo dieci minuti. Un errore di permessi non va negoziato dal workflow in autonomia. Un output AI a bassa confidenza non diventa automaticamente affidabile solo perché viene generato una seconda volta.

Le meccaniche di scalabilità servono, ma non risolvono questa ambiguità. La documentazione n8n descrive la queue mode come un’architettura in cui un’istanza principale, Redis, worker e database separano ricezione ed esecuzione dei workflow (documentazione n8n sulla queue mode). È utile quando il carico cresce. Però non dice al business che cosa fare quando un’esecuzione è ambigua.

In Agenti AI: servono code operative, non solo prompt il punto era simile: una coda dà al lavoro AI un posto dove aspettare, essere preso in carico e venire revisionato. Le classi di errore portano lo stesso principio dentro il workflow.

Che cosa deve succedere dopo questo errore?

La domanda utile non è: possiamo recuperare automaticamente? La domanda migliore è: che tipo di errore è?

Per iniziare basta una tabella piccola. Non serve creare un sistema enorme. Scegli un workflow critico e nomina le classi di errore che contano.

Errore API transitorio: retry con numero massimo di tentativi, backoff e log.

Schema drift: stop del workflow, alert all’owner e payload che mostra quale campo non rispetta più il contratto.

Trigger duplicato: deduplica prima dell’azione, usando una chiave come event ID, customer ID più timestamp, o versione del record sorgente.

Fonte stale: refresh della fonte, nuova lettura dal sistema di riferimento, oppure stop se la freschezza non è dimostrabile.

Risposta a bassa confidenza: revisione umana, soprattutto se l’output tocca clienti, decisioni economiche, claim legali o impegni operativi.

Confine di permesso: stop ed escalation. Il workflow non deve decidere da solo di avere più autorità.

Azione unsafe: approvazione umana o blocco totale, in base al rischio.

Questa tabella non è burocrazia. È il manuale operativo dell’automazione. Dice a chi costruisce dove mettere IF, Switch, validazioni, deduplica, stop e review. Dice a chi opera quali alert meritano attenzione. Dice al management se l’incidente è un problema tecnico, di qualità dati, di processo o di policy.

La documentazione n8n sugli error workflow spiega che un workflow di errore può partire quando un’esecuzione fallisce, usando un Error Trigger e dati come execution ID, messaggio di errore, ultimo nodo eseguito e nome del workflow (documentazione n8n sull’error handling). Quel payload è prezioso, ma l’organizzazione deve comunque interpretarlo. L’error workflow non dovrebbe dire soltanto che qualcosa è fallito. Dovrebbe etichettare la classe di errore e instradarla.

La tabella delle classi di errore

Una tabella pratica può avere sei colonne: classe di errore, segnale di rilevazione, risposta automatica, condizione di stop, owner, evidenza per la review.

Prendiamo un workflow che classifica ticket di supporto in billing, tecnico, sales o reclamo. Un timeout API può essere riprovato due volte. Una risposta del modello con formato sbagliato può passare da un tentativo di repair, chiedendo lo stesso output nello schema richiesto, e poi fermarsi. Un ticket senza customer ID non dovrebbe essere classificato a intuito. Deve aggiornare la fonte o finire in una coda operativa. Un reclamo con linguaggio legale deve andare in review umana. Un webhook duplicato deve essere deduplicato prima di creare un secondo ticket.

Qui entra anche il tema della retrieval. In La retrieval ha bisogno di un contratto l’idea centrale è che fonte, freschezza e regole di valutazione devono essere esplicite prima che la retrieval diventi affidabile. Lo stesso vale per l’automazione. Se il workflow non può provare che il contesto è abbastanza fresco, l’errore non è del modello. È una fonte stale. La risposta non è retry. È refresh o stop.

La tabella evita anche un’abitudine pericolosa: nascondere la proprietà del problema dietro l’automazione. Se il workflow fallisce perché il record cliente è incompleto, chi lo corregge? Sales ops? Data engineering? Customer success? Se la risposta è nessuno, il retry diventa un modo elegante per rinviare la responsabilità.

Dove mettere stop ed escalation

Le condizioni di stop vanno messe prima delle azioni irreversibili. Scrivere una bozza è meno rischioso che inviarla. Classificare è meno rischioso che cancellare. Riassumere è meno rischioso che aggiornare un sistema di record. Più il workflow si avvicina a un’azione che cambia stato, più la classe di errore deve essere esplicita.

n8n documenta anche il nodo Stop And Error, che può forzare il fallimento di un’esecuzione in circostanze scelte e attivare un error workflow (documentazione n8n su Stop And Error). Questo pattern è importante: a volte il comportamento affidabile non è recuperare. È fermarsi in modo chiaro.

Anche la concorrenza conta. La documentazione n8n per self-hosted concurrency spiega che le esecuzioni di produzione possono essere limitate e messe in coda quando superano la capacità, con elaborazione FIFO quando la capacità torna disponibile (documentazione n8n sulla concurrency). Questo protegge le risorse di esecuzione, ma non classifica il rischio di business. Un’azione unsafe in coda resta unsafe anche quando arriva il suo turno.

Uno studio arXiv del 2026 su oltre 6.000 workflow n8n pubblici ha rilevato che meccanismi espliciti di affidabilità come fallback strutturati, repair loop, alert specifici per tipo di errore e gate di approvazione umana sono ancora relativamente poco comuni nei workflow agentici pubblici (Characterizing Large Language Model Agentic Workflows). È un segnale da prendere sul serio. Molti workflow girano, ma girare non significa essere governati.

Auditare un workflow questa settimana

Scegli un workflow che tocca già lavoro ricorrente. Non partire dall’architettura completa. Parti da un percorso: trigger, decisione, azione.

Per ogni errore significativo chiediti: è transitorio, duplicato, stale, ambiguo, non autorizzato, unsafe o strutturalmente rotto? Poi decidi la risposta: retry, stop, deduplica, refresh, escalation o review umana. Aggiungi l’owner. Aggiungi l’evidenza che deve comparire nell’alert o nella coda di revisione.

Il risultato può essere una semplice tabella accanto al canvas del workflow. È già abbastanza per cambiare la conversazione. Il team smette di chiedere se l’automazione è affidabile in astratto e inizia a chiedere se ogni classe di errore ha la risposta giusta.

L’automazione AI ha bisogno di classi di errore, non solo di retry. Il retry ha senso solo dopo che il team sa che cosa è fallito, perché è fallito, chi lo possiede e quando l’azione più sicura è fermarsi.