Note operative Metodo

Allucinazioni: quanto potete fidarvi di un modello, e come si mette in sicurezza

3 min di lettura

Sala di lettura di una biblioteca storica
La risposta vera esiste: va ancorata alle fonti, non alla plausibilità.

Un modello linguistico non «sa» le cose: genera il testo più plausibile dato il contesto. Quasi sempre plausibile e vero coincidono. Quando non coincidono, il modello produce un’allucinazione: un’informazione inventata, dichiarata con la stessa sicurezza di quelle corrette. Non è un difetto di gioventù che i modelli si lasceranno alle spalle: è una proprietà del meccanismo. E per un’azienda è un rischio operativo e legale, non estetico.

Il rischio è già giurisprudenza

Due casi bastano a inquadrare il problema. Un tribunale canadese ha condannato Air Canada a onorare uno sconto che il suo chatbot aveva inventato: la compagnia aveva sostenuto che il chatbot fosse «un’entità separata responsabile delle proprie azioni», e il giudice ha risposto che no, quello che il vostro sistema dice ai clienti impegna voi. Negli Stati Uniti (e ormai anche in Europa) una serie di avvocati è stata sanzionata per aver depositato atti con sentenze inesistenti, generate dal modello e mai verificate. La linea giurisprudenziale è chiara: l’allucinazione non è una scusante — è vostra.

Perché “il modello migliorerà” non è una strategia

I modelli di frontiera allucinano meno dei loro predecessori, è vero. Ma «meno» su milioni di interazioni significa comunque «ogni giorno», e paradossalmente i modelli migliori producono errori più credibili, che superano la lettura veloce di un operatore distratto. La sicurezza non può dipendere dalla speranza che l’errore non capiti: deve dipendere dall’architettura che lo contiene quando capita.

Le quattro difese che funzionano davvero

  1. Ancorare le risposte ai vostri dati (grounding). Il modello non deve rispondere «a memoria»: deve leggere i documenti, i database, i sistemi aziendali — e rispondere solo da quelli. Se l’informazione non c’è, la risposta giusta è «non lo so», non un’invenzione fluente. Tecnicamente si fa collegando il modello a un modello operativo dei vostri dati: l’ontologia dice cosa esiste, il modello linguistico lo racconta.
  2. Citazioni verificabili, sempre. Ogni affermazione rilevante deve puntare alla fonte: il paragrafo del contratto, la riga del gestionale, il lotto di produzione. Una risposta senza fonte è un’opinione del modello; una risposta con fonte è un fatto controllabile in dieci secondi.
  3. Vincolare le azioni, non solo le parole. Quando l’AI non scrive ma fa — apre un ticket, modifica un ordine, ferma una linea — l’allucinazione diventa un atto. Qui la difesa è strutturale: l’agente può eseguire solo azioni tipizzate su oggetti che esistono nell’ontologia, e le azioni critiche richiedono approvazione umana. Un agente non può inventarsi un cliente se il sistema gli permette di agire solo su clienti reali.
  4. Misurare, per caso d’uso. «Quanto allucina?» non ha risposta in assoluto: ha risposta sul vostro compito, con i vostri documenti. Prima di andare in produzione si costruisce un set di prova con risposte note e si misura. Dopo, si continua a campionare. Ciò che non si misura, si scopre in tribunale.

La regola pratica

Distinguere sempre due usi. AI che assiste una persona esperta (riassume, cerca, propone bozze): rischio gestibile, la persona è il controllo. AI che risponde o agisce verso l’esterno senza revisione: rischio pieno, servono tutte e quattro le difese — o meglio non farlo affatto finché non ci sono. La differenza tra i due casi è esattamente ciò che un fornitore serio vi aiuta a tracciare prima di vendervi qualsiasi cosa.

Avete un caso d’uso dove l’errore costa caro? Mezz’ora con un nostro esperto per capire quali difese servono davvero.

Fonti