Perché le conversazioni AI falliscono: le dieci cause

Analizzare gli errori di un agente AI significa classificare ogni conversazione AI fallita in base alla causa, prima che qualcuno la corregga. La maggior parte degli errori chiamati “allucinazioni” è qualcos’altro: un articolo mancante, una policy superata o ambigua, un errore di recupero dei contenuti, uno strumento che non funziona o un passaggio a una persona gestito male. Ogni causa ha un responsabile e una correzione diversi, quindi l’etichetta decide se la correzione funziona.

In breve

• “Allucinazione” descrive un sintomo (una risposta sbagliata data con sicurezza), non una causa. La consideri l’ultima spiegazione, non la prima.
• Dieci cause coprono quasi ogni conversazione AI fallita nell’assistenza, dalle lacune nella knowledge base alla confusione da parte del cliente.
• Una domanda risolve la maggior parte dei casi: esisteva una fonte approvata che rispondeva, e l’agente l’ha usata?
• Le cause legate ai contenuti vanno al responsabile della knowledge base o della policy, quelle legate agli strumenti all’engineering, e solo gli errori di ragionamento al team che configura l’agente AI.
• Misuri ogni settimana la distribuzione per causa ogni 1.000 conversazioni. Le sole quote ingannano, perché una causa può crescere in quota mentre diminuisce in numero.

Perché i team chiamano allucinazione ogni errore di un agente AI?

I team chiamano allucinazione ogni errore perché la trascrizione mostra solo l’output: una risposta sbagliata, data con sicurezza. La causa sta più a monte, nei contenuti, nella policy, nel recupero dei contenuti, in uno strumento o nelle regole di passaggio. Senza un passaggio che classifichi la causa, vince la parola più familiare e la correzione finisce sul prompt.

La parola ha un significato preciso. Il profilo di rischio del NIST per l’AI generativa definisce la confabulazione, “nel linguaggio comune chiamata anche allucinazione”, come il fenomeno per cui i sistemi “generano e presentano con sicurezza contenuti errati o falsi” (NIST AI 600-1, sezione 2.2, in inglese). Questo copre il modello che inventa qualcosa. Non copre un agente che ha ripetuto fedelmente un articolo superato sui rimborsi, né uno che ha seguito una policy che nessuno ha mai scritto.

La differenza conta perché l’etichetta sbagliata manda il lavoro al team sbagliato. Una modifica al prompt non può correggere un articolo che non esiste. Quando Pylon, azienda di software per l’assistenza, ha classificato circa 200 ticket che il suo agente AI aveva passato a una persona in una settimana della propria coda, le lacune di contenuto “rappresentavano più della metà delle escalation” e le richieste di funzionalità il 15% (Pylon, settembre 2026, in inglese). Sono i dati di una sola azienda, non un benchmark, ma nessuna delle due cause è un problema del modello.

Questa guida fa parte della nostra guida sulla gestione delle policy per gli agenti AI, che spiega come le policy vengono scritte, assegnate a un responsabile e versionate. Qui ci concentriamo sul passo che precede la correzione: dare il nome giusto alla causa.

Quali sono le dieci ragioni per cui le conversazioni AI falliscono?

Le conversazioni AI nell’assistenza falliscono per dieci ragioni principali: una lacuna nella knowledge base, contenuti superati o contraddittori, una policy mancante o ambigua, un errore di recupero dei contenuti, un errore di ragionamento o un’allucinazione, un errore di un’azione o di uno strumento, un passaggio a una persona fallito, un errore di ambito, un bug del prodotto o una richiesta di funzionalità, e un problema da parte del cliente. Ognuna lascia una traccia diversa nella trascrizione.

La tabella qui sotto è la tassonomia da copiare. La usi come elenco di scelta nel suo modulo di revisione, una causa per ogni criterio non superato.

Etichetti il criterio non superato, non l’intera conversazione, perché una conversazione può fallire per due cause. Le cause 6 e 7 si nascondono spesso nei numeri di contenimento; la nostra guida sugli errori silenziosi degli agenti AI spiega come farle emergere. Per gli operatori, la distinzione equivalente è nella nostra guida su errore dell’operatore o errore di processo (in inglese).

Come si distingue un’allucinazione da una policy mancante?

Si distingue un’allucinazione da una policy mancante controllando la fonte. Se una fonte approvata e aggiornata rispondeva alla domanda e l’agente se n’è discostato, è un’allucinazione o un errore di ragionamento. Se nessuna fonte copriva il caso, o la regola esiste solo nella testa degli operatori esperti, è una policy mancante, e nessuna modifica al modello la risolverà.

Le quattro coppie che si confondono più spesso:

• Allucinazione o policy mancante. Il test è: “un operatore nuovo, leggendo solo le sue fonti scritte, avrebbe potuto rispondere correttamente?” Se no, l’agente AI non aveva nulla a cui restare fedele.
• Allucinazione o contenuti superati. Se il fatto sbagliato compare parola per parola in un articolo, l’agente ha fatto il suo lavoro. L’errore è l’articolo.
• Allucinazione o errore di recupero. Se l’articolo giusto esiste ma la risposta si adatta a un tema vicino, l’agente ha risposto fedelmente dalla pagina sbagliata. La retrieval-augmented generation, il metodo usato da molti agenti AI di assistenza, abbina un modello a una ricerca nei suoi contenuti (Lewis et al., 2020, in inglese), quindi il passaggio di ricerca può fallire da solo.
• Azione allucinata o errore dello strumento. “Il suo rimborso è in arrivo” senza alcun rimborso nel sistema è o l’agente che dichiara un’azione mai compiuta, o una chiamata a uno strumento fallita senza segnalarlo. Il log dello strumento le dice quale dei due. La nostra guida sull’audit del tasso di risoluzione degli agenti AI spiega come confrontare le azioni dichiarate con i record nei sistemi.

La nostra guida su come individuare le allucinazioni degli agenti AI descrive la routine per le vere allucinazioni, una volta isolate. Questa pagina è il filtro che decide quali sono vere.

L’albero decisionale per lo smistamento: dieci domande in ordine

Il modo più rapido per classificare una conversazione AI fallita è rispondere a un elenco fisso di domande in un ordine fisso e fermarsi al primo “sì” o “no” che indica una causa. L’ordine conta: esclude le cause legate al cliente, al prodotto e ai sistemi prima di incolpare i contenuti, e incolpa i contenuti prima del modello.

Lo copi nel suo modulo di revisione. Risponda per un criterio non superato alla volta.

1. Una persona avrebbe capito che cosa voleva il cliente da ciò che ha scritto? No: problema da parte del cliente (causa 10). Sì: prosegua.
2. La richiesta era una di quelle che l’agente AI dovrebbe gestire? No, e l’ha gestita comunque: errore di ambito (causa 8). Sì: prosegua.
3. Il problema di fondo era un difetto, o qualcosa che il prodotto non fa? Sì: bug del prodotto o richiesta di funzionalità (causa 9). No: prosegua.
4. L’agente doveva compiere o verificare un’azione (ricerca, rimborso, disdetta, aggiornamento), e quella chiamata è fallita, è andata in timeout o è stata rifiutata? Sì: errore di un’azione o di uno strumento (causa 6). No: prosegua.
5. La conversazione doveva passare a una persona, in un altro momento o con un contesto migliore? Sì: passaggio a una persona fallito (causa 7). No: prosegua.
6. Una fonte approvata risponde a questa domanda? No, e la regola è chiara a tutti: lacuna nella knowledge base (causa 1). No, e la regola dipende da chi la interpreta: policy mancante o ambigua (causa 3). Sì: prosegua.
7. Quella fonte è aggiornata, ed è l’unica fonte sul tema? No: contenuti superati o contraddittori (causa 2). Sì: prosegua.
8. L’agente ha usato quella fonte per questa risposta? No: errore di recupero dei contenuti (causa 4). Sì: prosegua.
9. La risposta corrisponde alla fonte? No: errore di ragionamento o allucinazione (causa 5). Sì: prosegua.
10. Il criterio stesso è giusto? Se l’agente ha seguito fedelmente una fonte aggiornata e approvata e ha comunque fallito, il criterio della scheda di valutazione potrebbe essere sbagliato. Lo mandi al QA lead per la calibrazione invece di forzare una causa.

La domanda 10 è la valvola di sicurezza: una tassonomia che non può dire “il nostro criterio era sbagliato” dà la colpa a chi resta. Conti quante volte arriva alla domanda 9. È l’unico percorso che finisce con “allucinazione”.

Chi corregge ogni causa, e come la si smista?

Ogni causa ha un responsabile, deciso dal punto in cui va fatta la correzione: i contenuti vanno al responsabile della knowledge base o della policy, i sistemi all’engineering, il prodotto al team di prodotto, e solo istruzioni e ragionamento al responsabile dell’AI. Smisti la conversazione con le prove allegate, mai solo con un conteggio.

Indichi ogni responsabile come persona, non come team. Una nota di smistamento richiede quattro elementi: la causa, due o tre conversazioni di esempio con le righe che falliscono evidenziate, il motivo di contatto interessato con il suo volume settimanale, e la data in cui lo rivaluterà. Senza gli esempi, il team che riceve discute la classificazione invece di correggere.

Correggere un agente AI non è fare coaching a una persona: la correzione deve cambiare i contenuti o la configurazione che l’agente legge. Il nostro articolo su coaching delle persone e correzione degli agenti AI spiega questa distinzione. Per le cause 6 e 8, la correzione giusta a volte è un limite, non una risposta migliore. OWASP indica “funzionalità eccessiva”, “permessi eccessivi” e “autonomia eccessiva” come cause di fondo delle azioni dannose degli agenti (OWASP LLM06, in inglese), ed è da qui che partono le nostre guide sui guardrail per agenti AI e sui livelli di autonomia degli agenti AI.

Come si svolge lo smistamento settimanale degli errori dell’AI?

Svolga lo smistamento degli errori dell’AI in una sessione settimanale da 45 a 60 minuti: raccolga le conversazioni fallite, le raggruppi per motivo di contatto, classifichi i gruppi principali con l’albero decisionale, assegni ogni causa al suo responsabile con gli esempi e verifichi se le correzioni della settimana precedente hanno tenuto. Classifichi gruppi, non singole conversazioni, così la sessione regge al crescere del volume.

Una routine che funziona:

1. Lunedì: raccolga gli errori. Prenda ogni conversazione AI che la settimana scorsa non ha superato un criterio critico (accuratezza, policy, azione, escalation). Se valuta solo un campione, aggiunga ogni conversazione con una riapertura, un reclamo o un nuovo contatto entro 7 giorni.
2. Raggruppi per motivo di contatto. Rimborsi, cambi di indirizzo, problemi di accesso. Inizi dai primi cinque motivi per numero di errori.
3. Classifichi da tre a cinque conversazioni per gruppo. Applichi le dieci domande. Se concordano, etichetti il gruppo. Se divergono, il gruppo contiene due problemi: lo divida.
4. Smisti. Un ticket per causa e per motivo di contatto, a un responsabile nominativo, con gli esempi e una data di rivalutazione.
5. Verifichi la settimana scorsa. Per ogni correzione rilasciata, confronti il numero di errori su quel motivo di contatto prima e dopo. Una correzione che non ha spostato il numero era la correzione sbagliata o la causa sbagliata.
6. Registri. Una riga per gruppo: settimana, motivo di contatto, causa, numero, responsabile, correzione, risultato. Questo registro è la sua distribuzione degli errori nel tempo.

La sessione la conduce il QA lead con il responsabile dell’AI, il responsabile della knowledge base e un responsabile delle support operations. Policy, engineering e prodotto partecipano solo quando c’è un loro punto in elenco. I passaggi a una persona falliti spesso emergono solo confrontando più conversazioni, ed è lì che aiuta il QA della customer journey.

Come si misura nel tempo la distribuzione degli errori dell’AI?

Misuri la distribuzione degli errori come numero di errori ogni 1.000 conversazioni AI, suddiviso per causa, ogni settimana, accanto alla quota di ciascuna causa. Il numero ogni 1.000 mostra se una causa sta diminuendo. Le quote mostrano dove si trova il lavoro rimanente. Legga entrambi, perché correggere una causa fa sembrare più grandi le altre in quota, anche quando non è cambiato nulla.

Pylon lo ha visto nei propri dati: mentre le sue lacune di contenuto calavano, le segnalazioni di bug sono “salite dall’8,5% al 19% delle escalation” (Pylon, in inglese). Una quota in crescita non significa di per sé più bug: le altre fette si sono ridotte.

Un esempio di calcolo (illustrazione, numeri inventati per mostrare il calcolo)

Prenda un agente AI che gestisce 12.000 conversazioni a settimana. Nella settimana 1, 480 non superano un criterio critico: 40 ogni 1.000. Il team corregge in quattro settimane i principali gruppi legati a knowledge base e policy. Nella settimana 5 il volume è lo stesso e gli errori sono 290: 24,2 ogni 1.000.

Tre cose da leggere. Le tre cause legate ai contenuti sono scese da 260 a 95 errori, dal 54,2% al 32,8% della distribuzione. Le allucinazioni sono passate dal 7,3% all’11,4% degli errori mentre il loro numero scendeva da 35 a 33: chi guarda solo le quote concluderebbe che il modello è peggiorato. E gli errori degli strumenti si sono mossi appena (da 40 a 38), segno che l’engineering non ha ancora rilasciato la sua correzione.

Le metriche da tenere nella dashboard:

• Errori ogni 1.000 conversazioni AI, in totale e per causa.
• Quota per causa, per decidere dove va lo sforzo della settimana successiva.
• Ricorrenza: errori su un motivo di contatto e una causa segnati come corretti. Sopra zero dopo due settimane significa che la correzione non ha tenuto.
• Tempo di correzione per responsabile, dal ticket assegnato alla rivalutazione.
• Tasso di non classificati: errori che nessuno ha saputo collocare. Se supera una piccola quota, vanno rivisti la tassonomia o i criteri.

Quando questa tassonomia non fa per lei?

Una tassonomia a dieci cause non fa per lei, o non ancora, quando il suo agente AI risponde a qualche centinaio di domande al mese da un piccolo centro assistenza e non compie azioni. Allora bastano tre gruppi: contenuti (cause da 1 a 3), agente AI (4, 5, 8, 10) e tutto il resto. Passi all’elenco completo quando il lavoro comincia ad arrivare a responsabili fuori dall’assistenza.

Segnali che tre gruppi non bastano più: l’agente compie azioni in altri sistemi, ha più di un agente AI o di una piattaforma che risponde ai clienti, le policy cambiano più di una volta a trimestre, oppure due team discutono ogni settimana su chi debba occuparsi di un errore. Se lo stesso motivo di contatto continua a fallire dopo le correzioni, conduca un’analisi della causa radice più approfondita su quel gruppo invece di aggiungere categorie.

Il ruolo di Kaizo

Kaizo offre QA e supervisione della governance per i team di assistenza in cui persone e agenti AI si dividono il lavoro. Copre il lato delle prove nell’analisi degli errori: valutare le conversazioni, far emergere le cause radice e rivalutare dopo una correzione. Non scrive i suoi articoli né le sue policy.

AutoPilot valuta ogni conversazione risolta con la sua scheda di valutazione e, sul fronte del controllo qualità degli agenti AI, lei aggiunge i criteri su cui un agente AI sbaglia e collega la sua knowledge base, così la valutazione avviene rispetto ai suoi contenuti. Ogni punteggio rimanda alle prove nella trascrizione. Insights trasforma quei punteggi in cause radice (il processo che non funziona, l’attrito nel prodotto, la lacuna di competenze), e questo dà allo smistamento settimanale i gruppi e gli esempi da cui partire.

Lo veda sulle sue conversazioni. Prenoti una demo e porti un motivo di contatto che il suo team considera un problema di allucinazioni.

Come iniziare questa settimana

Inizi dalle peggiori conversazioni AI della settimana scorsa, non da un nuovo strumento. Aggiunga le dieci cause al suo modulo di revisione, classifichi un piccolo lotto con l’albero decisionale, nomini un responsabile per causa e corregga per primo il gruppo più grande legato ai contenuti.

1. Incolli la tabella delle dieci cause nel suo modulo di revisione come elenco di scelta obbligatorio su ogni criterio non superato.
2. Prenda le 30 peggiori conversazioni AI della settimana scorsa e applichi a ciascuna le dieci domande. Conti quante arrivano alla domanda 9.
3. Nomini un responsabile per causa, come persone, e concordi il formato della nota di smistamento.
4. Fissi uno slot ricorrente di 45 minuti per lo smistamento e avvii il registro con i gruppi di questa settimana.
5. Scelga il gruppo più grande legato ai contenuti e lo corregga per primo. Rivaluti quel motivo di contatto la settimana prossima. Il lato policy completo del ciclo è nella nostra guida sulla gestione delle policy per gli agenti AI.

Domande frequenti

Ogni risposta sbagliata di un agente AI è un’allucinazione?

No. Un’allucinazione è un contenuto generato dal modello che non trova riscontro nelle sue fonti o nella conversazione. Una risposta sbagliata copiata da un articolo superato, o un tentativo su un caso che nessuna policy copre, è un errore di contenuto. Il test è se esisteva una fonte corretta e approvata e l’agente se n’è discostato.

Basare un agente AI sui propri contenuti elimina le allucinazioni?

Il grounding sui propri contenuti riduce le risposte inventate, ma non le elimina, e aggiunge nuovi punti di errore. L’agente può recuperare l’articolo sbagliato, citarne uno superato o discostarsi comunque da quello giusto. Per questo il recupero dei contenuti e i contenuti superati hanno cause proprie nella tassonomia, separate dall’allucinazione.

Chi dovrebbe essere responsabile dell’analisi degli errori di un agente AI?

Di solito il QA lead è responsabile della classificazione e dello smistamento settimanale, perché la scheda di valutazione e le prove delle revisioni stanno al QA. Le correzioni spettano ai responsabili di ciascuna causa: knowledge base, policy, configurazione dell’AI, engineering, support operations e prodotto. Una sola persona responsabile della classificazione mantiene le etichette coerenti da una settimana all’altra.

Quante conversazioni AI fallite andrebbero classificate ogni settimana?

Classifichi gruppi, non ogni conversazione. Da tre a cinque conversazioni per gruppo, sui primi cinque motivi di contatto per numero di errori, sono da 15 a 25 letture a settimana e di solito coprono la maggior parte degli errori. Ne legga di più in un gruppo quando le conversazioni non concordano sulla causa.

Le richieste di funzionalità vanno contate come errori dell’agente AI?

Le conti, ma le riporti separate dagli errori propri dell’agente. Una richiesta di funzionalità delude il cliente, non è un errore dell’agente, e nessuna modifica ai contenuti o al prompt la risolve. Contarle mostra al prodotto quanto spesso i clienti le chiedono, ed evita che gonfino il tasso di errore dell’agente AI.