In che lingua conviene parlare all’AI? Italiano o inglese: cosa cambia davvero

Te lo chiedono tutti, prima o poi: “ma se scrivo a ChatGPT in inglese, mi risponde meglio?”. La risposta onesta è che la differenza esiste, ma è piccola e — soprattutto — dipende da cosa gli stai chiedendo. Non è una scelta binaria tra “giusto” e “sbagliato”: è capire su quale piano la lingua conta e su quale no. In questo articolo smontiamo il mito, guardiamo cosa succede davvero dentro il modello, e chiudiamo con regole pratiche che uso ogni giorno.

Il mito dell’inglese “lingua nativa dell’AI”

La credenza è diffusa: siccome i modelli sono addestrati soprattutto su testo in inglese, l’inglese sarebbe la loro “lingua madre” e parlargli in italiano equivarrebbe a farli lavorare con un handicap. C’è un fondo di verità, ma la conclusione è sbagliata.

Il fondo di verità è la composizione del corpus di addestramento. La maggior parte del testo pubblico di alta qualità su cui questi modelli hanno imparato è in inglese: documentazione tecnica, paper scientifici, StackOverflow, gran parte di Wikipedia per profondità. Quindi sì, su alcuni argomenti molto specialistici l’inglese ha più “densità” di dati.

L’errore è pensare che questo renda il modello più intelligente in inglese. Non funziona così. Un LLM moderno non “traduce mentalmente in inglese e poi ti risponde”. Ragiona in uno spazio di rappresentazioni interne che è in larga parte indipendente dalla lingua di superficie. È un po’ come un interprete simultaneo di altissimo livello: non pensa in una lingua sola e traduce, pensa al concetto e lo esprime nella lingua che serve. La lingua con cui gli parli è l’involucro, non il motore.

Da qui in poi diventa più tecnico: vediamo perché.

I tre piani su cui la lingua incide (e non sono uguali)

Il problema di “meglio l’inglese o l’italiano?” è che tratta l’interazione come un blocco unico. In realtà ci sono tre momenti distinti, e la lingua pesa in modo diverso su ciascuno.

1. Comprensione dell’input — quanto bene il modello capisce cosa gli stai chiedendo, incluse sfumature, ironia, gergo tecnico.
2. Ragionamento e conoscenza di nicchia — la qualità del pensiero e l’accesso a informazioni specialistiche su cui il modello ha imparato.
3. Generazione dell’output — la qualità del testo che ti restituisce, nella lingua del deliverable.

La tesi di tutto l’articolo è questa: la lingua incide poco sul primo piano, un po’ sul secondo, e sul terzo la scelta giusta è quasi sempre ovvia (la lingua di chi leggerà). Chi dice “scrivi sempre in inglese” sta ottimizzando un solo piano — e nemmeno quello che conta di più.

Piano 1 — Comprensione: qui la lingua conta poco

Quando gli scrivi, la lingua dell’input è la variabile meno importante. Un brief in italiano lo capisce con la stessa precisione di uno in inglese: coglie le sfumature, il sarcasmo, il gergo tecnico SEO italiano (“cannibalizzazione”, “budget di scansione”, “posizionamento”). Se il tuo prompt è chiaro e ben strutturato in italiano, è chiaro e ben strutturato per il modello. Punto.

Piano 2 — Ragionamento e conoscenza: qui c’è un vantaggio marginale

Su compiti di ragionamento complesso o conoscenza molto verticale, l’inglese ha un vantaggio marginale. Se chiedi un edge-case di una libreria poco documentata, un dettaglio di un paper accademico, un’API di nicchia, formulare la richiesta in inglese può far emergere connessioni leggermente migliori — perché è lì che la densità di dati di training è massima. Parliamo di piccole percentuali, non di un salto di qualità. Su un ragionamento generale (logica, matematica di base, pianificazione) la differenza si azzera quasi del tutto.

Piano 3 — Output: chiedilo nella lingua del deliverable

Se il risultato finale è in italiano — un’email a un cliente, un capitolo di un libro, delle linee guida editoriali — chiedilo direttamente in italiano. Farlo ragionare in inglese e poi tradurre introduce un “sapore tradotto” nel testo, che è quasi sempre peggio del guadagno teorico ottenuto sul ragionamento. Su questo torniamo tra poco, perché è il punto più sottovalutato.

Cosa succede davvero sotto il cofano

Adesso scendiamo di un livello. Se vuoi capire perché la lingua incide così poco, devi guardare tre meccanismi: come il testo viene spezzato in token, com’è distribuito il corpus di addestramento, e come il ragionamento appreso in una lingua si trasferisce alle altre.

Tokenizzazione e “fertility”: l’italiano costa di più (ma non è un problema di intelligenza)

Prima di elaborare qualsiasi testo, il modello lo spezza in unità chiamate token, tramite un tokenizer che usa varianti di Byte Pair Encoding (BPE, introdotto in ambito NLP da Sennrich, Haddow e Birch nel 2016). Un token può essere una parola intera, un pezzo di parola o pochi caratteri. Se vuoi il quadro completo di come si arriva dai token alle risposte, ne ho parlato in come funzionano gli LLM, dai Transformer del 2017 ai modelli 2026.

Qui c’è un fenomeno reale e misurabile: i tokenizer sono ottimizzati soprattutto sull’inglese, quindi le altre lingue vengono spezzate in più token a parità di significato. Questa metrica si chiama fertility (token per parola). L’italiano, come le altre lingue latine, ha una fertility più alta dell’inglese: la stessa frase “occupa” più token.

Cosa comporta, concretamente?

• Consumo di context window: lo stesso testo in italiano riempie prima la finestra di contesto del modello. Su prompt lunghi con molti documenti allegati, è una variabile reale.
• Costo: le API si pagano a token. Un prompt in italiano costa qualcosa in più dello stesso prompt in inglese.
• NON comporta meno intelligenza: la fertility più alta è una questione di efficienza di codifica, non di comprensione. Il modello capisce l’italiano benissimo; semplicemente lo rappresenta con più token.

Chi confonde “l’italiano costa più token” con “l’AI è più stupida in italiano” sta scambiando un problema di compressione per un problema di capacità. Sono cose diverse.

La distribuzione del corpus di addestramento

Il secondo meccanismo è la composizione dei dati. I grandi corpus web multilingue (come la famiglia CommonCrawl e i dataset che ne derivano) sono fortemente sbilanciati verso l’inglese. Le lingue con meno dati di alta qualità — dette low-resource — soffrono davvero: lì il divario di performance è tangibile.

Ma l’italiano non è una lingua low-resource. È tra le lingue meglio rappresentate dopo l’inglese, con un volume di testo di qualità più che sufficiente perché il modello ne abbia una padronanza solida. Il ragionamento sul “poco training in italiano” vale per il gallese o lo swahili, non per l’italiano, lo spagnolo o il tedesco.

Cross-lingual transfer: perché il ragionamento non resta prigioniero di una lingua

Il terzo meccanismo è il più importante e il meno intuitivo: il transfer cross-linguistico. Le capacità di ragionamento che il modello sviluppa durante l’addestramento — logica, deduzione, problem solving — non sono legate a una lingua specifica. Emergono in uno spazio di rappresentazione condiviso e si trasferiscono da una lingua all’altra.

I benchmark lo mostrano bene. Esistono versioni multilingue dei test di ragionamento: MGSM (Multilingual Grade School Math, Shi et al., 2022) è la versione di GSM8K tradotta manualmente in dieci lingue per la matematica, e MMLU ha adattamenti multilingue per la conoscenza generale. MGSM non include l’italiano tra le sue dieci lingue, ma copre lingue latine confrontabili come tedesco, francese e spagnolo. Il risultato ricorrente sui modelli di frontiera è che il gap di performance tra inglese e lingue high-resource — quelle vicine all’italiano — si è molto ridotto rispetto ai modelli di qualche anno fa. Il divario grosso resta sulle lingue low-resource (nel set MGSM, per esempio, swahili o telugu), non sulle nostre.

In pratica: il modello impara a “ragionare” prevalentemente su dati inglesi, ma quella capacità la applica anche quando gli parli in italiano. È il motivo per cui il Piano 1 (comprensione) e gran parte del Piano 2 (ragionamento) non risentono quasi della lingua di input.

Il costo nascosto della traduzione

Torniamo al Piano 3, perché è dove si fanno gli errori più costosi. C’è una strategia che circola: “fatti fare il lavoro in inglese, così ragiona meglio, e poi traducilo in italiano”. Sulla carta massimizza il ragionamento. Nella pratica, se il deliverable è in italiano, spesso peggiora il risultato.

Il motivo è che la traduzione — anche fatta dallo stesso modello, anche ottima — lascia un residuo. Calchi sintattici, collocazioni che suonano “importate”, un ritmo che non è quello di chi scrive nativamente in italiano. Su un contenuto editoriale, un’email a un cliente, un testo di marketing, quel residuo si sente. E il guadagno teorico che avevi ottenuto facendo ragionare il modello in inglese — quelle piccole percentuali del Piano 2 — viene mangiato in pieno dalla perdita di naturalezza in output.

La regola pratica è semplice: se il testo finale deve essere in italiano, fallo generare direttamente in italiano. Il modello ragiona benissimo anche mentre scrive in italiano; non serve il passaggio intermedio in inglese, e nella maggior parte dei casi fa danni.

L’approccio ibrido che uso davvero

Detto tutto questo, la strategia che funziona meglio nella pratica non è “tutto italiano” né “tutto inglese”: è ibrida, e assegna la lingua in base alla funzione del testo.

• Istruzioni e prompt di sistema in inglese. Le direttive tecniche — struttura, vincoli, formato di output, regole di comportamento — le scrivo in inglese. Sono più compatte (meno token, per via della fertility), più precise, e c’è un ecosistema enorme di prompt engineering in inglese da cui pescare pattern collaudati. Se lavori con system prompt strutturati, magari in formato XML — come quelli che uso per pilotare gli agenti nella guida pratica ai server MCP con Claude Code — l’inglese è la scelta naturale per la parte di istruzioni.
• Materiale di input e output in italiano. I contenuti da elaborare (documenti, dati, esempi) e il risultato finale che leggerà una persona italiana restano in italiano. Il materiale in italiano non va tradotto: il modello lo capisce, e tradurlo introdurrebbe solo rumore.

È lo stesso principio dei tre piani: ottimizzi ogni parte per quello che le serve. Le istruzioni vogliono precisione e concisione (inglese); il contenuto vuole naturalezza per il lettore finale (italiano).

Regole pratiche: quando l’italiano e quando l’inglese

Ecco la sintesi operativa. Usa questa tabella come riferimento rapido.

Regola di default per chi non vuole pensarci: parla nella lingua che ti viene naturale, chiedi l’output nella lingua di chi lo leggerà. Nel 90% dei casi è già la scelta ottimale.

Quello che conta molto più della lingua

Ed eccoci al punto che vale più di tutto il resto: la lingua incide molto meno della qualità del prompt.

Un prompt in italiano con dati concreti, vincoli espliciti e un esempio dell’output che desideri batte sempre un prompt vago in inglese. La scelta della lingua ottimizza percentuali; la specificità del contesto cambia la qualità della risposta in modo radicale.

Se stai spendendo energie a decidere se scrivere in inglese o in italiano, le stai spendendo sul parametro sbagliato. Quelle stesse energie investite nel rendere il prompt più specifico — cosa vuoi esattamente, per chi, con quali vincoli, con quale esempio di riferimento — producono un miglioramento di un ordine di grandezza superiore.

La lingua è l’ultimo 5% dell’ottimizzazione. Il contesto è il primo 80%. Parti da lì.