Automazioni AI che si rompono: come capire perché e sistemarle

Chiamo il pattern per nome: la maggior parte delle automazioni AI che vediamo arrivare da un altro fornitore sono state collaudate una volta, sul caso perfetto, e mai più toccate. Nessuna gestione degli errori, nessun retry, nessun log leggibile. Il primo imprevisto le ferma, e siccome non avvisano nessuno, restano ferme finché un cliente non si lamenta. Non è colpa dell'AI: è una scelta di progettazione, fatta o non fatta, che decide se il sistema regge o crolla al primo urto.

Cos'è un'automazione AI che si può davvero chiamare "affidabile"?

Un'automazione affidabile non è quella che non si rompe mai: quel sistema non esiste, perché dipende da servizi esterni fuori dal tuo controllo (API di terzi, connessioni di rete, provider AI). È quella che, quando qualcosa va storto, non perde dati, riprova in modo sicuro, e avvisa una persona invece di fallire in silenzio. La differenza tra un prototipo e un sistema di produzione non si vede il giorno della demo: si vede alle tre di notte, quando un token scade o un servizio esterno risponde con un errore. Il prototipo si ferma e basta. Il sistema serio riprova, non duplica nulla, e lascia una traccia leggibile di cosa è successo.

Perché un'automazione che funzionava ieri si ferma oggi?

Perché nulla, in un sistema collegato a servizi esterni, resta fermo nel tempo. Le cause concrete che troviamo più spesso, in ordine di frequenza:

1. Credenziali o token scaduti. Le chiavi API e i token OAuth hanno una scadenza per definizione: è una misura di sicurezza, non un bug. Quando scade, il flusso si interrompe senza preavviso se nessuno monitora la data.
2. Un'API esterna è cambiata. Un fornitore aggiorna un endpoint, rinomina un campo, introduce un nuovo limite di chiamate. Il flusso costruito su quella versione smette di funzionare, senza che tu abbia toccato nulla.
3. Il formato dei dati in ingresso è cambiato. Una colonna rinominata in un foglio, un nuovo campo obbligatorio in un form, una data scritta diversamente: un flusso nato su dati puliti si blocca sui dati reali.
4. Rate limit e timeout non gestiti. Sotto carico, un'API esterna risponde con un limite di frequenza o un ritardo. Senza un retry intelligente, il flusso fallisce e quei dati vengono persi, non solo rallentati.
5. Il prompt dell'AI "deriva" su input reali. Un prompt validato su cinque esempi puliti comincia a dare risposte sbagliate su input reali più vari, più ambigui, più simili a un vero cliente arrabbiato.
6. Dati saltati o duplicati. Senza una chiave univoca per elemento, un retry o un doppio invio dal form crea due lead identici, o ne fa perdere uno.
7. Nessun monitoraggio. Il guasto tecnico non è quasi mai il problema reale: il problema è che il sistema falliva da giorni e nessuno lo sapeva, perché mancava un alert.

Nel lavoro di messa in sicurezza che seguiamo su automazioni esistenti, la causa più difficile da individuare non è mai la più esotica. È la più ignorata: il monitoraggio assente. Un flusso che fallisce in silenzio può restare rotto per settimane prima che qualcuno se ne accorga, e a quel punto il danno non è più solo tecnico.

L'assistente AI risponde male ai clienti: è colpa del modello?

Quasi mai. La documentazione OpenAI sugli output strutturati dichiara che questa funzione "ensures the model will always generate responses that adhere to your supplied JSON Schema": garantisce cioè che la risposta abbia il formato giusto (i campi giusti, i tipi giusti). Non garantisce che i valori dentro quei campi siano corretti: un modello può rispettare perfettamente lo schema e comunque inventare un contenuto sbagliato. Conformità al formato e correttezza del contenuto sono due proprietà diverse, e trattarle come la stessa cosa è l'errore più comune che troviamo in prompt scritti in fretta. La cura, quasi sempre, non è "un modello più potente": è ancorare le risposte a una base di conoscenza verificata e validare il prompt su un campione di richieste reali, non su due esempi puliti scelti a tavolino.

C'è una terza causa, meno frequente ma più insidiosa, quando l'automazione legge contenuti esterni prima di rispondere: email, pagine web, documenti allegati. La OWASP la chiama prompt injection indiretta: si verifica quando "an LLM accepts input from external sources, such as websites or files" e istruzioni nascoste in quel contenuto alterano il comportamento del modello all'insaputa di chi lo usa. Per un'automazione che riassume email o pagine web prima di generare una risposta, questo significa non fidarsi mai ciecamente di un testo ricevuto dall'esterno: un contenuto malevolo può provare a dettare al modello cosa rispondere o quali azioni proporre.

Rendere affidabile un'automazione che si rompe spesso non significa riscrivere tutto da capo. Significa aggiungere, uno per uno, gli strati che un prototipo salta perché non servono per superare la demo.

Validazione degli input e gestione dei casi limite

Prima di elaborare un dato, il sistema verifica che abbia il formato atteso: un campo mancante o malformato viene gestito con una regola esplicita, non lasciato esplodere a metà flusso. È il controllo più semplice da aggiungere e quello che previene la quota più alta di guasti legati a "un'API esterna è cambiata" o a dati sporchi in ingresso. Su piattaforme come Make questo si implementa spesso con un filtro tra due moduli: se i bundle soddisfano le condizioni del filtro passano al modulo successivo, altrimenti la loro elaborazione termina lì, invece di far arrivare un dato incompleto fino al layer AI o alla scrittura finale.

Retry con backoff, non retry alla cieca

Il retry aiuta solo se è progettato per farlo. La guida OpenAI sui rate limit è netta su questo punto: "Exponential backoff means waiting briefly after an unsuccessful request, then increasing the delay after each unsuccessful retry", raccomanda di rispettare l'header `Retry-After` quando presente e avverte che "unsuccessful requests contribute to your per-minute limit, so continuously resending a request won't work". Un retry che riparte ogni secondo peggiora il rate limit, non lo risolve. La stessa logica vive dentro le piattaforme di orchestrazione: Make attiva l'exponential backoff automaticamente sugli errori di tipo `ConnectionError` e `ModuleTimeoutError`, con attese che vanno da 1 minuto al primo tentativo fino a 3 ore dal settimo, se le esecuzioni incomplete sono abilitate. Il punto pratico: il retry deve avere un limite di tentativi e di tempo totale, altrimenti diventa un altro modo di restare bloccati, solo più lentamente.

Cosa fare delle esecuzioni fallite: non lasciarle sparire

Make offre cinque tipi di error handler dichiarati per uno scenario, ognuno con un comportamento diverso: Skip ("disregard errors and allow the scenario to process subsequent bundles"), Retry (memorizza l'esecuzione incompleta e abilita nuovi tentativi automatici o manuali), Resume (sostituisce un valore fallito e continua), Commit (ferma lo scenario ma salva ciò che è già stato elaborato) e Rollback (ferma e annulla). È una scelta esplicita da fare per ogni modulo critico, non un default che funziona da solo. Un dettaglio che sorprende chi arriva da un'altra piattaforma: le esecuzioni incomplete che permettono di riprendere un flusso fallito non sono attive per impostazione predefinita, vanno abilitate a mano nelle impostazioni dello scenario. Un'automazione che sembra avere un "retry automatico" può in realtà non conservare nulla del lavoro fallito, se questa opzione non è mai stata attivata.

Quando un'API esterna cambia senza preavviso: la lezione dei webhook

Molte automazioni AI dipendono da webhook di fornitori esterni: pagamenti, CRM, messaggistica. Stripe, uno dei provider di webhook più diffusi al mondo, documenta esplicitamente che "webhook endpoints might occasionally receive the same event more than once" e raccomanda di non fidarsi dell'ordine di arrivo: "Stripe doesn't guarantee the delivery of events in the order that they're generated (...) track event IDs to identify duplicate deliveries instead", non della data o dell'ordine di ricezione. I retry automatici, in caso di mancata risposta, proseguono "for up to three days with an exponential back off in live mode", secondo la documentazione Stripe sui webhook. È lo stesso pattern descritto sopra per l'idempotenza, applicato a un caso concreto: senza un registro degli ID già processati, tre giorni di retry di un fornitore esterno possono trasformarsi in tre lead duplicati o tre notifiche ripetute allo stesso cliente.

Idempotenza e deduplica: la cura per lead saltati o duplicati

Lead saltati e dati duplicati hanno la stessa radice: manca un identificativo univoco per elemento. La Builders' Library di Amazon definisce un'operazione idempotente come quella "dove una richiesta può essere ritrasmessa o riprovata senza effetti collaterali aggiuntivi", e descrive il pattern usato in produzione: un identificativo fornito dal client permette al servizio di riconoscere che una richiesta è già stata elaborata e restituire la stessa risposta, invece di eseguirla due volte. Secondo la stessa fonte, il caso tipico è il lancio di un'istanza cloud: un timeout di rete lascia il client incerto se la risorsa sia stata creata, e un retry ingenuo può generarne due invece di una. Applicato a un'automazione: ogni lead, ogni email, ogni evento in ingresso deve avere una chiave che il sistema controlla prima di scrivere, non dopo. Un retry o un doppio trigger, con questa chiave in campo, non crea più un doppione e non fa perdere nulla.

Credenziali e token: gestirli prima che scadano, non dopo

Le chiavi API scadono per progettazione: è una misura di sicurezza, e la OWASP API Security Top 10 lo tratta come parte del rischio di autenticazione compromessa, raccomandando di non accettare token senza una validazione della scadenza e di seguire standard di autenticazione consolidati invece di soluzioni artigianali. Il punto operativo per un'automazione è più semplice della sicurezza applicativa in senso stretto, ma la logica è la stessa: un avviso automatico qualche giorno prima della scadenza costa pochissimo da implementare e previene la causa numero uno di fermo che troviamo sul campo.

Prototipo vs produzione: cosa cambia davvero







Monitoraggio e alert: la differenza tra un guasto gestito e uno scoperto da un cliente

Il "Site Reliability Engineering" di Google, riferimento diffuso tra chi progetta sistemi distribuiti, distingue due domande che ogni sistema di monitoraggio dovrebbe rispondere: "what's broken, and why?" Il "cosa" è il sintomo visibile (l'automazione non ha inviato l'email), il "perché" è la causa sottostante (il token era scaduto). Un log che registra solo "errore" senza distinguere le due cose costringe a indagare da zero ogni volta. Secondo lo stesso testo, i segnali utili da tracciare in un sistema sono quattro: latenza, traffico, errori e saturazione. Per un'automazione l'equivalente pratico è: quanto impiega un'esecuzione, quante ne arrivano, quante falliscono e quanto ci si avvicina a un limite di chiamate o di crediti. La stessa fonte è altrettanto netta sulla qualità degli alert: "every page should be actionable" e "every page response should require intelligence". Un alert che arriva per un errore transitorio, già risolto dal retry automatico, insegna a ignorare gli alert: è un rischio quanto non averne nessuno.

Non è una lista di attività da eseguire in sequenza rigida: è l'ordine in cui ha senso farsi le domande quando qualcosa si rompe, e prima che si rompa di nuovo.

Domanda 1: qual è il singolo step che fallisce?

Esegui il flusso con il caso reale che fallisce e leggi i log passo per passo: input, chiamata API, elaborazione AI, scrittura in output. Non correggere nulla finché non hai isolato il punto esatto. Correggere "a occhio" senza aver isolato lo step è il modo più comune di introdurre un secondo problema mentre si cerca di risolvere il primo.

Domanda 2: la causa è tra le tre più comuni?

Credenziali scadute, API cambiata, dati fuori formato coprono la maggioranza dei casi che vediamo. Controllali in quest'ordine prima di cercare cause più rare: sono anche i più rapidi da verificare.

Domanda 3: se è l'AI, è un problema di formato o di contenuto?

Se le risposte sono sbagliate, verifica separatamente le due proprietà che la documentazione OpenAI distingue esplicitamente: lo schema è rispettato? Il contenuto è corretto? Se il primo è vero e il secondo no, il problema è nel prompt o nell'assenza di una base di conoscenza a cui ancorare la risposta, non nel modello scelto. La guida OpenAI sulla valutazione dei prompt raccomanda di validare su un mix di "dati di produzione, dati creati da esperti di dominio e dati storici", coprendo anche casi limite e input ambigui, non solo i casi tipici: è lì che un prompt validato in fretta smette di reggere.

Domanda 4: un retry o un doppio trigger può creare un duplicato?

Se la risposta è sì, manca una chiave di idempotenza. È una delle correzioni più economiche e più spesso trascurate: basta un identificativo stabile per elemento, controllato prima della scrittura.

Domanda 5: quanto spesso va controllata un'automazione già in produzione?

Idealmente non "a mano": con log e alert azionabili il sistema avvisa da solo quando il tasso di errore supera una soglia definita, e questo sostituisce il controllo manuale periodico. In aggiunta, una revisione tecnica programmata, per esempio trimestrale, verifica scadenze delle credenziali, cambi recenti nelle API dei fornitori e qualità delle risposte AI su un campione di input recenti.

Domanda 6: cosa hai imparato che va applicato anche altrove?

Ogni guasto risolto dovrebbe cambiare qualcosa in modo permanente: una validazione in più, un alert nuovo, una chiave di idempotenza aggiunta. Se la correzione si limita a "riavviare" senza lasciare traccia, lo stesso guasto tornerà, spesso nello stesso punto.

Questi tre progetti del portfolio Skalo toccano, in ordine, i tre punti di rottura più frequenti: dati in ingresso, risposte AI e scrittura sui sistemi a valle. Descriviamo architettura e scelte tecniche verificabili, non percentuali di risultato non misurate.

Automated Lead Generation Engine (2025): dove si concentrano rate limit e duplicati

Il Lead Engine, realizzato nel 2025, è un motore che raccoglie dati da fonti esterne, li arricchisce e assegna un punteggio tramite AI prima di esportarli verso il CRM. È esattamente il tipo di sistema in cui si concentrano i guasti tipici di questa guida: rate limit delle fonti esterne durante lo scraping, dati non ancora normalizzati, contatti che rischiano di duplicarsi se lo stesso lead viene raccolto due volte da fonti diverse. Lo abbiamo costruito con scraping controllato e rate limiting (nel rispetto dei termini delle piattaforme scrapate), uno strato di staging dove i dati vengono validati prima di entrare nel CRM, e una deduplica che riconosce un contatto già visto prima di crearne una copia. È il tipo di prevenzione che, fatta a monte, evita la chiamata di emergenza che altrimenti arriva settimane dopo.

Skalo AI Hub Intelligent Chatbot (2025): risposte ancorate, non improvvisate

Il caso "l'assistente dà risposte sbagliate ai clienti" è esattamente ciò che l'AI Hub è costruito per prevenire. È una piattaforma multi-tenant per creare e gestire assistenti AI personalizzati, con dashboard di amministrazione, gestione clienti, un sistema di prompt e un simulatore per testare le conversazioni prima di metterle live. Il principio architetturale è quello descritto sopra a proposito degli output strutturati: la risposta deve avere un formato coerente, ma soprattutto deve attingere a una base di conoscenza reale (prodotti, policy, FAQ del cliente) invece di generare contenuto senza vincoli. Le risposte sbagliate si correggono così in fase di test, con il simulatore, non davanti al cliente finale.

Skalo CRM & Sales Operating System (2025-2026): la scrittura che non deve mai duplicare

Quando un'automazione "salta dei lead o duplica i dati", il punto critico è quasi sempre la sincronizzazione con il sistema che riceve il dato finale. Lo Skalo CRM, prodotto interno sviluppato tra il 2025 e il 2026, gestisce lead, contatti, pipeline commerciale, script di vendita, offerte e automazioni AI in un unico sistema. La disciplina che applichiamo qui, chiave univoca per record e scrittura pensata per essere ripetibile senza generare doppioni, è la stessa che portiamo quando integriamo un'automazione esterna con il gestionale di un cliente: un retry o un doppio invio non deve mai tradursi in due righe della stessa pratica commerciale.