L’AI non capisce quello che dici: la Stanza cinese dietro l’illusione

AI / LINGUAGGIO / SOFTWARE

Parlare con un modello linguistico produce una sensazione difficile da ignorare: sembra che dall’altra parte ci sia qualcuno che ha capito. Fai una domanda ambigua, aggiungi una sfumatura, correggi un dettaglio e la risposta si adatta. Se poi gli chiedi di scrivere software, il fenomeno diventa ancora più convincente: legge una specifica, propone classi, modifica funzioni, spiega un bug. La tentazione è chiamare tutto questo “comprensione”.

Io credo che proprio qui serva togliere un po’ di magia. Non perché l’AI sia inutile o “solo autocomplete”, due semplificazioni che spiegano poco. Ma perché l’interfaccia linguistica ci porta ad attribuire al sistema una proprietà che non possiamo dedurre semplicemente dalla qualità della conversazione.

La parte più impressionante dell’AI non è che capisca come noi. È che riesca a produrre il comportamento di un interlocutore competente senza obbligarci a vedere tutto ciò che accade tra input e output.

La Stanza cinese: una risposta perfetta senza conoscere il cinese

Nel 1980 il filosofo John Searle pubblicò Minds, Brains, and Programs e propose l’esperimento mentale diventato noto come Stanza cinese. Immaginiamo una persona chiusa in una stanza. Non conosce il cinese. Dall’esterno arrivano fogli con simboli cinesi; nella stanza esiste però un insieme di regole, scritto in una lingua che la persona comprende, che indica quali simboli restituire in risposta a determinate sequenze.

Se le regole sono abbastanza sofisticate, chi sta fuori può ricevere risposte corrette e convincersi che nella stanza qualcuno conosca il cinese. Ma la persona all’interno continua a non sapere che cosa significhi nemmeno uno dei simboli che sta manipolando. Per Searle questo separa sintassi e semantica: eseguire correttamente regole formali sui simboli non basta, da solo, a dimostrare comprensione del loro significato.

È importante non trasformare l’esperimento in una sentenza scientifica definitiva sulle LLM del 2026. La Stanza cinese è un argomento filosofico, discusso e contestato da decenni; la stessa Stanford Encyclopedia of Philosophy ricostruisce numerose obiezioni, dalla “systems reply” alle interpretazioni funzionaliste. Ma rimane una lente straordinariamente utile per una domanda molto pratica: che cosa stiamo osservando quando un sistema produce una risposta che sembra intelligente?

Il testo che scrivi non entra nel modello come testo

Prendiamo una frase banale: “Il server non risponde dopo il deploy”. Per noi è una frase con oggetti, azioni e relazioni. Abbiamo un server, un deploy, una sequenza temporale e un problema operativo. Un modello linguistico non riceve quella frase come una piccola scena già dotata di significato umano.

Il primo passaggio è la tokenizzazione. La documentazione di OpenAI sui token spiega che il testo viene suddiviso in unità che possono essere caratteri, parti di parola, parole o punteggiatura. Tokenizzazioni e ID dipendono dal modello e dalla codifica. Quindi non esiste necessariamente un oggetto interno chiamato “server” che corrisponde alla parola che abbiamo appena scritto.

I token vengono trasformati in rappresentazioni numeriche e attraversano molti strati di calcolo. L’attenzione mette in relazione parti del contesto; le attivazioni interne costruiscono rappresentazioni distribuite che possono codificare strutture sorprendentemente ricche. La ricerca sull’interpretabilità mostra infatti che dentro i modelli emergono feature associate a concetti, domini e pattern. Questo è uno dei motivi per cui dire “è soltanto statistica” è corretto quanto dire che un database è soltanto elettricità: vero a un livello, quasi inutile per spiegare il comportamento.

Alla fine, però, l’output torna a essere una sequenza di token. Il modello stima quali continuazioni siano compatibili con il contesto e genera progressivamente la risposta. Anche nei sistemi con ragionamento, tool e memoria, la conversazione che vediamo è una rappresentazione testuale prodotta da una pipeline molto diversa dal modo in cui noi sperimentiamo il significato.

L’illusione nasce nell’interfaccia

La cosa interessante è che l’illusione non è un bug. È quasi inevitabile. Il linguaggio umano è il nostro principale strumento per inferire la mente degli altri. Se qualcuno risponde correttamente, ricorda il contesto, coglie una battuta e corregge un errore, noi attribuiamo comprensione perché nella vita quotidiana è una scorciatoia ragionevole.

Con una LLM applichiamo la stessa euristica a un sistema costruito apposta per produrre linguaggio plausibile. La superficie è la stessa, il meccanismo sottostante no. E più la superficie migliora, più diventa facile confondere il successo comportamentale con una teoria su ciò che il sistema “sa”, “vuole” o “ha capito”.

Questo non diminuisce il risultato ingegneristico. Al contrario: rende ancora più interessante il fatto che rappresentazioni numeriche e trasformazioni apprese possano produrre traduzioni, sintesi, ragionamenti e codice utili. Ma ci obbliga a giudicare il sistema per ciò che possiamo verificare, non per l’antropomorfismo che l’interfaccia suggerisce.

Nel software l’equivoco diventa pericoloso

Quando chiediamo “creami un endpoint per annullare un ordine”, un modello può generare controller, validazione, query e test. A noi sembra che abbia capito che cosa sia un ordine. In realtà ciò che ci interessa davvero non è stabilire se possieda nella propria mente il concetto di ordine: ci interessa sapere se il software prodotto preserva gli invarianti del sistema.

Può aver visto nel contesto una classe Order, una convenzione per i repository, esempi di endpoint simili e test esistenti. Da questi segnali può costruire codice perfettamente plausibile. Ma se nel dominio “annullare” significa anche rilasciare una prenotazione di magazzino, invalidare un pagamento pendente, registrare un audit e impedire l’operazione dopo la spedizione, nessuna eleganza sintattica dimostra che questi vincoli siano stati compresi.

Qui la Stanza cinese smette di essere soltanto filosofia e diventa una buona disciplina di engineering. Non chiedermi se l’agente “ha capito”. Fammi vedere che ha modificato lo stato giusto, rispettato gli invarianti, superato test significativi e lasciato il sistema verificabile.

È lo stesso principio che ho affrontato nell’articolo L’agente dice “fatto”. Il database non è d’accordo: una sequenza di tool call plausibile e una risposta finale convincente non equivalgono al risultato corretto. Il database, il filesystem, la build e i test sono molto meno impressionabili di noi.

Perché il prompt non può contenere tutta la realtà

Questa distinzione spiega anche perché continuiamo a sopravvalutare i prompt. Possiamo descrivere un requisito con grande precisione, ma una frase non contiene automaticamente tutte le regole implicite del sistema su cui stiamo lavorando. Il modello può ricostruirne molte grazie al contesto e ai pattern appresi; altre non sono nel prompt, altre ancora non sono documentate da nessuna parte.

Nel software reale la semantica è spesso distribuita. Sta nel database, nei vincoli, nei test, nei log, nelle API esterne, nelle procedure operative e perfino negli errori storici che hanno generato una certa architettura. Per questo un agente efficace ha bisogno di strumenti per osservare il sistema e di confini che non dipendano dalla sua interpretazione linguistica.

È anche il motivo per cui la sicurezza degli agenti AI non può stare nel prompt. Scrivere “non fare X” è una regola espressa nel linguaggio. Impedire tecnicamente X è enforcement. Se attribuiamo al modello una comprensione quasi umana, le due cose sembrano più vicine di quanto siano davvero.

Un esempio concreto: dalla richiesta al codice

Immaginiamo di chiedere a un agente: “Aggiungi uno sconto del 10% ai clienti premium, ma solo sui prodotti non già in promozione”. La frase viene tokenizzata e trasformata in rappresentazioni interne. Il modello usa il contesto disponibile per associare “premium” a possibili campi, ruoli o metodi e “promozione” a prezzi, regole o flag. Se può usare strumenti, cercherà nel repository simboli coerenti, leggerà file e costruirà una modifica.

Può trovare Customer::isPremium() e Product::sale_price e produrre una condizione apparentemente ovvia. Ma magari nel sistema una promozione può derivare anche da una tabella campagne, da un coupon automatico o da un listino B2B. Il codice è formalmente sensato e semanticamente incompleto.

Che cosa risolve il problema? Non un prompt più poetico. Servono contesto recuperabile, test sugli invarianti, accesso controllato agli strumenti, feedback dal runtime e una verifica esterna del risultato. In altre parole: dobbiamo costruire attorno al modello un sistema che renda osservabile la parte di realtà che il linguaggio da solo non contiene.

Non capire come noi non significa non essere utile

Qui c’è una trappola opposta. Se rifiutiamo l’idea che una risposta fluida dimostri comprensione umana, non segue che l’AI sia un giocattolo probabilistico incapace di rappresentare qualcosa. Le reti moderne sviluppano rappresentazioni interne complesse; la ricerca di interpretabilità di Anthropic, per esempio, mostra feature associate a concetti e pattern che non coincidono banalmente con singoli token. Il dibattito su che cosa meriti davvero la parola “comprensione” resta aperto.

Dal punto di vista di chi costruisce software, però, possiamo evitare di risolvere oggi il problema filosofico. Possiamo adottare una regola molto più utile: non usare l’impressione di comprensione come garanzia operativa.

L’AI può essere straordinariamente competente senza che la sua competenza ci autorizzi a trattarla come un essere umano che ha capito il contesto implicito.

Togliere il velo rende l’AI più interessante, non meno

La Stanza cinese continua a essere affascinante perché separa due cose che l’interfaccia tende a fondere: ottenere la risposta giusta e sapere che cosa quella risposta significhi. Le LLM moderne rendono la separazione molto più difficile da percepire, perché non applicano un libretto statico di regole scritto da un programmatore: apprendono rappresentazioni e regolarità da enormi quantità di dati e producono comportamenti che Searle non poteva osservare nei sistemi del 1980.

Proprio per questo l’esperimento non va usato come slogan per liquidare l’AI. Va usato come antidoto all’eccesso opposto: scambiare una conversazione credibile per la prova che dall’altra parte esista lo stesso tipo di comprensione che attribuiamo a una persona.

Nel software la conseguenza è concreta. Un modello non deve “capire” il nostro gestionale nel senso umano per aiutarci a modificarlo. Deve avere abbastanza contesto, strumenti abbastanza precisi e verifiche abbastanza forti da produrre un cambiamento corretto. La magia finisce lì. E, a mio avviso, è proprio quando finisce la magia che comincia l’ingegneria.