Sono le 14:37 di un martedì. Un picco imprevisto di richieste entra nel contact center di un fornitore energetico. L'Agente AI che gestisce il canale chat inizia a rispondere con latenza fuori soglia. Quattro minuti dopo, le integrazioni con il CRM iniziano a restituire timeout intermittenti a seguito di una modifica API a valle non comunicata. Il sistema di monitoring intercetta l'anomalia prima che il volume diventi visibile al team operations del cliente. È così che il problema viene preso in carico e comunicato, prima di diventare rumore.
Questo è il punto in cui si misurano i vendor. Non nella demo. Non nel primo mese di go-live, quando tutto è monitorato e presidiato. Ma nel secondo anno, quando gli Agenti AI sono diventati infrastruttura critica, i volumi sono cresciuti e qualcosa va storto.
La domanda che ogni stakeholder dovrebbe fare in fase di procurement non è "il vostro sistema è affidabile?", ma "mostratemi esattamente cosa succede quando non lo è". Questo articolo è quella risposta.
Tassonomia e classificazione. Sapere cosa sta succedendo prima di agire
Un team di Agenti AI in produzione può degradare in modi strutturalmente diversi. Trattarli tutti come "il sistema non funziona" è il modo più rapido per allungare i tempi di risoluzione e comunicare male al cliente. La prima operazione utile è una tassonomia precisa.
- Degrado di latenza. Gli Agenti AI rispondono, ma oltre le soglie di accettabilità definite. In un canale vocale, uscire dalla "magic zone" sotto i 2-3 secondi di risposta rompe la naturalezza della conversazione. In un canale chat, superare i 10 secondi produce abbandono. Il sistema funziona, ma non abbastanza bene da offrire l'esperienza per cui è stato scelto.
- Errore di risposta. Gli Agenti AI producono output formalmente corretti nel formato, ma sbagliati nel contenuto - rispondono a una domanda sulla tariffa gas con informazioni relative alla tariffa luce, oppure citano una promozione scaduta da 48 ore. La causa è tipicamente un disallineamento tra la knowledge base e la configurazione degli Agenti, che la pipeline di validazione degli aggiornamenti è progettata per intercettare e che, nei casi residui, attiva l'incident management qui descritto.
- Integrazione fallita. Gli Agenti AI non riescono a leggere o scrivere su un sistema esterno - CRM, gestionale, sistema di ticketing - a causa di un timeout, una modifica API non comunicata o un problema di autenticazione a valle. Il sintomo visibile per l'utente finale è una risposta vaga o un'escalation non necessaria a un operatore umano.
- Allucinazione su topic critico. Gli Agenti AI generano una risposta plausibile ma fattualmente errata su un argomento ad alto impatto - un importo contrattuale, una scadenza normativa, le condizioni di un sinistro, una procedura di disdetta. In settori regolati come banking e insurance, questo tipo di incidente ha implicazioni che vanno oltre la customer experience e toccano la compliance.
- Interruzione del servizio. Gli Agenti AI non rispondono. Il canale è down. L'impatto è immediato e visibile: le conversazioni non vengono gestite, i clienti rimbalzano su canali alternativi o abbandonano. È l'incidente più semplice da rilevare, perché il perimetro del problema è netto - anche se la complessità della risoluzione dipende dalla causa upstream.
Classificazione per severità: P1, P2, P3
La severità non è un giudizio soggettivo - è una classificazione operativa che determina chi interviene, con quale urgenza e come si comunica. Definirla in anticipo, per iscritto e concordata con il cliente, è la premessa di qualsiasi SLA che abbia senso.
P1 - Impatto immediato sulla produzione. Il servizio è interrotto o gravemente compromesso per una quota significativa degli utenti finali. Include l'interruzione completa del canale, il degrado di latenza che supera la soglia critica su volumi sostenuti, o l'allucinazione su topic critico che ha già raggiunto utenti reali. Richiede intervento immediato e aggiornamenti a cadenza regolare al cliente fino alla risoluzione.
P2 - Degrado rilevabile, continuità garantita. Il servizio è operativo ma con performance degradate - latenza elevata su una minoranza di sessioni, errori di risposta su una specifica categoria di intent, integrazione con un sistema secondario non funzionante. L'utente finale percepisce una riduzione della qualità, ma il canale regge. Richiede intervento entro la finestra contrattualizzata, con comunicazione al cliente nello stesso intervallo.
P3 - Anomalia non critica. Comportamenti inattesi che non impattano l'esperienza utente in modo misurabile - un pattern di risposta subottimale su casi edge, una metrica di monitoring che si discosta dalla baseline senza superare le soglie di allerta, un log di errore isolato. Viene tracciato, analizzato e incluso nel ciclo di miglioramento. Non richiede intervento urgente né comunicazione immediata al cliente, ma viene riportato nel report mensile aggregato e nelle review periodiche del servizio.
Detection e response. Intercettare il problema prima che impatti il cliente
Il presupposto di un buon incident management è non dipendere dal cliente per scoprire che qualcosa è rotto. Questo richiede un layer di osservabilità che monitora in continuo - 24/7, non solo negli orari di presidio - un insieme di metriche operative definite in fase di onboarding.
Le soglie non sono generiche. Variano per settore, canale e disegno del workflow. La latenza accettabile su una chat asincrona non è quella di una voce inbound, e il tasso di escalation che segnala un problema dipende dall'architettura conversazionale scelta. Ogni deployment ha la propria configurazione di monitoring, negoziata con il cliente e documentata prima del go-live.
Le dimensioni tipicamente monitorate in modo continuativo includono la latenza media e al percentile 95, il tasso di completamento delle conversazioni, il tasso di errori sulle integrazioni, la frequenza di risposte fuori perimetro rilevate dai guardrails e la disponibilità del canale. A queste possono affiancarsi, a seconda del deployment, metriche di qualità valutate su campioni, coerenza delle risposte con la knowledge base, sentiment delle conversazioni, tasso di rifiuto dell'utente.
Alert e escalation verso il team on-call
Quando una soglia viene superata, il sistema genera un alert. La catena di escalation è predefinita - non improvvisata nel momento dell'emergenza - e differenziata per severità.
Un alert P1 raggiunge immediatamente il team on-call, disponibile 24/7 nei contratti enterprise. Non un sistema di ticketing generico, ma un team che ha accesso diretto alla configurazione di produzione del cliente e può intervenire sui sistemi nei minuti che seguono l'alert.
Un alert P2 raggiunge il team di servizio con escalation al responsabile tecnico del cliente nel caso in cui la risoluzione superi la finestra di intervento definita nello SLA.
Un alert P3 viene aggregato nel report periodico di monitoring e portato all'attenzione del cliente nel ciclo di review regolare, senza generare rumore non necessario, ma senza nascondere nulla.
Comunicazione al cliente nelle prime fasi
La comunicazione durante un incidente attivo è una disciplina a sé stante. Tre sono i principi operativi che distinguono un vendor maturo da uno che improvvisa.
L'obiettivo è che il primo contatto avvenga prima che il cliente si accorga del problema, o al più in contemporanea. Ricevere una chiamata dal cliente che segnala un disservizio mai intercettato dai sistemi di monitoring è il segnale che le soglie vanno riviste, non un imprevisto da accettare.
Gli aggiornamenti sono a cadenza definita, non "appena ci sono novità". In un P1, gli aggiornamenti seguono una cadenza ravvicinata definita nello SLA - anche quando l'unica notizia è che il team sta lavorando e non ha ancora individuato la causa radice. Il silenzio durante un incidente è più destabilizzante di un aggiornamento neutro.
Il linguaggio è operativo, non elusivo. "Stiamo verificando" non è un aggiornamento - è una risposta che aumenta l'ansia senza ridurla. Un aggiornamento utile ha la struttura: cosa sta succedendo, cosa stiamo facendo, quando arriva il prossimo aggiornamento.
Risoluzione, root cause analysis e post-mortem
Le azioni di risoluzione seguono una gerarchia di intervento ordinata per impatto e reversibilità.
La prima linea è sempre la limitazione del perimetro - ridurre il perimetro di risposta dell'Agente agli ambiti in cui si comporta correttamente, dirottando le richieste problematiche verso un operatore umano o verso un messaggio di cortesia che non espone il brand a rischi. È una misura temporanea, ma consente di mantenere il servizio parzialmente operativo mentre si lavora alla causa radice.
La seconda linea è il rollback alla configurazione precedente. Nei Self-improving Agents di indigo.ai i miglioramenti agiscono sulla configurazione dell'Agente - proposti dal sistema e approvati da un operatore umano - non sui pesi del modello sottostante. Operare a livello di configurazione, e non di fine-tuning, rende il rollback rapido, deterministico e reversibile, eseguibile in produzione senza interruzione percepibile del servizio. Un rollback da fine-tuning, al contrario, richiede tipicamente ore o giorni.
La terza linea è l'intervento diretto sulla configurazione - modifica delle istruzioni, aggiornamento della knowledge base, correzione delle policy di guardrail - applicata dopo aver identificato la causa radice con sufficiente certezza da non rischiare di introdurre nuovi problemi.
Root Cause Analysis. Metodologia strutturata
La root cause analysis non è un'attività opzionale da fare "se c'è tempo" dopo un P1. È un processo obbligatorio con output documentato, che alimenta sia la prevenzione sia il post-mortem condiviso con il cliente.
La metodologia segue una struttura in quattro passi.
Ricostruzione della timeline. Il punto di partenza è sempre una timeline precisa - non una narrazione approssimativa. Quando è stato rilevato il primo segnale anomalo? Quando è scattato l'alert? Quando ha avuto inizio la degradazione effettiva, anche se non ancora visibile? I sistemi di tracing distribuito consentono di ricostruire questa sequenza con granularità fine, identificando il componente in cui il problema ha avuto origine.
Identificazione della causa radice. La tecnica dei 5 perché applicata sistematicamente. L'obiettivo non è trovare qualcosa da correggere, è trovare il meccanismo che ha permesso al problema di presentarsi, in modo da intervenire su quello e non sul sintomo.
Analisi degli impatti. Quante sessioni sono state impattate? Quale porzione degli utenti ha ricevuto una risposta errata o degradata? Ci sono stati impatti su sistemi a valle, come ticket aperti in modo erroneo o escalation non necessarie? Se l'incidente ha coinvolto dati personali - ad esempio, un Agente che ha restituito dati di un cliente a un utente diverso - indigo.ai, in qualità di responsabile del trattamento, notifica il cliente senza ingiustificato ritardo e gli fornisce tutte le evidenze tecniche necessarie a valutare il rischio. La decisione sulle notifiche alle autorità e agli interessati spetta al cliente in qualità di titolare, secondo la ripartizione di responsabilità definita nel Data Processing Agreement.
Piano di non-recurrence. Per ogni causa radice identificata, un'azione specifica con responsabile e scadenza. Non "miglioreremo il monitoring", ma un intervento puntuale, con metrica e data di completamento.
Post-mortem condiviso con il cliente
Il post-mortem è il documento con cui un vendor dimostra di avere a cuore la relazione oltre la singola emergenza. Il suo valore non è nella descrizione di quello che è andato storto - che il cliente già conosce - ma nella trasparenza sul processo di analisi e nelle garanzie concrete che lo stesso problema non si ripresenti.
Il formato standard include un sommario esecutivo leggibile da un CEO senza background tecnico, la timeline ricostruita, la causa radice identificata, l'impatto quantificato, le azioni correttive con responsabile e scadenza, e un piano di follow-up strutturato.
La tempistica di consegna è parte dello SLA contrattualizzato in fase di onboarding, differenziata per severità dell'incidente. Non "appena pronto".
Una review di follow-up strutturata, tipicamente entro le settimane successive alla risoluzione, non è una formalità. In quella sede si verifica che le azioni correttive siano state effettivamente implementate, e il cliente ha accesso ai dati di monitoring post-incidente per validare che il comportamento anomalo non si sia ripresentato.
Prevention. Ogni incidente alimenta il sistema
Il ciclo si chiude con la prevenzione. Ogni incidente documentato contribuisce a tre output concreti.
Il primo è l'aggiornamento del sistema di monitoring - nuove soglie, nuovi parametri, nuovi scenari di alert che l'incidente ha rivelato come non coperti. Il monitoring non è configurato una volta per tutte al go-live. Si affina nel tempo, alimentato dall'esperienza operativa reale.
Il secondo è l'aggiornamento dei test pre-deployment. Ogni causa radice identificata si traduce in un test aggiuntivo nella pipeline di validazione degli aggiornamenti. Se un incidente è stato causato da una modifica alla knowledge base non testata su un sottoinsieme di intent critici, quel sottoinsieme diventa parte permanente della suite di test di regressione.
Il terzo è l'alimentazione del ciclo dei Self-improving Agents. Le conversazioni impattate dall'incidente vengono analizzate dall'Observer Agent per estrarre pattern, valutare la qualità delle risposte degradate e proporre aggiornamenti mirati alla configurazione - con approvazione umana prima di qualsiasi modifica in produzione.
Un sistema AI in produzione su volumi enterprise non è mai esente da degradazioni, edge case o sorprese delle integrazioni. La domanda non è se capiterà - è con chi vuoi essere quando capita. Con un vendor che scopre il problema da te e risponde improvvisando, o con uno che te lo ha già comunicato, sta già lavorando alla causa radice e ti consegnerà un post-mortem strutturato nei tempi previsti dallo SLA.
L'incident management strutturato non è solo buona ingegneria. È la forma più concreta di fiducia che un vendor enterprise può costruire.
FAQ
Come vengono definite le soglie di monitoring e chi ha visibilità su di esse?
Le soglie vengono definite in fase di onboarding insieme al team tecnico del cliente, sulla base di volumi attesi, settore e criticità del canale. Non sono valori standard uguali per tutti. Il cliente ha accesso in tempo reale al dashboard di monitoring e ogni aggiornamento alle soglie viene concordato e tracciato.
Cosa succede se un incidente coinvolge dati personali degli utenti finali?
È un perimetro che trattiamo con priorità separata rispetto all'incident management tecnico. In qualità di responsabile del trattamento, indigo.ai notifica il cliente senza ingiustificato ritardo e ne supporta la valutazione del rischio con tutte le evidenze tecniche necessarie. Gli obblighi di notifica alle autorità e di eventuale comunicazione agli utenti impattati restano in capo al cliente in qualità di titolare, secondo quanto definito nel Data Processing Agreement.
Il post-mortem viene consegnato anche per gli incidenti P3?
Per i P3 il formato è semplificato: un report mensile di anomalie aggregate con le azioni correttive adottate, anziché un documento stand-alone per ogni evento. Il principio è che ogni anomalia venga tracciata e analizzata, ma la profondità del reporting resta proporzionale all'impatto.
