Introduzione
La maggior parte delle aziende che sperimentano l’IA per l’assistenza clienti si scontra con lo stesso ostacolo. Il sistema funziona bene per settimane. Poi fornisce a un cliente una risposta sicura ma completamente errata. Magari riguardo ai tempi per richiedere un rimborso. Magari riguardo a una politica modificata nell’ultimo trimestre. Qualcuno ai vertici se ne accorge e l’implementazione, che avrebbe dovuto coprire la maggior parte della coda, si blocca silenziosamente a una frazione di essa.
I dati del settore confermano quanto sia comune questo schema. Il “2025 World Quality Report” di OpenText, Capgemini e Sogeti ha rilevato che le preoccupazioni relative all’affidabilità e alle “allucinazioni” rappresentavano il principale ostacolo all’adozione dell’IA per il 60% delle organizzazioni intervistate. Una ricerca separata condotta da Gong ha rilevato che il 58% delle aziende aveva bloccato i progetti di IA e che quasi la metà degli investimenti pianificati in questo ambito era stata frenata da preoccupazioni relative alla fiducia piuttosto che al budget. Gli strumenti sono all’altezza. È la fiducia in essi a rimanere indietro.
La matematica dietro una risposta errata
Il lavoro di assistenza è asimmetrico, in quanto penalizza l’accuratezza media come parametro di valutazione. Una risposta corretta fa risparmiare qualche minuto. Una risposta errata può approvare un rimborso che non avrebbe mai dovuto essere concesso, inventare una politica che non è mai esistita o assumere un impegno che nessuno ha autorizzato. Quando lo svantaggio di un singolo errore supera il vantaggio di cento risposte corrette, ottimizzare per il caso medio è un obiettivo del tutto sbagliato.
C’è anche un costo meno evidente. Un responsabile dell’assistenza che si accorge che l’IA ha sbagliato una volta, da quel momento in poi inizia a ricontrollare tutto, il che annulla gran parte del tempo che avrebbe dovuto risparmiare. La fiducia non viene valutata conversazione per conversazione. Si costruisce o crolla, e una volta che crolla i team smettono di fidarsi del sistema anche quando ha ragione la maggior parte delle volte.
Le allucinazioni non scompaiono, vanno gestite
Anche i modelli linguistici più avanzati generano informazioni errate nelle giuste condizioni, e le cifre reali sono più alte di quanto la maggior parte delle persone supponga. Per quanto riguarda la sintesi basata su dati concreti, che è essenzialmente lo stesso compito di rispondere attingendo dai propri documenti di assistenza, la classifica delle allucinazioni di Vectara colloca i modelli migliori intorno al 3% e mostra che modelli di punta ben noti si attestano tra il 6% e il 15%. Alcuni modelli che fanno ampio ricorso al ragionamento superano il 20% in quello stesso compito, poiché un ragionamento più approfondito offre loro maggiore spazio per introdurre affermazioni che il testo di origine non ha mai fatto. Se si sottopone un modello a domande aperte senza alcun punto di riferimento, i numeri peggiorano notevolmente. I ricercatori di Stanford hanno scoperto che i modelli leader producevano allucinazioni sulla grande maggioranza di specifiche domande legali quando non veniva fornito alcun documento di origine.
Nulla di tutto ciò significa che un modello specifico sia scadente. Significa che nessun modello, se utilizzato da solo, è abbastanza affidabile da poter essere presentato a clienti paganti senza un sistema di supervisione.
Intelligenza e controllo tirano in direzioni opposte
C’è una ragione strutturale per cui un singolo modello non può risolvere questo problema da solo. Man mano che un sistema migliora nella gestione di casi ambigui o sconosciuti, diventa anche più difficile da prevedere completamente, perché lo stesso ragionamento che gli permette di gestire un caso per cui nessuno ha scritto uno script è lo stesso ragionamento che occasionalmente lo porta dove non dovrebbe andare. Un modello più capace non è automaticamente più sicuro. Questo compromesso spiega perché l’affidabilità debba essere progettata come un livello che circonda il modello, piuttosto che essere pretesa dal modello stesso.
Aissist affronta questo aspetto con quattro tecniche a livelli anziché una sola. Il prompt engineering definisce le regole di base che ogni attività deve seguire, aspetto che assume maggiore importanza in un sistema agentico in cui una singola richiesta del cliente può espandersi in più di una dozzina di attività secondarie che devono tutte rispettare gli stessi limiti di sicurezza. Una fase di "booster" esegue le decisioni incerte più di una volta e mantiene la risposta su cui la maggior parte degli agenti è d’accordo, a costo di una maggiore potenza di calcolo. Un ciclo di auto-ispezione fa sì che il sistema riveda il proprio output, oppure lo passi a un secondo modello con un ruolo diverso, prima che qualsiasi cosa raggiunga il cliente. E un livello di governance sovrapposto si trova al di sopra di tutto ciò, verificando se un output o un’azione sia conforme alla politica prima che venga emesso, funzionando meno come un filtro e più come un supervisore dell’intero sistema.
È grazie a questa combinazione che la piattaforma mantiene il proprio tasso di errore dell’IA al di sotto dell’1%, un dato degno di nota soprattutto perché pochissimi fornitori in questo settore lo rendono pubblico.
Valutare quando non rispondere
Il comportamento più prezioso in un agente dell’assistenza non è rispondere correttamente a più domande. È riconoscere a quali non dovrebbe cercare di rispondere da solo. Un sistema che inoltra tempestivamente una controversa disputa di fatturazione, allegando il contesto completo, causa molti meno danni rispetto a uno che va avanti e tira a indovinare. Questo è anche ciò che distingue un agente che descrive una soluzione da uno che la applica effettivamente, recuperando l’ordine, apportando la modifica e confermandola al cliente.
L’affidabilità va mantenuta, non solo costruita
Un sistema che è accurato il giorno del lancio non rimarrà tale senza un monitoraggio costante. I prodotti cambiano, le politiche vengono aggiornate e le domande poste dai clienti si evolvono di conseguenza. Una misurazione continua rileva tale evoluzione sotto forma di dati anziché come un’ondata di reclami, e un ciclo disciplinato di valutazione, test e implementazione continua a colmare le lacune individuate, con un operatore umano che approva comunque prima che qualsiasi modifica venga effettivamente applicata.
Cosa verificare effettivamente prima di fidarsi di un fornitore
Qualsiasi fornitore che affermi che la propria IA non commette mai errori dovrebbe essere considerato con sospetto, perché di solito significa che nessuno sta misurando con sufficiente attenzione per sapere se sia vero o meno. Quelli che vale la pena prendere sul serio pubblicano un tasso di errore, spiegano esattamente come individuano gli errori prima che i clienti se ne accorgano e sono trasparenti su quando il sistema passa il testimone a una persona invece di tirare a indovinare. Si tratta di un approccio molto diverso dal semplice «fidatevi dell’IA», ed è quello che regge davvero quando il sistema deve gestire un volume reale di richieste di assistenza.
