Tutti i modi in cui la tua AI può fallire: una mappa della Failure Intelligence

Il tuo agente AI è in esecuzione. La latenza è ottimale. I log degli errori sono silenziosi. Le dashboard dell'infrastruttura sembrano in salute.

Nel frattempo, un utente ha appena riformulato la stessa domanda tre volte, ha ricevuto una risposta vaga e ha rinunciato. Un altro ha chiesto qualcosa che l'agente non era configurato per gestire e ha ricevuto un rifiuto senza alcuna spiegazione. Un terzo ha avviato una conversazione, ha raggiunto un vicolo cieco e se n'è andato senza risolvere ciò per cui era venuto.

Nessuno di questi eventi ha generato un codice di errore. Il monitoraggio dell'infrastruttura li ha registrati come interazioni riuscite. Dal punto di vista del sistema, tutto ha funzionato. Dal punto di vista dell'utente, l'agente ha fallito.

Secondo il report State of AI 2025 di McKinsey, l'88% delle organizzazioni utilizza l'AI in almeno una funzione, ma solo il 39% registra un impatto sull'EBIT a livello aziendale. Gartner prevede che oltre il 40% dei progetti di AI agentica sarà cancellato entro il 2027, citando controlli di rischio inadeguati e un valore aziendale poco chiaro. Il modello di fallimento è coerente: la tecnologia funziona in modo affidabile mentre l'esperienza utente fallisce silenziosamente.

Comprendere come gli agenti di AI deludono gli utenti è il primo passo per risolvere i problemi giusti.

Il divario nel monitoraggio dell'infrastruttura

Il monitoraggio dell'infrastruttura ti dice quando il tuo sistema si blocca. Misura la latenza, il tempo di attività, il consumo di token e i tassi di errore. Questi sono parametri necessari. Ma non possono dirti quando i tuoi utenti rinunciano.

La distinzione è importante perché la maggior parte dei fallimenti degli agenti AI non sono fallimenti del sistema. Sono fallimenti dell'esperienza utente. L'agente ha risposto. La risposta è stata tecnicamente generata senza errori. Ma l'utente non ha ottenuto ciò per cui era venuto e se n'è andato.

Questi fallimenti sono invisibili al monitoraggio dell'infrastruttura perché richiedono la lettura di ciò che è accaduto nella conversazione, non solo se la chiamata API è stata completata. Nei log di sistema, una richiesta rifiutata appare identica a una andata a buon fine. Una risposta che non ha affrontato l'effettiva domanda dell'utente è indistinguibile da una che ci è riuscita. Una conversazione terminata con un abbandono appare identica a una terminata con una risoluzione.

Il divario tra "il sistema ha funzionato" e "l'utente ha ottenuto valore" è il punto in cui si perde la maggior parte del ROI dell'AI aziendale.

Una tassonomia dei fallimenti lato utente

I fallimenti lato utente rientrano in sei tipologie identificabili. Ognuna ha cause distinte, segnali distinti e correzioni distinte. Sapere quale tipo predomina nella tua installazione ti dice dove concentrare gli sforzi di miglioramento.

1. Richieste non gestite

L'AI rifiuta o non riesce a rispondere a una richiesta legittima dell'utente. L'agente si scontra con un limite di policy, incontra una funzionalità mancante o attiva un guardrail troppo ampio, producendo un rifiuto o una mancata risposta.

Questo tipo di fallimento è particolarmente dannoso perché combina due segnali negativi contemporaneamente: l'utente non ha ottenuto ciò di cui aveva bisogno e l'interazione ha comunicato un limite rigido senza spiegarlo. Gli utenti che riscontrano richieste non gestite senza una spiegazione chiara del perché o di cosa fare in alternativa tendono a non riprovare.

I segnali da monitorare sono il volume dei rifiuti per argomento, il tasso di rifiuto rispetto al volume totale delle sessioni e il tasso di abbandono dell'utente a seguito di un rifiuto. Tassi di rifiuto elevati su una specifica categoria di argomenti indicano un problema di ambito della policy o un guardrail che si attiva su query innocue. La soluzione consiste solitamente in una di queste tre opzioni: ampliare l'ambito della policy, ottimizzare la soglia del guardrail o migliorare la risposta di fallback in modo che gli utenti sappiano cosa possono fare in alternativa.

2. Fallimento del task

L'AI inizia ad aiutare ma fornisce un output incompleto, errato o inutilizzabile. Il task dell'utente non viene completato, anche se l'agente ci ha provato.

Il fallimento del task è il tipo di fallimento più direttamente dannoso per le implementazioni di produttività interna. Un dipendente che chiede a un agente AI di aiutarlo con la revisione di un documento e riceve un riassunto parziale o impreciso non ha risparmiato tempo. Potenzialmente ha perso tempo se agisce in base all'output prima di averlo verificato.

I segnali sono il tasso di completamento del task, la frequenza delle richieste di chiarimento all'interno della stessa sessione e l'abbandono dopo risposte parziali. Tassi elevati di richieste di chiarimento su una specifica categoria di task indicano che la prima risposta sistematicamente non riesce a risolvere il task in un unico turno. Le soluzioni riguardano tipicamente la copertura della knowledge base, la qualità del recupero (retrieval) o la progettazione dell'output strutturato.

3. Fallimenti di lingua e localizzazione

Un disallineamento tra la lingua o la localizzazione dell'utente e le capacità dell'agente. Ciò include risposte fornite nella lingua sbagliata, scarsa qualità della traduzione o output culturalmente inappropriati.

Questo tipo di fallimento viene sistematicamente rilevato meno del dovuto perché influisce principalmente su gruppi di utenti i cui dati di utilizzo sono proporzionalmente inferiori nei report aggregati. Un'azienda multinazionale in cui un agente AI funziona bene per le query in lingua inglese ma in modo incoerente per quelle in spagnolo o francese vedrà questo fenomeno nei pattern di utilizzo geografici e linguistici, non nelle metriche generali.

I segnali sono il tasso di disallineamento linguistico, la variazione dell'adozione in base alla geografia e l'abbandono in base alla localizzazione. La correzione dipende dall'installazione: supporto di modelli multilingue, instradamento basato sul rilevamento della lingua o configurazione dell'agente specifica per l'area geografica.

4. Risposte vuote o nulle

L'AI non restituisce nulla. Output vuoti, risposte nulle o errori di backend che si presentano all'utente come silenzio.

Questo è il tipo di fallimento che ha più probabilità di apparire nel monitoraggio dell'infrastruttura, ma spesso appare in modo incoerente perché potrebbe correlarsi a specifici pattern di input piuttosto che al carico generale del sistema. Gli utenti che incontrano risposte vuote non hanno informazioni su se riprovare, riformulare o rinunciare.

I segnali sono il tasso di risposte vuote, la correlazione con specifiche strutture di input o argomenti e il comportamento dell'utente a seguito di una risposta vuota. La correzione risiede nella gestione degli errori: risposte di fallback, visualizzazione corretta degli errori e rilevamento dei pattern di input che intercettano i casi limite prima che raggiungano il livello di generazione.

5. Segnali di frustrazione dell'utente

Segnali impliciti dell'utente che non sta ottenendo ciò di cui ha bisogno. Riformulazione ripetuta della stessa query, linguaggio di escalation, calo del sentiment nel corso dei turni di conversazione e abbandono della sessione dopo molteplici scambi falliti.

Questo tipo di fallimento è il più comune e il più difficile da rilevare con il monitoraggio tradizionale, perché nessuno dei singoli segnali costituisce un errore tecnico. Un utente che riformula una domanda tre volte di seguito genera tre chiamate API andate a buon fine. Il pattern di frustrazione è visibile solo quando il comportamento della conversazione viene analizzato nel suo complesso.

I segnali sono la frequenza di riformulazione per sessione e per argomento, la traiettoria del sentiment attraverso i turni di conversazione e la velocità di abbandono della sessione. Un'elevata frequenza di riformulazione su una specifica categoria di intento indica un problema di rilevamento dell'intento: l'agente non comprende ciò che gli utenti in quella categoria stanno effettivamente chiedendo. Le soluzioni sono l'ottimizzazione dei prompt, il miglioramento della classificazione dell'intento o l'aggiunta di un percorso di escalation che offra agli utenti un'alternativa quando l'agente non risolve la loro richiesta.

6. Feedback negativo esplicito

Valutazioni negative dirette da parte degli utenti: pollice in giù, valutazioni basse, risposte "non utili". Il segnale più chiaro e anche il più raro. La ricerca sull'AI conversazionale mostra costantemente che la maggior parte degli utenti insoddisfatti non lascia un feedback esplicito. Semplicemente smette di usare l'agente.

Il feedback esplicito è prezioso proprio perché rappresenta un giudizio deliberato dell'utente, non un'inferenza comportamentale implicita. Ma dovrebbe essere letto come la punta visibile di un iceberg molto più grande. Quando il feedback negativo esplicito su una categoria di argomenti aumenta, l'insoddisfazione effettiva in quella categoria è in genere diverse volte superiore.

I segnali da monitorare sono il tasso di feedback negativi per argomento di conversazione e per segmento di utenti, e la correlazione tra feedback espliciti negativi e segnali di frustrazione impliciti. L'uso più efficace dei dati di feedback esplicito è in combinazione con i segnali impliciti: il feedback esplicito individua dove si concentrano i problemi, i segnali impliciti quantificano l'entità di tali problemi.

Perché il tipo di fallimento è importante per la definizione delle priorità

Diversi tipi di fallimento richiedono interventi diversi da parte di team diversi. Le richieste non gestite necessitano di decisioni di policy e di prodotto. I fallimenti dei task necessitano di lavoro di ingegneria e di dati. I problemi linguistici necessitano di un'infrastruttura di localizzazione. Le risposte vuote necessitano di gestione degli errori. I segnali di frustrazione richiedono un lavoro sui prompt e sulla UX. Il feedback esplicito necessita di una revisione dei contenuti e della qualità.

Senza una tassonomia, questi problemi emergono come un segnale indifferenziato di "l'AI non funziona abbastanza bene", su cui non si può agire con precisione. Con una tassonomia, ogni tipo di fallimento ha un proprietario chiaro e un intervento preciso.

La distribuzione dei fallimenti varia anche in base al tipo di installazione e alla fase. Nei servizi finanziari, i fallimenti dei task tendono a dominare perché la soglia di accuratezza per risposte complete e precise è alta e le informazioni parziali sono spesso inutilizzabili. Nelle installazioni di assistenza clienti, le richieste non gestite registrano un picco iniziale quando gli utenti testano l'ambito delle capacità dell'agente. Negli strumenti di produttività interna, durante i primi 30 giorni, i segnali di frustrazione sono solitamente i più elevati, poiché i dipendenti imparano a interagire efficacemente con l'agente.

Anche i pattern temporali sono importanti. All'inizio di un'installazione, i segnali di frustrazione e le richieste non gestite tendono a essere più elevati mentre si stabilisce l'ambito dell'agente e gli utenti ne apprendono le capacità. Man mano che l'installazione matura e i guardrail si stringono, i fallimenti dei task e i problemi linguistici diventano spesso il pattern dominante. Una tassonomia dei fallimenti rende questi cambiamenti visibili e pronti per l'azione.

Cosa misurare e come agire

Tre pratiche rendono l'analisi dei fallimenti utile dal punto di vista operativo e non solo interessante a livello analitico.

Monitora il volume dei fallimenti per tipo nel tempo, non solo in modo aggregato. Un calo del tasso di fallimento complessivo che nasconde un picco nei fallimenti dei task in una funzione specifica è un segnale più urgente di quanto suggerisca il dato aggregato. Il tracciamento a livello di tipologia fa emergere questi pattern.

Correlare i tipi di fallimento con i risultati aziendali. I tassi di richieste non gestite che si correlano con l'abbandono della sessione hanno una priorità diversa rispetto a quelli che si correlano con utenti che risolvono con successo autonomamente tramite un percorso di query diverso. I tassi di fallimento del task che si correlano con i dipendenti che tornano a processi manuali hanno una priorità più alta rispetto a quelli in cui gli utenti trovano soluzioni alternative all'interno dell'agente. L'impatto aziendale definisce le priorità dell'elenco delle correzioni in modo più affidabile rispetto al solo volume dei fallimenti.

Risolvi un tipo alla volta e misura il prima e il dopo. Affrontare più tipi di fallimento contemporaneamente rende impossibile attribuire il miglioramento a una modifica specifica. I cicli di miglioramento più affidabili sono: identificare il tipo di fallimento a più alto impatto, effettuare un intervento specifico, misurare se il tasso di fallimento in quella categoria migliora e se la metrica aziendale a cui si correla si muove di conseguenza, quindi passare alla priorità successiva.

Nebuly fa emergere questi pattern di fallimento nelle conversazioni del tuo agente AI, categorizzandoli per tipo e mostrando come si correlano con i risultati di adozione e fidelizzazione.

Nebuly

Nebuly è la piattaforma di ROI per l'AI aziendale. Si collega agli agenti AI su cui si basa la tua attività, agli assistenti con cui interagiscono i tuoi clienti e agli strumenti che i tuoi dipendenti usano ogni giorno, tra cui Claude, ChatGPT e Copilot, e traduce tale attività in valore aziendale. Quanto tempo viene risparmiato tra i team. Quali ricavi sta influenzando la tua AI. Come si presentano l'adozione e la competenza nell'uso dell'AI nella pratica, tra dipartimenti e aree geografiche. Tutto aggregato a livello organizzativo, mai legato ai singoli individui.

Se hai bisogno di chiarezza su ciò che il tuo investimento in AI sta effettivamente offrendo, prenota una demo.