Allucinazioni LLM nel 2026: il problema non è la conoscenza, è l'astensione

In sintesi

• I modelli di frontiera (Opus 4.7, GPT-5.5, Gemini 3.1 Pro) non allucinano meno perché sanno di più: allucinano meno perché imparano a tacere
• Su AA-Omniscience, Opus 4.7 scora 26 e GPT-5.5 scora negativo — il selettore principale non è l'accuracy ma la calibrazione
• GPT-5.5 ha un tasso di allucinazione dell'86% su domande di dominio dove avrebbe dovuto astenersi: scelta progettuale, non bug
• Su documenti lunghi (32.000 token), anche i migliori modelli superano il 10% di hallucination anche con la fonte in pasto — il RAG da solo non basta
• Per applicazioni in dominio regolato la risposta corretta non è "usa il modello più intelligente", è "usa il modello più calibrato + layer di verifica esplicito"

I benchmark pubblicati nelle ultime settimane su modelli di frontiera, Claude Opus 4.7, GPT-5.5, Gemini 3.1 Pro, raccontano una storia che ribalta la narrativa dominante. Il problema delle allucinazioni non si sta risolvendo aumentando la conoscenza del modello. Si sta risolvendo, lentamente, insegnando al modello a dire "non lo so". È una distinzione che cambia profondamente cosa significa portare un sistema LLM in produzione in un contesto regolato.

In questo articolo metto in fila i numeri freschi di maggio 2026 e provo a dire cosa significano operativamente per chi progetta applicazioni AI dove l'errore non può essere il prezzo da pagare. Documentazione tecnica regolata, dispositivi medici, specifiche di prodotto in revisione continua, compliance fiscale, customer service che cita claim sanitari. Tutti casi dove l'allucinazione non è un fastidio, è un rischio normativo.

Il dato che cambia la conversazione

Su AA-Omniscience, il benchmark di Artificial Analysis che misura conoscenza e calibrazione su 6.000 domande in sei domini (Business, Humanities, Health, Law, Software Engineering, Science), il punteggio si muove tra -100 e +100, e zero rappresenta il punto in cui un modello dà tante risposte giuste quante sbagliate. Claude Opus 4.7, uscito a fine aprile 2026, scora 26. Gemini 3.1 Pro è in testa con 33. GPT-5.5 sta sotto.

Tradotto: solo una manciata di modelli, a oggi, su domande di dominio specifico, dà più valore che danno. La maggioranza dei modelli sul mercato, se misurati con un criterio che penalizza l'allucinazione e premia il "non lo so", scora intorno allo zero o sotto.

Il salto di Opus 4.7 rispetto al suo predecessore Opus 4.6 è interamente attribuito alla calibrazione: il modello su 100 domande prova a rispondere su 36, e sulle altre 64 dichiara di non avere informazioni sufficienti. Non è diventato più intelligente, è diventato più consapevole dei propri limiti. Il tasso di allucinazione sulle risposte effettivamente date è sceso dal 61% al 36%.

E qui arriva il dato che lascia perplessi quando lo si vede per la prima volta: GPT-5.5, lo stato dell'arte di OpenAI a maggio 2026, ha un tasso di allucinazione misurato all'86%. Non vuol dire che GPT-5.5 sbaglia 86 volte su 100 in uso normale: vuol dire che, costretto a rispondere su domande di dominio dove avrebbe dovuto astenersi, lo fa quasi sempre. Il modello "tenta" sempre. È un tratto di personalità progettuale, non un bug.

Il secondo dato che pochi citano

Vectara mantiene un secondo benchmark, sulla "summarization faithfulness": dato un documento sotto al naso del modello, il riassunto resta dentro al documento o aggiunge fatti non supportati? Questo è il proxy diretto di cosa succede in un sistema RAG enterprise: il modello ha già la fonte, deve solo restare aggrappato a quella.

Nella versione vecchia del benchmark, con documenti corti, i top model scendevano sotto al 5% di hallucination. Sembrava una vittoria. A fine 2025 Vectara ha rifatto il benchmark con documenti lunghi fino a 32.000 token, 7.700 articoli su legge, medicina, finanza, tecnologia. Tipo i documenti che si trovano davvero in uno studio legale, in un ospedale, in un'azienda regolamentata.

Su quel benchmark più duro, anche GPT-5, Claude Sonnet 4.5 e Grok-4 hanno superato il 10% di hallucination. Cioè anche dando al modello esattamente la fonte da cui rispondere, su documenti lunghi e complessi, una risposta su dieci o peggio aggiunge fatti che nel documento non ci sono.

Per chi lavora su MDR, IVDR, certificazioni di sicurezza, manuali tecnici, normativa fiscale, questo numero è la realtà operativa. Non i numeri da benchmark corti che escono nelle slide dei vendor.

Perché Opus 4.7 è interessante anche se non è la scelta giusta per tutti

L'aspetto più interessante di Opus 4.7 non è il numero in sé. È che Anthropic ha esplicitamente trade-offato: meno risposte, ma più affidabili. Su un benchmark che misura solo accuratezza pura, questa strategia perde. Su un benchmark che premia anche l'astensione, vince.

Per chi sviluppa applicazioni in dominio regolato, questo è esattamente il comportamento desiderato. Un sistema che su 100 richieste risponde a 36 con alta affidabilità e dice "non lo so" sulle altre 64 è infinitamente più utile, in un'azienda manifatturiera che gestisce specifiche tecniche, di un sistema che risponde a tutte e 100 sbagliando una su tre senza dichiararlo.

GPT-5.5 ha una filosofia opposta: massimizza il tasso di risposta, accettando un tasso di errore alto. È una scelta ragionevole per casi d'uso creativi, brainstorming, conversazione generalista. È disastrosa in contesti dove la risposta diventa una scheda tecnica firmata, una procedura di sicurezza, una consulenza che il cliente userà come riferimento.

Non c'è un "modello migliore" assoluto. C'è un modello giusto per il caso d'uso. E il selettore principale, in contesti regolati, è quanto bene il modello sa tacere.

Le tre cose che cambiano operativamente

Questi numeri non sono una notizia accademica. Cambiano tre cose concrete in come si progetta oggi un'applicazione LLM enterprise.

La prima: la scelta del modello non si fa più solo guardando l'MMLU o l'arena Elo. Va guardato il profilo di calibrazione. Su un caso d'uso regolato, un modello che scora 0% hallucination perché si astiene su tutto vale di più di un modello con accuracy alta che però sbaglia in silenzio. Le pipeline serie del 2026 stanno iniziando a mettere modelli diversi su task diversi: un modello "cauto" sui contenuti regolati, un modello "creativo" sui contenuti di brainstorming.

La seconda: il prompt engineering oggi include una componente nuova, l'esplicita istruzione a calibrarsi. "Se non sei sicuro, dichiaralo. Se la fonte non lo dice esplicitamente, non inferirlo. Se la domanda richiede informazioni che non hai, rispondi che non hai abbastanza informazioni". Sembrano ovvietà, ma fino al 2024 i modelli ignoravano queste istruzioni il più delle volte. Da Opus 4.7 e Gemini 3.1 Pro in poi, le seguono in modo affidabile.

La terza: il RAG da solo non basta più. Il dato Vectara sul benchmark lungo dice che anche con la fonte in pasto al modello, il 10-20% delle risposte aggiunge fatti non supportati. Le architetture enterprise serie oggi aggiungono un layer di verifica esplicito: un secondo modello che, leggendo la risposta generata e la fonte, dichiara se ogni affermazione della risposta è effettivamente nel documento. Quando non lo è, la risposta viene bloccata o flaggata. È un costo computazionale doppio, ma in domini regolati è il prezzo dell'auditabilità.

Tabella: tre profili di modello a maggio 2026

Caratteristica	Modelli "tentatori" (es. GPT-5.5)	Modelli "calibrati" (es. Opus 4.7)	Modelli "intermedi" (es. Gemini 3.1 Pro)
Tasso di risposta	Alto, prova quasi sempre	Più basso, si astiene volentieri	Alto, ma con confidence dichiarata
Hallucination su domande di dominio	Molto alto, sopra l'80% sulle astenibili	Moderato, sotto il 40%	Intermedio, intorno al 50%
Caso d'uso ideale	Brainstorming, scrittura creativa, conversazione	Documentazione regolata, RAG enterprise, compliance	Search-augmented Q&A, ricerca interna
Rischio in dominio regolato	Inaccettabile	Gestibile con citazione fonte	Da valutare caso per caso

Questa tabella, a cui sono arrivato da letture incrociate dei benchmark, sarà obsoleta entro 6 mesi. La sostanza no. La distinzione tra modelli che tentano e modelli che si astengono resterà il selettore principale per applicazioni serie.

L'AI Act, dove siamo a maggio 2026

Il 7 maggio 2026, sei giorni fa, Consiglio UE e Parlamento Europeo hanno raggiunto un accordo politico provvisorio sul cosiddetto Digital Omnibus, che rinvia diverse scadenze chiave dell'AI Act. Per i sistemi AI ad alto rischio standalone gli obblighi scattano il 2 dicembre 2027, non più il 2 agosto 2026. Per i sistemi AI incorporati in prodotti regolati, tipicamente dispositivi medici sotto MDR, gli obblighi si applicano dal 2 agosto 2028.

L'accordo deve ancora essere formalmente adottato, ma il segnale è chiaro: la conformità è posticipata di 12-24 mesi, non eliminata. Per chi produce dispositivi medici, attrezzature industriali con certificazioni, prodotti regolati, il messaggio operativo non cambia. C'è tempo per fare le cose bene. Non per non farle.

Il rinvio cambia però una cosa importante: progettare oggi una pipeline LLM con auditabilità, tracciabilità, calibrazione esplicita, costa il 20-30% in più rispetto a una pipeline "veloce" senza queste caratteristiche. Tra 24 mesi, rifare una pipeline che è andata in produzione senza questi attributi costerà 3-5x. La finestra di vantaggio per chi parte oggi col piede giusto è proprio adesso.

Tre raccomandazioni operative

Tre raccomandazioni operative, distillate da queste osservazioni.

Non scegliere il modello su MMLU o su demo. Per ogni caso d'uso regolato, costruisci un set di 30-50 domande con risposte note fornite dall'esperto interno, e testa due o tre modelli sul tuo set reale, non sui benchmark generici. Spesso un modello più piccolo ben calibrato batte un modello più grande "tentatore" sul caso d'uso specifico.

Pretendi citazione della fonte come parte del design, non come opzione. Ogni risposta che il sistema dà deve essere ricollegabile al documento e al paragrafo da cui viene. Senza questa traccia, nessun audit normativo è possibile e l'azienda non saprà mai con certezza perché il sistema ha risposto in un certo modo.

Costruisci un layer di verifica esplicito. Anche un secondo passaggio LLM, sulle risposte generate, che controlli se ogni affermazione è effettivamente supportata dalla fonte, riduce l'errore residuo di un altro fattore 2-3x. Costa due chiamate al modello invece di una. Per applicazioni regolate, è investimento ben speso.

In Rayo costruiamo agenti AI su misura proprio con queste tre caratteristiche di default. Non perché siamo bravi, ma perché abbiamo capito da progetti reali che senza queste tre cose il sistema non resta in produzione più di sei mesi prima che qualcuno trovi un errore importante.

FAQ

Se Opus 4.7 si astiene su 64 domande su 100, non è un peggioramento dell'esperienza utente? Dipende dal contesto. In una conversazione generalista, sì, può sembrare meno utile. In un sistema che assiste un operatore di produzione che chiede una tolleranza tecnica, un "non lo so, chiedi al responsabile qualità" è la risposta giusta. Il design del sistema deve canalizzare gli "non lo so" verso il punto di escalation umano corretto, non lasciarli sull'utente. Quando questa canalizzazione è ben fatta, l'astensione diventa una feature, non un limite.

Posso usare GPT-5.5 in dominio regolato se ci metto sopra un buon RAG? Tecnicamente puoi, ma il dato Vectara dice che anche con la fonte in pasto al modello, GPT-5.5 e simili tendono ad aggiungere informazioni non supportate. Su documenti complessi e lunghi (32k token, tipici della normativa) il tasso supera il 10%. In dominio regolato questo significa una risposta su dieci che, in audit, non è giustificabile dalla fonte. Se il caso d'uso accetta questo livello di errore (es. supporto interno di prima linea con escalation facile a umano), può funzionare. Se non lo accetta (es. risposta che diventa parte di una scheda tecnica firmata), no.

Quanto costa progettare oggi un sistema LLM "audit-ready" rispetto a uno standard? Indicativamente il 20-30% in più, sia in tempo di sviluppo che in costi di runtime (per il layer di verifica e il logging strutturato). Su un progetto di 10.000 euro standard si parla di 12-13.000 euro. Su un progetto di 50.000 euro si parla di 60-65.000 euro. Per un'azienda che opera in dominio regolato, il delta si recupera in pochi mesi grazie a evitati incidenti di compliance e a un'unica architettura che reggerà l'AI Act senza riprogettazione.

I modelli open source (Llama, Mistral, Qwen) sono adatti a contesti regolati? A maggio 2026 i modelli open weights di nuova generazione (Llama 4, Mistral Large 3, Qwen 3) hanno colmato gran parte del gap di qualità sui task generalisti, ma sui benchmark di calibrazione restano in genere uno o due gradini sotto i frontier. Per applicazioni dove la sovranità del dato pesa più della performance assoluta (es. dispositivi medici con dati pazienti, segreti industriali), un modello open su infrastruttura europea con RAG e layer di verifica è una scelta ragionevole. Per applicazioni dove conta il margine ultimo di calibrazione, oggi i frontier closed model restano avanti.

Tra sei mesi questi numeri saranno ancora validi? I numeri specifici no, i modelli evolvono di mese in mese. La struttura del problema sì. Il trade-off tra "tentare" e "astenersi" è una scelta progettuale che ogni vendor di modelli fa esplicitamente, e che continuerà a essere il driver principale di affidabilità in dominio regolato anche con i modelli del 2027. Quello che cambierà è il punto medio del trade-off, non la sua esistenza.