Pubblicare con l'AI in cinque lingue: cosa si rompe davvero, e come lo intercetti prima del lettore

Pubblicare in cinque lingue oggi costa quanto pubblicarne una. La transcreazione AI — copy riadattato per ogni mercato, non traduzione letterale — ha tolto la barriera economica che teneva le PMI italiane dentro il confine linguistico. Questo sito lo fa da mesi: ogni articolo di /risorse esce contemporaneamente in italiano, inglese, francese, spagnolo e olandese, generato da una pipeline AI. Le 31 pubblicate prima di questa sono tutte lì, in cinque versioni ciascuna.

Quindi possiamo scrivere una cosa che quasi nessuno scrive: ecco il registro dei difetti. Non ipotesi — le cose che si sono rotte davvero, come le abbiamo trovate e cosa abbiamo cambiato. Cinque classi, e la quinta è quella che nessun rilettore avrebbe mai visto, perché il testo era perfetto.

Cinque cose che si sono rotte, e come le abbiamo trovate

Il tratto comune, prima dei dettagli: nessuna è stata intercettata prima della pubblicazione. Tutte sono emerse dopo, articolo per articolo, senza campionamento e senza un termbase bloccato sui termini legali. È il vuoto di processo che il resto di questo articolo riempie.

1. Il verbo che trasforma un fatto in un'accusa

Una frase italiana neutra su un caso giudiziario reale, con nome e parti, è arrivata in francese con una scelta verbale intensificata, editorializzante: il senso è scivolato da constatazione a qualcosa di molto vicino a un'accusa. Nessun errore di lingua, nessuna frase sgrammaticata — una deriva di registro su una materia in cui il registro è la sostanza.

È anche la classe più voluminosa che abbiamo osservato: quello stesso articolo ha richiesto tre correzioni di transcreazione nel solo francese, un altro sul settore edilizio ne ha richieste quattro in olandese. La combinazione che le produce è sempre la stessa — materia legale o regolatoria più traduzione adattiva: la transcreazione rende il testo naturale nella lingua d'arrivo, e «naturale», su una frase che descrive una controversia, spesso significa «più netto».

2. L'errore identico in tutte e cinque le lingue

Un articolo descriveva i divieti dell'EU AI Act come applicabili al solo settore pubblico. È sbagliato — e siccome l'errore stava a monte del passaggio per locale, nella premessa condivisa, la transcreazione l'ha propagato fedelmente: sbagliato in modo identico in cinque lingue, nello stesso momento. Il perimetro corretto dei divieti sta nell'articolo dedicato a cosa cambia (e cosa no) con l'EU AI Act per le PMI.

Non è una classe linguistica, ed è per questo che merita la sua riga: il QA deve verificare l'affermazione, non la traduzione dell'affermazione. Cinque revisori madrelingua ti restituiscono cinque «corrisponde», e la premessa resta falsa in tutte e cinque. La ridondanza linguistica non è ridondanza fattuale.

3. Le date che nessuna lingua scrive davvero così

Le datelines non uscivano nel formato che ciascuna lingua usa realmente: ordine di giorno e mese, separatori e convenzioni sui nomi dei mesi cambiano fra le cinque. È un difetto meccanico, non linguistico, ma viaggia sulla stessa pipeline ed è visibile quanto una mistranslation: un lettore olandese che vede una data scritta all'italiana non pensa «bug di formattazione», pensa che il sito non sia davvero suo.

4. Nessun segnale che il testo era stato corretto — questo è chiuso

Nessuno dei difetti sopra portava con sé un marcatore di revisione visibile al lettore: chi aveva letto la versione sbagliata non aveva alcun modo di sapere che nel frattempo era stata sistemata. Questa voce è già risolta e in produzione: gli articoli corretti espongono una data di revisione visibile. È l'unico punto di questo elenco che sia una mitigazione completata invece che una lacuna aperta, ed è anche il più economico da copiare.

5. La copia è giusta, è il codice a sbagliare

Questa è la migliore, ed è l'unica classe in cui il testo è corretto e il difetto è nel codice. Due componenti della home page evidenziavano graficamente l'acronimo nel titolo con una sostituzione letterale: cercavano la stringa «AI» e la avvolgevano in uno span per accentarla. La transcreazione aveva fatto il suo lavoro bene — francese e spagnolo dicono correttamente «IA» — quindi la ricerca non trovava nulla, non sostituiva nulla, e i due locali rendevano un titolo piatto.

Il punto è come fallisce: in silenzio, e in un silenzio che sfugge a ogni presidio esistente. Nessun errore. Nessuna chiave di traduzione mancante — quindi un test di simmetria delle chiavi passa, perché non manca nessuna chiave: differisce il rendering. E nessuna rilettura lo trova, perché il testo è giusto. È rimasto in produzione finché un intervento di design non ha toccato quella riga per altri motivi. La correzione è banale: un match a parola intera sull'unione delle forme locali — l'espressione regolare che riconosce sia AI sia IA come parole autonome, applicata al titolo già escapato. Ma non è lei la lezione.

La lezione vera: quando ripari un pattern, cerca il pattern — non il file

I due componenti erano identici nel difetto. Il primo è stato corretto un intero ciclo prima che il secondo venisse anche solo notato: la riparazione era stata applicata dove il bug era stato trovato, non ovunque il pattern viveva. Risultato: un difetto identico, vivo, in due lingue, sopravvissuto a un giro in più per nessun motivo. Un grep di trenta secondi sulla sostituzione letterale li avrebbe chiusi entrambi in una volta.

Vale ben oltre questo caso. Qualunque token che una vista cerca letteralmente e che cambia forma da lingua a lingua è candidato allo stesso fallimento silenzioso: acronimi (AI/IA/KI), la punteggiatura invertita dello spagnolo, simboli di valuta, appellativi. Se il tuo codice confronta una stringa in lingua sorgente, quel confronto è falso in almeno una delle lingue in cui pubblichi — e non te lo dirà nessuno.

La regola che ne abbiamo ricavato, e che applichiamo: un difetto di pattern non si chiude sul file, si chiude sul repository. Prima della correzione, il grep. Sempre.

MQM: la tassonomia che trasforma «rileggi» in una checklist

L'industria della localizzazione ha già un nome per ognuna di queste cose, e averlo cambia il modo di lavorare. MQM (Multidimensional Quality Metrics) è la tassonomia standard degli errori di traduzione, curata dall'ente che mantiene il framework: organizza i difetti in sette dimensioni — Accuratezza, Fluidità, Terminologia, Stile, Convenzioni locali, Verità, Design — ciascuna su tre livelli di gravità (minore, maggiore, critico), secondo i modelli di scoring pubblicati dal framework. È la struttura sotto le norme ISO 5060:2024 (valutazione della qualità di traduzione) e ISO 11669:2024 (progetti di traduzione), e una guida divulgativa di un fornitore di servizi linguistici ne ripercorre l'impianto per intero.

Il nostro registro si mappa sopra con un'aderenza quasi imbarazzante. Il caso francese è Accuratezza/Mistranslation, di gravità alta perché il soggetto era un caso reale con nome. L'errore di perimetro sull'AI Act è un difetto di Verità — la categoria che esiste proprio per le affermazioni false sul mondo — che diventa anche di Accuratezza una volta transcreato. Le date sono Convenzioni locali. Il titolo senza accento grafico è Design. Questa mappatura, va detto una volta, è la nostra lettura dei nostri difetti — non un risultato pubblicato da qualcuno.

Perché conta dare un nome? Perché una checklist si costruisce sulle categorie, non sulle buone intenzioni. «Fai rileggere» non è un processo: non ha criteri di uscita, non produce un dato, non dice a chi rilegge cosa cercare. «Verifica le sette dimensioni sui tre livelli di gravità, e registra ciò che trovi» sì.

Back-translation: non è la traduzione andata e ritorno

Una confusione diffusa da chiudere subito, perché produce falsa sicurezza. La round-trip translation — ributtare il testo tradotto nella macchina per riportarlo in italiano e vedere se «torna» — è un test di fumo sulla qualità del modello, non un metodo di QA. La back-translation è un'altra cosa: un linguista indipendente, che non ha mai visto l'originale, ritraduce il testo localizzato verso la lingua di partenza, e il committente confronta le due versioni cercando gli scostamenti di significato. La distinzione è definitoria: la guida operativa di un fornitore di localizzazione la costruisce su questo punto, e la voce di glossario di un grande gruppo di servizi linguistici la definisce nello stesso modo.

È lo standard indicato per i contenuti regolamentati — contratti, testi legali, materiale rilevante per la sicurezza: precisamente la categoria dei nostri due casi peggiori. E funziona dove la rilettura fallisce per una ragione meccanica: verifica l'equivalenza concettuale, non la scorrevolezza. Il verbo intensificato del caso francese era scorrevolissimo; era il concetto ad essersi spostato, e in colonna accanto all'originale uno spostamento del genere si vede a occhio nudo.

Glossario a tre livelli, applicato prima del revisore

Il presidio che avremmo dovuto avere per primo è il più noioso: un termbase bloccato. Le buone pratiche per contenuti regolamentati lo articolano su tre livelli, descritti dal blog di una piattaforma di localizzazione:

• termini di marca e di prodotto — i nomi che non si traducono mai, in nessuna lingua;
• termini tecnici e di dominio, inclusa la terminologia normativa e legale, fissata lingua per lingua in modo che il modello non possa inventarsi un equivalente plausibile ma sbagliato;
• termini vietati o a rischio — denominazioni superate, marchi altrui, formulazioni giuridicamente insidiose.

Il dettaglio che fa la differenza sta però nell'ordine di esecuzione. Il glossario va eseguito come controllo su ogni segmento prima o durante la transcreazione, con le violazioni segnalate prima che il testo arrivi a un revisore: è il flusso descritto dalla guida 2026 al workflow di enforcement terminologico di un fornitore del settore, che aggiunge anche la parte che quasi tutti saltano: un termbase ha bisogno di un proprietario con nome e cognome e di un calendario di revisione, perché un glossario corretto al lancio si degrada da solo col tempo. Sulle nostre due classi peggiori una lista di formulazioni vietate — verbi che imputano condotte, affermazioni di perimetro del tipo «si applica solo al settore X» — le avrebbe intercettate entrambe prima della pubblicazione.

Il campione del 10%, pesato sul rischio invece che piatto

La prassi corrente degli operatori di localizzazione non è rileggere tutto: si campiona circa il 10% del volume consegnato per una revisione madrelingua a posteriori, come descrive la guida al localization QA di un fornitore di testing. La parte che conta davvero è la seconda: quel 10% è una base, non una regola, e sui contenuti ad alto rischio — legale, regolatorio, sicurezza — va alzato fino alla revisione integrale.

I programmi di LQA maturi strutturano livelli di QA distinti — controllo a campione, revisione standard, revisione completa in contesto — associati alla tolleranza al rischio di ciascun tipo di contenuto: è l'impostazione di una guida pratica alla language quality assurance di un fornitore di servizi di localizzazione. Da cui la conseguenza scomoda: una percentuale di campionamento uniforme su tutti gli argomenti è già di per sé un difetto di progettazione.

Formati locali e pseudolocalizzazione: la classe che si automatizza

Date, numeri e valute sono indicati con insistenza come la classe di bug locale più frequente in assoluto: i formati scritti a mano si rompono in silenzio in ogni lingua che non sia quella d'origine — mese e giorno invertiti, separatori decimali e di migliaia che cambiano, il simbolo di valuta dal lato sbagliato. La correzione standard è smettere di scrivere stringhe e passare a formattatori consapevoli della lingua, verificati in CI, come illustra la guida 2026 alla formattazione i18n di una piattaforma di localizzazione. È il presidio che rende impossibile la nostra terza classe: non c'è modo di sbagliare un formato che non scrivi.

A monte c'è una tecnica che vale la pena conoscere anche se non fai software: la pseudolocalizzazione, spiegata dalla guida di una piattaforma di gestione traduzioni — si renderizza l'interfaccia con stringhe finte, allungate e accentate, prima che esista una traduzione reale, così i punti che si rompono saltano fuori mentre costruisci. È pensata per le stringhe di interfaccia più che per il testo editoriale: copre la tua applicazione, non i tuoi articoli.

Tre trappole che la nostra pipeline è costruita per intercettare

Tre condizioni che oggi, sulle 31 pubblicazioni che precedono questa e in tutte e cinque le lingue, risultano coerenti. Le elenchiamo lo stesso: sono il tipo di cosa che si rompe senza rumore, e un presidio si costruisce prima che serva.

• L'ordine dei file per lingua non è garantito. Il file olandese delle descrizioni degli articoli elenca le voci in un ordine diverso dall'italiano. Nessun problema oggi — ma qualsiasi automazione che assuma «la riga N in italiano corrisponde alla riga N in olandese» è sbagliata per costruzione. Si allinea per chiave, mai per posizione.
• Il francese scrive le percentuali con uno spazio prima del segno — «180 %», «70 %» — dove l'italiano scrive «180%». Conseguenza: una regex scritta guardando il testo italiano salta il francese senza segnalare nulla. Non trova zero occorrenze in modo rumoroso: ne trova meno, e sembra che vada tutto bene. Ogni sweep su testo multilingue va scritto sull'unione delle convenzioni.
• Il nostro controllo sul colofone è valutato per lingua. Corretto così — ma significa che una citazione presente in italiano e caduta in olandese spaccherebbe l'affermazione sulle fonti fra due lingue senza far scattare nulla di globale. Il presidio esiste perché questa asimmetria è possibile.

La checklist, ordinata per rischio e non a tariffa piatta

Tradotto in operazioni, per chiunque pubblichi contenuti multilingua generati con l'AI:

1. Classifica per rischio, prima di tutto il resto. Gli articoli su materia legale, fiscale o regolatoria, o che nominano casi e istituzioni reali, non ricevono lo stesso trattamento di una guida operativa: controllo in stile back-translation sulle frasi che affermano qualcosa, idealmente lettura madrelingua completa.
2. Blocca la terminologia per lingua prima della transcreazione, con l'elenco delle formulazioni vietate — verbi che attribuiscono condotte, affermazioni di perimetro — e le violazioni segnalate prima che il testo raggiunga un revisore.
3. Separa il fact-check dell'affermazione dalla verifica della traduzione. Il fact-check va fatto sulla fonte italiana, prima del fan-out. Apri il link e leggi la pagina citata contro l'affermazione: la classe peggiore di errore è quella in cui un dato verificabile e uno inventato stanno nella stessa frase, dove lo spot-check «cita fonti vere?» passa e l'affermazione resta falsa. Come dichiarare tutto questo al lettore è il tema dell'articolo su cosa dire ai clienti sull'uso dell'AI.
4. Campiona il 10% con revisione madrelingua, alzando la quota sui contenuti a rischio. È la deviazione verso l'alto che rende il campionamento utile invece che rassicurante.
5. Fai passare date, numeri e valute da un formattatore consapevole della lingua, controllato in build. Zero stringhe di data scritte a mano per lingua.
6. Grep del pattern, non del file. Ogni volta che correggi un difetto strutturale — un confronto con una stringa sorgente, un'assunzione posizionale, una regex tarata sull'italiano — cerca il pattern su tutto il codice prima di chiudere. È il controllo più economico dell'elenco ed è quello che ci è costato di più non fare.
7. Metti una data di revisione visibile sugli articoli corretti. Da noi è già in produzione: è come i programmi di qualità linguistica dichiarano un problema invece di sistemarlo di nascosto, e per chi legge è la differenza tra un sito che si corregge e uno che spera che nessuno se ne accorga.

Nessuna di queste cinque classi è un argomento contro la transcreazione AI: sono il costo di gestione di una capacità che fino a poco fa non esisteva a questo prezzo, e quel costo si paga in processo, non in traduttori. La domanda giusta prima di pubblicare non è «la traduzione è buona?», è «che cosa si romperebbe senza che nessuno mi avvisi?» — perché i difetti che contano stanno lì: non nella frase sbagliata, ma nella frase giusta resa da un codice che parla una lingua sola.

Le fonti esterne citate qui sono guide di fornitori di servizi di localizzazione, blog di piattaforme i18n e la documentazione dell'ente che cura la tassonomia MQM, consultate il 29 luglio 2026: non sono ricerca scientifica né letteratura peer-reviewed. Le norme ISO 5060:2024 e ISO 11669:2024 sono citate per nome sulla base di quelle guide, senza consultazione del testo normativo. La mappatura dei difetti osservati sulla nostra pipeline sulle dimensioni del framework MQM è un'analisi nostra, non un risultato citato da terzi. Nelle fonti consultate non esiste alcun tasso di difetto misurato per la transcreazione AI su copy legale o regolatorio: nessuna percentuale del genere è riportata qui, e diffida di chi te ne offre una.