Intercettare le allucinazioni AI: 3 guardrails per team B2B

Come si presentano le allucinazioni AI nei workflow B2B

Un'allucinazione è quando il modello produce una risposta sicura ma sbagliata. Nel B2B emerge in tre forme classiche: (1) inventare un numero d'ordine inesistente per una richiesta support, (2) "citare" una data che non è realmente nel contratto quando lo riassume, (3) inventare una nuova categoria quando classifica fatture fuori dal set definito.

Tutte e tre condividono lo stesso pattern: senza ancoraggio reale, il modello riempie il vuoto. Il problema è che l'output sembra sicuro — anche se sbagliato. "L'AI sbaglia" non basta; serve sapere dove e perché. I tre guardrail qui sotto fanno questo.

Tre guardrail: fonte, regola, umano

1) Citazione della fonte: il modello restituisce ogni risposta con l'id o numero di riga del documento sorgente. Senza fonte, risponde "non so". Le allucinazioni calano del ~80%.

2) Pre-controllo a regole: validare l'output contro le regole di dominio prima che arrivi — il numero d'ordine è di 8 cifre? La categoria fattura è nella lista? Il formato della data è valido? Questi controlli Python economici intercettano la maggior parte.

3) Approvazione umana preventiva: le azioni ad alto rischio (rimborsi, firme contratti) sono proposte dall'AI ma approvate da un umano. L'AI gestisce ~95% da sola; il 5% di eccezioni viene instradato a voi per revisione.

I tre insieme: in audit indipendenti il tasso di allucinazione scende sotto il 2%.

Costruire un processo di valutazione prima del lancio

Non potete rilevare un tasso di allucinazione osservando a occhio gli output; serve un set di test. Costruite un golden set di 50-200 esempi reali con risposte corrette note, e assicuratevi che copra i casi limite — dati mancanti, query ambigue, richieste fuori ambito. Fate girare il modello su di esso prima di ogni modifica al prompt o al modello, non solo al lancio.

Monitorate due numeri separati: l'accuratezza (ha dato la risposta giusta) e il tasso di astensione (ha detto correttamente "non lo so" quando avrebbe dovuto). Un modello che non si astiene mai appare sicuro di sé ma è più rischioso; un modello che si astiene troppo spesso è fastidioso ma più sicuro. La soglia giusta dipende da quanto costa una risposta sbagliata rispetto a una rimandata.

Il test avversariale conta quanto il test sui casi normali — alimentate deliberatamente il modello con query progettate per innescare allucinazioni: domande su entità che non esistono, richieste che mescolano due record insieme, prompt che gli chiedono di estrapolare oltre il documento di origine. Se non riesce a fallire con eleganza in un test controllato, non fallirà con eleganza nemmeno in produzione.

Trattate questo come una pipeline viva, non come un cancello una tantum. Ogni volta che modificate il prompt, cambiate modello o aggiungete una nuova fonte documentale, rieseguite il set di valutazione e confrontate i nuovi numeri di accuratezza e astensione con la vostra baseline prima di distribuire. È la stessa disciplina del test di regressione nel software tradizionale — solo che qui si testa il giudizio anziché la logica.

Quali compiti comportano il maggior rischio di allucinazione

Non tutti i compiti AI comportano lo stesso rischio, quindi neppure il vostro budget per i guardrail dovrebbe essere distribuito in modo uniforme. La generazione aperta — redigere un'email per un cliente, riassumere una riunione, scrivere testi di marketing — lascia spazio alla creatività, ma proprio quello spazio è dove si nasconde l'allucinazione: statistiche inventate, citazioni fittizie, promesse che l'azienda non ha mai fatto. Questa è la categoria a più alto rischio, perché non esiste un output "corretto" fisso da verificare, solo una gamma di risultati accettabili.

L'estrazione numerica e finanziaria segue da vicino. Estrarre un totale da una fattura, calcolare uno sconto, estrarre un codice fiscale — qui gli errori sono silenziosi (il numero sembra plausibile) e costosi (alimenta direttamente movimenti di denaro). Le affermazioni legali e affini all'ambito medico — obblighi contrattuali, dichiarazioni di conformità, indicazioni su dosaggi o sicurezza — appartengono alla stessa fascia ad alto rischio: sbagliare una volta e il danno risultante non è imbarazzo, è responsabilità legale.

All'altro estremo, l'estrazione strutturata rispetto a uno schema fisso — analizzare questo curriculum in nome/email/competenze, classificare questo ticket in una delle 12 categorie, taggare questa transazione con un codice commerciante — è relativamente a basso rischio. Il modello ha meno spazio per inventare perché lo spazio di output è vincolato e facile da validare meccanicamente: potete verificare che la categoria esista, che l'email contenga una chiocciola, che il valore sia una delle 12 opzioni. La classificazione in un piccolo insieme chiuso si comporta allo stesso modo — anche quando il modello sbaglia, sbaglia entro i confini che avete definito, il che è una modalità di fallimento fondamentalmente più economica.

Usate questo gradiente per decidere dove investire lo sforzo sui guardrail. I compiti a basso rischio e schema chiuso possono spesso funzionare con una validazione leggera e controlli a campione. I compiti ad alto rischio, aperti o numerici/legali meritano l'intero impianto della sezione precedente — citazione delle fonti, controlli di regole e un umano nel ciclo — prima di lasciare che l'automazione tocchi un cliente o un registro contabile.