Allucinazioni dell'AI: cosa sono e come gestirle in azienda

A partire da un noto caso statunitense del 2023, diversi avvocati in vari paesi hanno depositato atti con citazioni generate dall'AI, complete di numero e anno di sentenza, che non corrispondevano ad alcuna causa reale. Il modello non aveva copiato male un dato: lo aveva inventato, con lo stesso tono sicuro con cui avrebbe citato una sentenza vera. È l'esempio più citato di un problema che chi lavora con questi sistemi conosce bene e che molte aziende sottostimano quando passano dalla demo alla produzione: le allucinazioni.

Conoscerle e sapere come gestirle non è un dettaglio tecnico: è una condizione per usare l'AI in modo responsabile.

Cosa sono, esattamente

Il termine indica un comportamento preciso dei modelli linguistici: il sistema genera informazioni plausibili e formulate con sicurezza, ma false o non corrispondenti alla realtà. Non è un difetto che si corregge con un aggiornamento, è una conseguenza strutturale di come funzionano questi modelli, che producono testo plausibile, non cercano la verità: il modello non sa se ciò che dice è vero, genera la sequenza di parole statisticamente più probabile nel contesto.

Il problema non è solo che il modello sbagli, ma che sbaglia con lo stesso tono con cui ha ragione. Non c'è un segnale visibile di incertezza né un "forse" automatico: un'allucinazione è indistinguibile da una risposta corretta, a meno di conoscere già la risposta giusta.

Dove il rischio si sente davvero, in azienda

Oltre al caso delle sentenze inesistenti, gli scenari più comuni in un contesto aziendale sono altri tre. Un dipendente chiede a un assistente sui documenti interni quanti giorni di ferie gli spettano in una situazione particolare, e il sistema risponde con sicurezza una cifra sbagliata perché non ha trovato il documento giusto e ha "completato" la risposta. Un sistema di analisi dei contratti omette o interpreta male una clausola rilevante, e il rischio non è solo l'errore, ma la falsa sicurezza che spinge a non verificare. Un agente compila un modulo con dati che non ha trovato nel contesto disponibile, e semplicemente li inventa. In tutti e tre i casi il danno non nasce dall'errore in sé, ma dal fatto che nessuno lo abbia notato in tempo.

Perché succede: quattro cause

Le cause, in ordine di frequenza, sono dati di addestramento lacunosi o contraddittori, da cui il modello ha imparato schemi incoerenti senza segnalare l'incertezza; domande fuori dal suo campo, davanti alle quali il modello tende a completare comunque la risposta invece di dire "non lo so"; contesto insufficiente, per cui se le informazioni per rispondere non sono disponibili il modello riempie il vuoto con conoscenze generali che possono essere sbagliate; e istruzioni ambigue o incomplete, che aumentano la probabilità di risposte inventate.

Il livello di rischio decide il livello di controllo

Non tutti i compiti hanno lo stesso profilo di rischio, e questo deve guidare la progettazione fin dall'inizio. Nei compiti a rischio basso, come riassumere documenti interni, classificare email o preparare bozze da rivedere, un'allucinazione è un fastidio, non un danno. Nei compiti a rischio medio, come rispondere su regole HR, assistere i clienti sulle condizioni di vendita o analizzare contratti, servono un sistema RAG solido e uscite di sicurezza esplicite. Nei compiti a rischio alto, con effetti legali, finanziari o sulla sicurezza delle persone, servono supervisione umana obbligatoria, registri completi e collaudi sistematici prima del rilascio. La regola pratica è semplice: più alto è il costo di un errore non rilevato, più forte deve essere il controllo umano.

Le misure che funzionano, e come verificarle prima del rilascio

La prima misura è far rispondere il modello sempre sulla base di documenti aziendali reali, tramite la RAG, e non sulla sua memoria generale: un sistema ben costruito riduce drasticamente le invenzioni sulle informazioni aziendali, perché le informazioni necessarie sono nel contesto. Il sistema deve inoltre indicare sempre da quale documento viene la risposta, e se non può citare una fonte non dovrebbe rispondere. Nei processi ad alto impatto una persona deve convalidare prima che la decisione produca effetti: la supervisione umana non è un'inefficienza, è un requisito. Il sistema deve anche saper dire quando non sa rispondere: "non ho informazioni sufficienti" è una risposta utile, un'invenzione plausibile è pericolosa, ed è una scelta di progettazione deliberata. Dire esplicitamente al modello "se non trovi l'informazione nei documenti, dichiara che non puoi rispondere" riduce molto le allucinazioni, e i modelli attuali seguono bene questo tipo di indicazioni. Infine, per i compiti che richiedono precisione conviene abbassare la "temperatura", il parametro che regola quanto il modello varia le risposte, riducendo le variazioni indesiderate.

Nessuna di queste misure va presa sulla parola: un sistema non si giudica dalla demo, ma da una prova sistematica. Prima di metterlo in produzione conviene preparare un insieme di domande di prova, qualche decina o qualche centinaio, con le risposte corrette già note, domande semplici, domande difficili, domande a cui la risposta non è nei documenti, e misurare quante volte il sistema risponde bene, quante sbaglia e, soprattutto, quante volte ammette di non sapere quando dovrebbe. La stessa prova va ripetuta ogni volta che cambiano il modello, le istruzioni o i documenti, perché un miglioramento su un fronte può peggiorare un altro, e in produzione vale la pena raccogliere le segnalazioni degli utenti sulle risposte sbagliate: sono il materiale più prezioso per migliorare il sistema nel tempo.

Un sistema affidabile, quindi, non è un modello particolarmente "preciso", ma un'architettura che prevede risposte ancorate a dati verificabili, uscite di sicurezza esplicite, la registrazione di ogni domanda e risposta per analizzare gli errori, collaudi sui casi limite prima del rilascio, supervisione proporzionata al rischio e dati di riferimento sempre aggiornati. Le allucinazioni non si eliminano, si gestiscono, e il modo in cui vengono gestite è una delle differenze principali tra i sistemi che creano valore nel tempo e quelli che creano problemi. Se vuoi rendere più affidabile un tuo sistema, scrivici.