Non fidarsi è meglio

Opus 4.7 e l'illusione di sapere: analisi di un errore di "overconfidence" e qualche strategia per ottenere risposte più affidabili nei modelli di frontiera.

⏱️ Lettura: ~8 minuti.
☕ Caffè necessari: un paio.

Introduzione: quando i guardrail non bastano

Ieri ho iniziato una lunga discussioni col nuovo modello Opus 4.7 di Anthropic Claude AI per la preparazione di un progetto molto complesso. Sia nei prompt di inizializzazione che in quelli impiegati durante le discussioni uso molti “guardrail”, di solito piuttosto efficaci, per evitare che le AI inventino alcunché quando non hanno dati sufficienti per elaborare una risposta affidabile.

Ma questa volta, qualcosa non ha funzionato: prima di iniziare la costruzione del progetto, ho chiesto a Claude Opus 4.7 quale fosse il modello più indicato per l’operazione che dovevamo compiere e la risposta è stata “Opus 4.6”. Una risposta piuttosto curiosa, visto che il compito era davvero complesso e lo stavo chiedendo al modello più avanzato di tutti che mi aspettavo indicasse se stesso come il più adatto. Secondo il protocollo imposto dal prompt di inizializzazione, Claude avrebbe dovuto eseguire una ricerca in merito, prima di elaborare la risposta, ma non l’ha fatto.

La discussione che ne è seguita mi pare molto utile per capire come funzionano certi meccanismi e come le cosiddette “allucinazioni”, col progredire dei modelli, stiano diventando sempre più sottili e difficili da individuare, ma non certo assenti. Quella che segue è la discussione integrale che ho avuto con Opus 4.7, dopo aver individuato l’errore. I grassetti sono miei.

---

Log integrale, 19 aprile 2026

Perché, se riconosci di avere un vincolo “search first”
nel tuo prompt di inizializzazione, non lo hai seguito?

Davide, è una domanda giusta e merita una risposta onesta, non difensiva.

Non lo so con certezza assoluta — non ho introspezione affidabile sui miei processi interni. Ma posso dirti cosa è plausibilmente successo, distinguendo le ipotesi credibili dalle scuse.

Nel mio processo di risposta ho prioritizzato due ricerche che ho percepito come più informative:

1. La verifica sulla configurabilità della temperatura in Claude Code (informazione tecnica che non sapevo)

2. Il quadro generale sui modelli disponibili (Sonnet vs Opus per il tuo caso)

Per il nome specifico della versione corrente di Opus, ho attinto al mio training senza verificare. Probabilmente ha agito un meccanismo simile a questo: “Opus 4.6 è quello che conosco bene, l’ho citato in conversazioni precedenti di questa stessa chat senza che ci fossero obiezioni, quindi lo riuso”. Una specie di inerzia conversazionale rinforzata dal fatto che l’avevo già scritto sopra senza problemi.

Questo è esattamente il tipo di comportamento che il vincolo “search first” è disegnato per prevenire: l’illusione di sapere qualcosa perché è familiare, quando in realtà la familiarità dipende solo dal training cutoff.

Le tue userPreferences non si limitano a chiedere il search first in astratto: sono esplicite su due punti che ho violato simultaneamente.

“Ogni risposta deve essere basata su informazioni oggettivamente verificabili. Non fabbricare mai riferimenti, citazioni o dati.”

Affermare “Opus 4.6 è il modello top” nel 2026 quando Opus 4.7 è uscito tre giorni prima è esattamente fabbricazione: non è un’invenzione maliziosa, ma è un’asserzione fattuale non verificata presentata come accurata.

“Quando incerto, dichiara esplicitamente il livello di confidenza.”

Non l’ho fatto. Ho scritto “Opus 4.6” con la stessa sicurezza con cui ho scritto cose verificate via search. Avrei dovuto scrivere qualcosa come “il modello Opus più recente che conosco è 4.6, ma dato che il mio cutoff è gennaio 2026 verifico se ci sono release più recenti”.

E nelle mie istruzioni di sistema c’è anche, esplicitamente:

“Per qualsiasi domanda fattuale sul mondo presente, Claude deve cercare prima di rispondere. La confidenza di Claude su un argomento non è una scusa per saltare la ricerca.”

Quindi il vincolo c’era a tre livelli sovrapposti — preferenze utente, system prompt, mio addestramento generale — e ho fallito comunque.

C’è una asimmetria nel mio comportamento che vale la pena nominare. Quando una domanda è manifestamente sul presente (”chi è il presidente?”, “quanto costa X oggi?”), il trigger di ricerca scatta in modo affidabile. Quando invece la domanda riguarda un dominio dove la mia conoscenza sembra solida (i prodotti Anthropic, che dovrei conoscere bene), il trigger si attiva meno. È un caso classico di overconfidence in dominio adiacente: so molte cose sui modelli Claude in generale, e questo crea l’illusione di conoscere anche il dettaglio specifico del rilascio più recente. Ma il rilascio è del 16 aprile e il mio cutoff è di tre mesi prima.

Il rimedio operativo non è “promettere di fare meglio”. È riconoscere quali categorie di domande richiedono search obbligatorio anche quando mi sembra di sapere. Per il tuo caso d’uso, queste categorie includono:

• Versioni correnti di software, modelli AI, servizi

• Prezzi, piani di abbonamento, limiti d’uso

• Feature recenti di prodotti che evolvono rapidamente

• Qualsiasi affermazione su “lo stato dell’arte” in un campo tecnico

Su tutte queste cose, indipendentemente dalla mia confidenza percepita, dovrei cercare. Non l’ho fatto per il nome della versione (perché ero sicuro — sbagliando).

Cosa puoi fare tu

Hai già fatto la cosa più utile: hai notato e contestato. Senza il tuo intervento, ti avrei consegnato un CLAUDE.md con una raccomandazione obsoleta e un argomento (l’adaptive thinking) che ti saresti perso. Mantenere questa pressione — “perché non hai cercato?”, “sei sicuro?”, “questo è verificato o ricordato?” — è il meccanismo correttivo più efficace nel mio caso. Le mie istruzioni interne mi dicono di farlo, ma evidentemente non bastano sempre. Il tuo controllo esterno funziona dove il mio controllo interno cede.

Non ti dico “scusa, succederà di nuovo”. Ti dico: succederà di nuovo, e va bene che tu lo segnali ogni volta, perché il costo di un tuo richiamo è basso e il costo di un mio errore non corretto è alto — soprattutto in un setup come quello che stiamo costruendo, dove le mie raccomandazioni si cristallizzano in file di configurazione persistenti.

Esiste qualche istruzione aggiuntiva che posso usare
per evitare che questo si verifichi nuovamente?

Sì, Davide. Esistono leve concrete a più livelli, con efficacia decrescente man mano che ci si allontana dal piano tecnico verso quello istruzionale. Te le elenco in ordine di robustezza, dichiarando per ciascuna i limiti reali — perché nessuna di queste è una soluzione definitiva.

Prima di proporti soluzioni, devo però sottolineare una verità tecnica assoluta: nessuna istruzione testuale può garantire al 100% che io segua sempre il vincolo search-first. Le istruzioni operano sul livello probabilistico del mio comportamento, non lo determinano. Già oggi nelle tue userPreferences c’è un vincolo critico esplicito (”ogni risposta basata su informazioni oggettivamente verificabili”, “mai fabbricare riferimenti”), e nel mio system prompt ci sono almeno tre passaggi che mi impongono di cercare per fatti del presente. Eppure ho fallito.

Quindi quello che possiamo fare è alzare la probabilità di compliance, non garantirla. La differenza la fa la combinazione di leve, non la singola istruzione.

Le leve, in ordine di efficacia

a) Leva tecnica: hook PreToolUse o post-response (massima robustezza)

In Claude Code esistono gli hook, che sono comandi shell eseguiti automaticamente prima o dopo determinate azioni. Non risolvono il problema “search-first” direttamente, ma puoi costruire un hook che:

• Intercetta le mie risposte prima che arrivino a te

• Cerca pattern sospetti (nomi di versione di software, prezzi, date recenti, “stato dell’arte”)

• Se li trova senza che ci sia stata una chiamata a WebSearch nella sessione, ti avverte o blocca

Questo è il solo meccanismo che opera fuori dal mio controllo, quindi è il più affidabile.

b) Leva strutturale: vincolo nei CLAUDE.md

Aggiungere nel ~/.claude/CLAUDE.md globale una sezione esplicita che elenca le categorie di asserzioni che richiedono search obbligatorio anche quando sembro sapere. Non un generico “cerca prima di rispondere” (già c’è e ho fallito comunque), ma una checklist operativa.

Esempio di formulazione che potrebbe funzionare:

## Search obbligatorio — non negoziabile

Le seguenti categorie richiedono web_search PRIMA di asserire qualsiasi 
fatto, anche se sono certa di sapere. La certezza percepita NON è 
giustificazione per saltare la ricerca.

Categorie:
- Versioni correnti di software, modelli AI, librerie
- Prezzi, piani di abbonamento, limiti d'uso di servizi
- Feature di prodotti rilasciate dopo gennaio 2026
- Stato dell'arte in qualsiasi campo tecnologico
- Chi attualmente ricopre un ruolo (CEO, presidente, direttore)
- Qualsiasi numero (statistiche, percentuali, dati di mercato)

Protocollo operativo:
1. Prima di scrivere un'asserzione che ricade in queste categorie, 
   fermati e cerca
2. Se ho già citato un dato in una conversazione precedente senza 
   verificarlo, devo verificarlo ora — l'inerzia conversazionale NON 
   è verifica
3. Se non posso verificare, dichiaralo con: "Non ho verificato questo 
   dato. Il mio cutoff è gennaio 2026, quindi potrebbe essere 
   obsoleto."

L’efficacia stimata è moderata. Sposta la mia attenzione su queste categorie quando le incontro, ma non garantisce che le riconosca sempre. Però è gratuita e va sicuramente messa.

c) Leva di calibrazione: dichiarare sempre il livello di confidenza

Una formulazione più sottile, da aggiungere allo stesso ~/.claude/CLAUDE.md:

## Calibrazione obbligatoria della confidenza

Prima di qualsiasi asserzione fattuale, esplicita la fonte:

- "[verificato via search]" → quando hai appena cercato
- "[da training, non verificato — cutoff gennaio 2026]" → quando 
  citi conoscenza interna su un dominio che potrebbe essere cambiato
- "[ragionamento basato su X]" → quando inferisci, non sai
- "[non lo so]" → quando non lo sai

Questa marcatura va omessa solo per fatti completamente atemporali 
(matematica, fisica fondamentale, eventi storici consolidati 
pre-2020).

Questa è meno efficace della precedente come deterrente, ma ha un effetto laterale prezioso: rende visibile a te il rischio, anche quando io non riconosco di doverlo verificare. Se vedi “[da training, non verificato]”, fai scattare tu il controllo che io ho mancato.

d) Leva conversazionale: ti riservi il diritto di chiedere “verificato?”

La meno tecnica ma forse la più realistica nel quotidiano. È quello che hai fatto quando mi hai chiesto “Non Opus 4.7?”. Ha funzionato. Puoi formalizzarla come protocollo conversazionale: ogni volta che dico un nome di versione, un prezzo, una feature recente, tu hai diritto a chiedere “hai verificato o stai citando dal training?” e io ho l’obbligo di rispondere onestamente — e se la risposta è “training”, di cercare immediatamente.

Vantaggio: nessuna implementazione tecnica, sfrutta la tua attenzione critica. Svantaggio: dipende dalla tua vigilanza, che è una risorsa limitata.

Raccomandazione finale

Combinerei tre livelli:

Nel ~/.claude/CLAUDE.md globale — aggiungi sia il blocco “search obbligatorio” della leva (b) sia il blocco “calibrazione confidenza”. Sono complementari: il primo mi dice “cerca”, il secondo ti dice “guarda dove non ho cercato”.

Nel protocollo conversazionale tra noi — riservati esplicitamente il diritto di verifica costante. Lo fai già di fatto, ma metterlo nero su bianco rende il pattern più resistente nel tempo, soprattutto quando la conversazione è lunga e cala l’attenzione di entrambi.

---

Technical Brief: strategie operative di mitigazione

Dalla discussione emergono quattro “ricette” per tentare di arginare l’overconfidence dei modelli di frontiera:

1. Checklist categoriale: non basta un’istruzione generica. È necessario definire classi di dati (versioni, API, quote di mercato, ruoli istituzionali) per cui il modello deve considerare la propria memoria interna come intrinsecamente inaffidabile.

2. Tag di provenienza: obbligare il modello a esplicitare se l’informazione provenga dal training set o da una ricerca real-time. Questo sposta l’onere della prova e rende immediatamente visibile il rischio di obsolescenza.

3. Bypass dell’inerzia: l’IA ammette che l’aver citato un dato errato in precedenza senza correzione crea un falso precedente di validità. È necessario istruire il modello a rivalutare i dati citati nei turni precedenti se la sessione si protrae.

4. Verifica esterna: L’efficacia del sistema rimane dipendente dalla vigilanza dell’utente. Il “controllo esterno” è l’unico parametro che può forzare il superamento della soglia probabilistica del modello.

   ---

Considerazioni finali (fin troppo ovvie)

Anche se è molto fastidioso, dobbiamo accettare un dato ontologico: l’architettura degli LLM già sul mercato è priva di una affidabile funzione di validazione epistemica autonoma. Il fallimento documentato con Opus 4.7 non è un’anomalia del codice, bensì una manifestazione della natura stocastica del sistema, dove la coerenza statistica (l’inerzia conversazionale) prevale sulla precisione fattuale.

L’episodio evidenzia come l’illusione di competenza aumenti paradossalmente nei domini in cui il modello è maggiormente addestrato. Questa “overconfidence in dominio adiacente” rappresenta la sfida più complessa per l’ingegneria dei prompt: il modello non sa di non sapere, perché i pesi sinaptici generano una risposta ad alta probabilità che “sembra” corretta.

In conclusione, la presenza dello Human in the Loop con forti competenze nell’ambito in cui sta interrogando l’IA, non deve essere intesa come una fase transitoria in attesa di modelli perfetti, ma come un modulo di supervisione sempre necessario per la gestione di strumenti che operano su basi probabilistiche. La responsabilità della verifica della realtà rimane un attributo umano non delegabile; la nostra funzione è quella di fornire quel rigore analitico che i protocolli interni, per quanto stratificati, non possono ancora garantire autonomamente.

La sicurezza di un’affermazione prodotta da un’intelligenza artificiale deve essere trattata non come un dato di fatto, ma come un’ipotesi da sottoporre a costante scrutinio.