Come verificare l'output di un agente AI

Perché la fiducia con cui un modello generativo scrive una frase non è un segnale della sua correttezza. Lo mostra un test controllato riportato nell'AI Index Report 2026 di Stanford HAI: quando una stessa affermazione falsa viene presentata come qualcosa che crede una terza persona, i modelli la riconoscono bene come falsa. Quando la stessa identica affermazione falsa viene presentata come qualcosa che crede l'utente che sta parlando con il modello, l'accuratezza crolla: uno dei modelli testati passa dal 98,2% al 64,4% di risposte corrette, un altro dal 90% al 14,4%, con lo stesso identico fatto da valutare.

Il punto non è che questi modelli siano scadenti. È che un modello ottimizzato per essere utile e collaborativo tende ad assecondare chi gli parla più di quanto tenda a contraddirlo, e questa tendenza non è visibile leggendo il tono della risposta: il testo scorretto è scritto con la stessa sicurezza di quello corretto. Giudicare un output dal fatto che "suona bene" verifica lo stile, non il contenuto.

Molto, ed è la ragione per cui non esiste un numero unico da citare come "tasso di errore dell'AI". Lo stesso report di Stanford misura, su ventisei modelli tra i più usati, tassi di allucinazione che vanno dal 22% al 94% a seconda del modello e del compito. Un intervallo di questa ampiezza dice una cosa sola con chiarezza: il rischio dipende dal compito specifico, non da una proprietà generale del modello, e va misurato caso per caso, non assunto da una media letta altrove.

Questo ha una conseguenza pratica diretta. Un compito ad alto rischio (un dato che finisce in un contratto, un'affermazione su un competitor, un numero che entra in un report per un cliente) va verificato indipendentemente da quanto il modello sia bravo in media. La media non protegge il singolo caso.

Dipende dal tipo di output, e va deciso prima, non durante. Il codice ha un vantaggio strutturale: può avere test automatici che passano o falliscono senza ambiguità, e questo lo rende il tipo di lavoro più facile da delegare con sicurezza. La maggior parte del resto del lavoro non ha questa comodità, ma può comunque essere verificata con lo strumento giusto: un documento tecnico può essere controllato contro una rubrica scritta e uno stile guida dichiarato, un dato numerico può essere incrociato con una seconda fonte indipendente, un'affermazione su un fatto esterno può essere tracciata fino al documento originale da cui viene.

Il principio che tiene insieme questi metodi diversi è lo stesso: più riesci a chiudere il ciclo di verifica con un controllo automatico e oggettivo, più l'agente lavorerà in modo affidabile nel tempo. I compiti dove il successo è sfumato e difficile da misurare restano i più rischiosi da affidare a un agente, non perché l'agente sia peggiore su quei compiti, ma perché nessuno saprebbe dire con certezza se ha avuto successo.

È un modo semplice di strutturare la verifica quando non esiste un test automatico pronto: un agente esegue il compito, un secondo agente, con istruzioni diverse e nessun coinvolgimento nella produzione del primo output, ha l'unico compito di controllarlo. Il secondo agente non deve essere più intelligente del primo. Deve avere un lavoro più semplice e più mirato: non produrre, solo giudicare, con criteri specifici scritti in anticipo.

Il vantaggio pratico è che separare chi fa da chi controlla riduce un errore sistematico comune: un agente che rilegge il proprio lavoro tende a confermarlo, perché la stessa logica che ha prodotto un errore tende a non vederlo in fase di rilettura. Un controllore indipendente, umano o agente, con un compito diverso e criteri propri, può ridurre quel punto cieco senza eliminarlo.

Non tutti gli output hanno bisogno dello stesso livello di controllo. La tabella indica il metodo minimo ragionevole, non il massimo possibile.

La persona che fissa il livello di qualità accettabile, prima che il lavoro cominci, non dopo aver visto il primo output. È la stessa logica di una metrica di successo scritta prima di un progetto: una checklist scritta dopo aver già visto il risultato tende ad adattarsi al risultato invece di misurarlo davvero, perché è difficile scrivere criteri severi su un lavoro che si ha già davanti e che, in parte, si vorrebbe considerare buono.

Quando i criteri sono scritti prima e restano fissi, la qualità resta stabile nel tempo e non scivola lentamente verso il basso mano a mano che aumenta la fiducia nell'agente. È il meccanismo che rende sicuro allargare l'autonomia con l'esperienza: non perché a un certo punto ci si fida senza motivo, ma perché il criterio con cui si giudica il lavoro non è mai cambiato.

Gli errori si accumulano invece di fermarsi al primo. Un agente che lavora su più passaggi costruisce ogni fase sopra il risultato della precedente: se un errore nella prima fase non viene intercettato, le fasi successive lo useranno come se fosse corretto, e il risultato finale apparirà coerente e ben argomentato, non perché sia giusto, ma perché è stato elaborato più a lungo sopra una premessa sbagliata.

È la ragione per cui la verifica non è un passaggio finale da aggiungere se rimane tempo. È un controllo che deve intervenire il prima possibile nella catena, perché il costo di un errore non corretto cresce a ogni fase successiva che lo eredita.

C'è anche un costo meno visibile, che si paga anche quando l'errore viene poi trovato: la fiducia. Un team che scopre un errore non intercettato in un output già consegnato a un cliente non torna al livello di fiducia precedente semplicemente correggendolo. Da quel momento rilegge tutto il resto con più sospetto, il che rallenta esattamente il lavoro che la delega doveva velocizzare. La verifica sistematica non serve solo a evitare il singolo errore: serve a evitare che un singolo errore mal gestito riporti indietro l'intero processo di delega.