La sede di TechMakers a Genova è un osservatorio privilegiato sulle dinamiche dell’intelligenza artificiale applicata alle imprese. Mentre sviluppavamo documentazione tecnica per i nostri progetti di Ai conversazionale e integrazione Erp (Enterprise Resource Planning, tipo di software che le organizzazioni utilizzano per gestire le attività quotidiane di business), ci siamo imbattuti in un dato che merita attenzione: lo stesso contenuto in italiano consuma dal 18% al 45% in più di risorse rispetto all’inglese.
Non parliamo di differenze trascurabili. Su documenti identici per contenuto informativo, abbiamo misurato:
Guidelines tecniche: 2.999 token in inglese, 3.544 in italiano (+18%)
Contenuti narrativi: 762 token in inglese, 1.105 in italiano (+45%)
A parità di byte processati (la differenza di caratteri è minima, circa il 3-4%), l’italiano richiede sistematicamente più “pezzetti”, i token, per essere elaborato dai modelli di Ai. E questo ha conseguenze dirette sui costi, sulle performance e sulla fattibilità stessa di molti progetti.
Il tokenizer: quando l’Ai spezzetta le parole
Per capire il fenomeno, serve una premessa. I modelli di intelligenza artificiale non leggono il testo come lo leggiamo noi. Utilizzano un “tokenizer”: un sistema che scompone il testo in unità più piccole chiamate token. Può essere una parola intera (“casa”), parte di una parola (“svilupp” + “are”), o nei casi estremi singoli caratteri.
Il problema è strutturale: i tokenizer più diffusi, quelli utilizzati da Gpt, Claude e la maggior parte dei modelli commerciali, sono stati ottimizzati principalmente su corpus inglesi. È come se avessero “imparato” 50 mila parole inglesi complete, ma solo 10 mila italiane. Risultato: quando incontrano testo italiano, devono frammentare molto di più.
Un esempio concreto: “development” viene processato come un singolo token, mentre “sviluppo” richiede 2-3 token. Stesso significato, lavoro triplicato.
L’impatto sul tessuto imprenditoriale ligure
Questa asimmetria linguistica crea barriere concrete per le pmi del territorio che vogliono adottare soluzioni di intelligenza artificiale: per esempio costi operativi maggiorati. I servizi Ai si pagano a token. Una media impresa che elabora documentazione, contratti, comunicazioni clienti in italiano si trova con bollette dal 20% al 45% superiori rispetto a un competitor tedesco o inglese che processa volumi equivalenti. Su decine di migliaia di richieste mensili, parliamo di migliaia di euro di differenza.
Prestazioni degradate: più token significano context window ridotte, meno “spazio” per l’Ai per ragionare su documenti complessi. Un sistema che deve analizzare specifiche tecniche, ordini di acquisto, piani di produzione in italiano ha meno capacità di elaborazione simultanea rispetto allo stesso sistema operante in inglese.
Barriere all’Ai in locale: è qui che il divario diventa critico per il nostro territorio. Molte aziende liguri, pensiamo al settore portuale, alla nautica, al manifatturiero avanzato, hanno esigenze stringenti di riservatezza dei dati. Vogliono (o devono) far girare l’Ai sui propri server, non affidarsi a cloud esterni.
Per farlo, utilizzano modelli compressi, quello che tecnicamente si chiama quantizzazione, che richiedono meno risorse hardware ma perdono capacità. Un modello open source come Llama o Mistral, nella versione da 7-13 miliardi di parametri quantizzata, può girare su server da 2.000-5.000 euro. Perfetto per una pmi.
Ma c’è un problema: questi modelli sono stati addestrati per il 70-80% su testo inglese, solo il 5-10% su italiano. La compressione amplifica la disparità. In pratica, un modello che funziona egregiamente in inglese diventa mediocre – a volte quasi inutilizzabile – in italiano per compiti complessi.
Scenari concreti nel contesto ligure
Settore portuale e logistica
Un sistema Ai deve analizzare documenti di trasporto, packing list, certificazioni in italiano. Con un modello locale quantizzato, la qualità dell’estrazione dati degrada significativamente rispetto alla stessa operazione su documentazione inglese. Servono modelli più grandi (quindi hardware più costoso) o bisogna accettare errori che nel settore logistics possono avere conseguenze economiche dirette.
Nautica e cantieristica
Gestione documentale per equipaggi, analisi specifiche tecniche, sistemi di supporto alla manutenzione. Il linguaggio tecnico nautico italiano, con la sua terminologia specifica, viene frammentato ancora di più dai tokenizer. Un chatbot interno per la ricerca di procedure manutentive richiede risorse doppie rispetto alla versione inglese.
Manifatturiero e industria 4.0
Sistemi di monitoraggio che devono interpretare log, segnalazioni, procedure operative in italiano. L’overhead computazionale si somma ad altre elaborazioni real-time, creando colli di bottiglia che in inglese non esisterebbero.
Il paradosso delle pmi italiane
Si crea un circolo vizioso: le aziende che più avrebbero bisogno di democratizzare l’accesso all’Ai, ossia le PMI che non possono permettersi team dedicati o infrastrutture cloud costose, sono quelle più penalizzate.
Un’impresa tedesca può adottare Ai in locale con investimenti contenuti e ottenere risultati eccellenti. Un’impresa italiana con le stesse risorse deve scegliere: hardware più potente (costi triplicati), qualità inferiore, o rinunciare all’autonomia e affidarsi a servizi cloud esterni (con tutti i problemi di privacy e dipendenza che questo comporta).
Non è un problema di competenze tecniche del nostro tessuto imprenditoriale. È una barriera linguistica strutturale nell’architettura stessa dei sistemi Ai.
Verso l’equità linguistica: prospettive di sviluppo
La situazione non è immutabile. Alcune direzioni di sviluppo possono ridurre il divario come modelli multilingue nativi: nuove architetture di tokenizer stanno emergendo, progettate da zero per gestire equamente più lingue. Alcuni modelli recenti (come le ultime versioni di Mistral) mostrano miglioramenti significativi.
Fine-tuning localizzato: progetti open source stanno creando versioni “Italian-friendly” di modelli popolari, con dataset di addestramento arricchiti e tokenizer ottimizzati. Ma servono investimenti e competenze specifiche.
Quantizzazione consapevole: tecniche di compressione che preservano selettivamente i “pesi” neurali più importanti per lingue non-inglesi, riducendo il degrado prestazionale.
Ecosistemi regionali: la Liguria, con il suo mix di università, centri di ricerca (Iit in primis) e tessuto imprenditoriale innovativo, potrebbe giocare un ruolo nello sviluppo di soluzioni specifiche per il contesto italiano.
Conclusioni: consapevolezza come primo passo
Per le imprese liguri che stanno valutando l’adozione di soluzioni Ai, questa consapevolezza è fondamentale per scelte informate:
Budget: prevedere costi maggiorati del 20-40% per operazioni in italiano
Architettura: valutare se l’AI in locale è realmente fattibile con le risorse disponibili
Fornitori: verificare che i modelli proposti siano stati testati approfonditamente in italiano, non solo in inglese
Roadmap: considerare che il divario si ridurrà nei prossimi anni, ma oggi è una realtà da affrontare
L’intelligenza artificiale non è neutrale rispetto alla lingua. Chi opera in mercati non anglofoni deve tenerne conto nelle pianificazioni strategiche. Ma parlarne apertamente, misurare il fenomeno, condividere dati è il primo passo per creare pressione verso un ecosistema AI veramente multilingue.
Non per idealismo linguistico, ma perché c’è un mercato enorme di imprese europee non anglofone che vogliono – e meritano – di accedere a queste tecnologie senza pagare la “tassa della lingua”.
Carlo Cassinari è ceo di TechMakers srl, software house genovese specializzata in soluzioni di Ai conversazionale, integrazioni Erp e sviluppo custom per le imprese.
