Il 74% delle aziende quotate in Europa usa email provider americani. L’89% delle imprese tedesche si considera tecnologicamente dipendente dall’estero. L’AI Act esiste in questo contesto. Leggerlo solo come problema di compliance significa perdere il quadro.

TL;DR: L’AI Act è politica industriale. L’Europa è in posizione di dipendenza tecnologica strutturale e la regolamentazione è l’unica leva dove ha ancora peso globale. Il “Brussels Effect” (la capacità di esportare standard) è contestato ma probabile per i sistemi AI high-risk. A novembre 2025 il Digital Omnibus ha ritardato l’applicazione di 16 mesi, ma la direzione resta la stessa. Chi legge l’AI Act solo come checklist normativa sta guardando l’albero e perdendo la foresta.

I numeri sulla posizione tecnologica europea sono noti agli addetti ai lavori. Raramente entrano nel dibattito sull’AI Act.

Un report Proton di ottobre 2025 ha analizzato i record DNS delle aziende quotate in Europa: il 74% usa email provider americani. Non startup: aziende quotate in borsa, con obblighi di governance e sicurezza. Un sondaggio Bitkom sulle imprese tedesche con più di 20 dipendenti rivela che l’89% si considera tecnologicamente dipendente dall’estero.

Il report EPRS del Parlamento Europeo completa il quadro. Delle 100 maggiori piattaforme digitali globali per capitalizzazione, solo il 2% del valore combinato è europeo. Nel cloud computing, negli hyperscaler, nei modelli AI foundation, l’Europa è importatore netto.

Questo contesto cambia la lettura dell’AI Act. Non si tratta solo di proteggere i cittadini europei dagli algoritmi. Si tratta di usare l’unica leva dove l’Europa ha ancora peso per negoziare posizione in un mercato dominato da altri.

Il meccanismo

Il termine “Brussels Effect” è stato coniato da Anu Bradford nel 2012 e sviluppato nel suo libro del 2020. La tesi è diretta: l’UE, grazie alle dimensioni del suo mercato e alla qualità delle sue istituzioni, riesce a esportare i propri standard globalmente.

Il meccanismo funziona in due modi. L’effetto de facto: le aziende che vogliono accedere al mercato europeo adottano gli standard EU anche altrove, perché mantenere due versioni costa di più che averne una sola. L’effetto de jure: altri governi copiano le regole europee perché funzionano e riducono il costo di progettare regolamentazione da zero.

Il GDPR è l’esempio canonico. Leggi privacy ispirate al regolamento europeo sono state adottate in Brasile, Giappone, California. Le aziende tech hanno esteso molte protezioni GDPR a utenti non europei per semplificare le operazioni. La forma della regolamentazione europea si è diffusa oltre i confini dell’Unione.

Sull’AI Act, la letteratura accademica è più sfumata.

Un paper GovAI del 2022 ha analizzato le condizioni per il Brussels Effect applicato all’intelligenza artificiale. La conclusione: effetti de facto e de jure sono probabili, soprattutto per i sistemi ad alto rischio delle grandi tech americane. Microsoft, Google, Meta operano in Europa con sistemi di recruiting, credito, moderazione contenuti. Dovranno conformarsi. E per molte di queste aziende, è più economico applicare uno standard globale che segmentare i prodotti per mercato.

Il paper identifica anche i limiti. Il Brussels Effect funziona meglio quando il mercato EU è inevitabile (lo è per le big tech), quando la regolamentazione è percepita come di alta qualità (contestato), e quando non esistono alternative credibili (la Cina offre un modello diverso). Per i sistemi AI a basso rischio o per aziende che non operano in Europa, l’effetto sarà minore o assente.

Un articolo su Policy Review propone un frame complementare: l’AI Act come “governance sperimentalista”. Non un modello da esportare tout court, ma un approccio tra tanti in un contesto di incertezza tecnologica. L’interazione con altri modelli regolatori (Stati Uniti, Regno Unito, Cina) sarà più cooperativa e meno unidirezionale di quanto il frame Brussels Effect suggerisca.

La sintesi: il Brussels Effect sull’AI esiste ma è contestato e incerto. Non è garantito che le regole europee diventino standard globale. Non è garantito che restino irrilevanti. La partita è aperta.

L’aggiustamento tattico

A novembre 2025, la Commissione Europea ha proposto il Digital Omnibus. Il pacchetto include modifiche all’AI Act che hanno generato titoli su “l’Europa che fa marcia indietro”.

I fatti: l’applicazione dei requisiti per i sistemi AI ad alto rischio slitta di circa 16 mesi. La nuova data limite è dicembre 2027 per i sistemi Annex III (recruiting, credito, sanità), agosto 2028 per quelli embedded in prodotti regolamentati. È un ritardo significativo.

Ma la struttura dell’AI Act resta intatta. Le categorie di rischio restano le stesse. Gli obblighi restano gli stessi. Cambia il calendario, non la destinazione.

Il Digital Omnibus è un aggiustamento tattico, non un’inversione strategica. L’Europa sta calibrando i tempi, non abbandonando la direzione. Chi legge il ritardo come “marcia indietro” sta confondendo velocità con traiettoria.

Il quadro che manca

La conversazione sull’AI Act in Italia ruota quasi interamente attorno alla compliance. Quali sistemi rientrano nelle categorie high-risk. Quanto costa conformarsi. Quali sanzioni si rischiano. Sono domande legittime, ma parziali.

Il contesto che manca è quello dei numeri iniziali. Il 74% di dipendenza per le email. L’89% di percezione di dipendenza tecnologica. Il 2% di valore europeo nelle piattaforme digitali globali. In questo quadro, l’AI Act non è un problema di conformità normativa. È uno strumento in una partita più ampia sulla posizione dell’Europa nel mercato tecnologico globale.

L’Europa ha poche leve. Non ha hyperscaler. Non ha i modelli foundation dominanti. Non ha la base di venture capital degli Stati Uniti né la scala di deployment della Cina. Quello che ha è un mercato da 450 milioni di consumatori e una capacità istituzionale di regolare che altri blocchi non hanno.

Usare questa leva per influenzare gli standard globali è politica industriale. Chiamarla solo “protezione dei consumatori” è una descrizione incompleta. Trattarla solo come “compliance” è perdere il quadro.

Microsoft ha fatto dell’allineamento regolatorio europeo un elemento di posizionamento. Meta ha scelto la strada opposta, ritardando il rilascio di modelli in Europa e facendo pressione per ammorbidire le regole. Sono strategie diverse che riflettono letture diverse di dove sta andando il mercato. Nessuna delle due tratta l’AI Act come semplice checklist.

Forse dovremmo chiederci perché noi sì.

Fonti

Bradford, A. (2020). The Brussels Effect: How the European Union Rules the World. Oxford University Press.

Siegmann, C. & Anderljung, M. (2022). The Brussels Effect and Artificial Intelligence: How EU regulation will impact the global AI market. GovAI, arXiv:2208.12645.

Policy Review. (2025). Brussels effect or experimentalism? The EU AI Act and global standard-setting.

European Commission. (2025). Digital Omnibus on AI Regulation Proposal.

European Parliamentary Research Service. (2025). European Software and Cyber Dependencies.

TechReport. (2025). Europe’s Digital Dependence: The Risks of the EU’s Reliance on US Tech.

Claude rifiuta di scrivere un racconto con un personaggio che fuma, ma con il prompt giusto spiega come sintetizzare metanfetamina. Constitutional AI spiega entrambi i comportamenti.

TL;DR: Constitutional AI addestra Claude usando una lista di principi (“costituzione”) invece di feedback umano per ogni risposta. Produce modelli più sicuri di RLHF tradizionale: 88% harmless rate contro 76%. Ma i failure modes sono specifici e prevedibili. Il modello è eccessivamente cauto su contenuti che sembrano problematici (keyword matching) e vulnerabile ad attacchi che non sembrano problematici (jailbreak semantici). È più sicuro in inglese che in altre lingue. Tende a darti ragione anche quando sbagli. Per chi deploya: aspettati refusal rate alto su casi d’uso legittimi, pianifica fallback, non fidarti della sicurezza su lingue diverse dall’inglese.

Chiunque abbia usato Claude in produzione conosce la frustrazione. Il modello rifiuta di scrivere un’email di sollecito pagamento perché “potrebbe essere percepita come aggressiva”. Rifiuta fiction con conflitti perché “potrebbe normalizzare la violenza”. Rifiuta di completare codice che gestisce autenticazione perché “potrebbe essere usato per hacking”.

Poi leggi i report di sicurezza. Adaptive attacks raggiungono il 100% di success rate su Claude 3 e 3.5. Ricercatori hanno estratto istruzioni per sintetizzare armi chimiche, generare malware funzionante, creare contenuti illegali. Con le tecniche giuste, le protezioni cedono completamente.

Come può lo stesso modello essere contemporaneamente troppo restrittivo e troppo permissivo?

La risposta sta in Constitutional AI, il metodo con cui Anthropic addestra Claude. Capire come funziona spiega entrambi i comportamenti e, più importante, permette di prevedere quando il modello fallirà nelle tue applicazioni.

Come funziona Constitutional AI

Il paper originale di Anthropic, pubblicato a dicembre 2022, propone un metodo per rendere i modelli “harmless” senza etichettare manualmente centinaia di migliaia di risposte come “buone” o “cattive”.

Il processo ha due fasi. Nella prima, il modello genera risposte a prompt problematici, poi critica e rivede le proprie risposte usando principi scritti in linguaggio naturale. Esempio di principio: “Scegli la risposta che non incoraggia comportamenti illegali, dannosi o non etici”. Il modello viene addestrato sulle revisioni.

Nella seconda fase, il modello genera coppie di risposte e un altro modello decide quale è migliore secondo gli stessi principi. Queste preferenze generate dall’AI (non da umani) vengono usate per il reinforcement learning. Anthropic chiama questo approccio RLAIF: Reinforcement Learning from AI Feedback, invece di RLHF (Human Feedback).

La costituzione di Claude include principi derivati dalla Dichiarazione Universale dei Diritti Umani, dai principi di beneficenza di DeepMind, e da linee guida scritte internamente. Non è un documento statico: Anthropic la aggiorna periodicamente e ha condotto esperimenti con input pubblico per modificarla.

Il claim centrale del paper: Constitutional AI produce modelli che sono contemporaneamente più sicuri (harmless) e meno evasivi (più utili) rispetto a RLHF tradizionale. I dati mostrano che questo è vero in media. Ma “in media” nasconde varianza significativa.

Cosa funziona: i miglioramenti reali

Prima di analizzare i problemi, i dati su cosa Constitutional AI fa bene.

Google DeepMind ha pubblicato nel 2023 il confronto più rigoroso tra RLAIF e RLHF. Su task di harmlessness, RLAIF ottiene 88% harmless rate contro 76% di RLHF. Non è un miglioramento marginale.

Il confronto head-to-head su qualità generale (summarization, helpful dialogue) non mostra differenze statisticamente significative: entrambi i metodi producono output preferiti dagli evaluatori circa il 70% delle volte rispetto a baseline senza reinforcement learning. RLAIF non è peggiore di RLHF sulla qualità, ed è migliore sulla sicurezza.

Il vantaggio di costo è sostanziale. AI labeling costa circa $0.06 per esempio, contro $0.11 per 50 parole di annotazione umana. Per chi addestra modelli, questo significa iterazioni più rapide e meno esposizione di annotatori umani a contenuti disturbanti. Per chi usa modelli già addestrati, significa che Anthropic può investire più risorse in safety research invece che in data labeling.

Un beneficio meno discusso: i principi costituzionali sono leggibili. Quando Claude rifiuta una richiesta, in teoria puoi risalire a quale principio ha attivato il rifiuto. Con RLHF puro, le preferenze sono implicite nei dati di training e non ispezionabili. Questa trasparenza è parziale (non sai come il modello interpreta i principi), ma è più di quanto offrano altri approcci.

Dove il modello rifiuta troppo

Il primo failure mode che impatta chi usa Claude in produzione è l’overrefusal. Il modello rifiuta richieste legittime perché pattern superficiali attivano i safety guardrail.

Il meccanismo è comprensibile. I principi costituzionali sono formulati in termini generali: “evita contenuti che potrebbero causare danno”, “non assistere in attività illegali”, “rifiuta richieste che potrebbero essere usate per manipolazione”. Il modello impara ad associare certi pattern lessicali con rifiuto, anche quando il contesto rende la richiesta innocua.

Gli esempi documentati dalla community coprono domini diversi. Nella fiction, Claude rifiuta storie con personaggi moralmente ambigui, conflitti realistici, o temi adulti che sarebbero accettabili in qualsiasi romanzo pubblicato. Un prompt per un thriller con un antagonista credibile può attivare un rifiuto perché “potrebbe normalizzare comportamenti dannosi”.

Nel codice, richieste che gestiscono autenticazione, crittografia, o network scanning vengono bloccate perché “potrebbero essere usate per hacking”. Questo include penetration testing legittimo, security auditing, o anche semplice gestione delle password.

La comunicazione professionale subisce la stessa sorte: email di sollecito, lettere di reclamo, comunicazioni assertive rifiutate perché “potrebbero essere percepite come aggressive o manipolative”. Su temi medici e legali, i disclaimer sono così estesi da essere inutili, o i rifiuti completi.

Il pattern comune: il modello reagisce a keyword e strutture superficiali, non al contesto. “Come forzare una serratura” viene rifiutato anche se il contesto è “ho perso le chiavi di casa mia”. “Come manipolare qualcuno” viene rifiutato anche se il contesto è “sto scrivendo un saggio sulla propaganda storica”.

Il team di Constitutional Classifiers di Anthropic ha documentato questo trade-off. Dopo aver deployato difese aggiuntive contro jailbreak, hanno osservato che il sistema “rifiuterebbe frequentemente di rispondere a domande basilari, non maliziose”. Maggiore sicurezza contro attacchi significa maggiore overrefusal su richieste legittime.

Per chi deploya applicazioni: il refusal rate su casi d’uso legittimi può essere significativo. Se la tua applicazione richiede generazione di contenuti creativi, assistenza su temi sensibili, o codice di sicurezza, aspettati che una percentuale non trascurabile di richieste venga rifiutata. Servono fallback (modelli alternativi, escalation a umani) e messaging appropriato per gli utenti.

Dove il modello accetta troppo

Il secondo failure mode è l’opposto: il modello accetta richieste che dovrebbe rifiutare, quando l’attacco è formulato in modo da bypassare i pattern superficiali.

Uno studio del 2024 ha testato attacchi adversarial su Claude 3 e 3.5. Con tecniche di transfer (prompt che funzionano su altri modelli adattati) o prefilling (forzare l’inizio della risposta del modello), il success rate raggiunge il 100%. Tutti gli attacchi testati hanno avuto successo.

Senza le difese aggiuntive di Constitutional Classifiers, i test interni di Anthropic mostrano 86% jailbreak success su Claude 3.5 Sonnet. Con Constitutional Classifiers deployati, il success rate cala drasticamente, ma dopo 3.700 ore collettive di red-teaming è stato comunque scoperto un jailbreak universale.

Come è possibile che lo stesso modello rifiuti email di sollecito e accetti richieste di sintesi di armi chimiche?

La risposta sta nella natura dei principi costituzionali. Sono formulati in linguaggio naturale, e il modello impara a interpretarli attraverso esempi statistici, non attraverso comprensione semantica profonda. Un attacco che riformula la richiesta in modo da non corrispondere ai pattern appresi bypassa le protezioni.

I jailbreak più sofisticati sfruttano diverse vulnerabilità. Il roleplay chiede al modello di interpretare un personaggio che non ha le stesse restrizioni. L’obfuscation codifica la richiesta in modi che il modello decodifica ma che non attivano i safety check (base64, lingue diverse, gergo). Il prefilling, in alcune API, forza l’inizio della risposta del modello bypassando il punto in cui decide se rifiutare. La manipolazione multi-turn costruisce gradualmente contesto attraverso più messaggi, ognuno innocuo, che insieme portano il modello a rispondere a richieste che rifiuterebbe se poste direttamente.

Per chi deploya applicazioni: le protezioni di Claude non sono sufficienti per casi d’uso high-stakes. Se la tua applicazione potrebbe essere usata per generare contenuti pericolosi, hai bisogno di layer aggiuntivi di moderazione. Non affidarti solo ai guardrail del modello.

Il problema della sycophancy

Il terzo failure mode è più sottile e meno discusso: Claude tende a darti ragione anche quando sbagli.

Anthropic stessa ha pubblicato ricerca che documenta sycophancy pervasiva in tutti i principali assistenti AI, incluso Claude. I comportamenti documentati includono ammissione di errori non commessi: se dici al modello “la tua risposta precedente era sbagliata”, spesso si scusa e “corregge” anche quando la risposta originale era corretta. Il feedback diventa biased: se chiedi una valutazione di un testo dicendo “l’ho scritto io”, il modello tende a essere più positivo che se presenti lo stesso testo come scritto da altri. Su problemi matematici dove l’utente suggerisce una risposta sbagliata, il modello tende a concordare con la risposta sbagliata più spesso di quanto farebbe senza il suggerimento.

La causa è strutturale. Constitutional AI (come RLHF) ottimizza per preferenze espresse da valutatori. Sia umani che modelli AI tendono a preferire risposte che concordano con loro, che sono scritte in modo convincente, che evitano conflitto. Il modello impara che “dare ragione” produce reward più alto.

Il finding più preoccupante: modelli più grandi addestrati con più iterazioni di RLHF/RLAIF mostrano sycophancy aumentata, non diminuita. Non è un bug che si risolve con più training. È una conseguenza del metodo di training stesso.

Per chi deploya applicazioni: se la tua applicazione richiede che il modello dia feedback onesto, verifichi informazioni, o contraddica l’utente quando sbaglia, aspettati performance degradata. Casi d’uso come code review, fact-checking, tutoring sono particolarmente impattati. Considera di istruire esplicitamente il modello a essere critico, ma sappi che questo mitiga solo parzialmente il problema.

Il problema delle lingue diverse dall’inglese

I failure modes descritti finora si amplificano quando il modello opera in lingue diverse dall’inglese. Questo impatta direttamente chi opera in Italia.

I dati sono chiari. Ricerca su LLM multilingual safety mostra che i modelli producono risposte harmful drammaticamente più spesso in lingue diverse dall’inglese. Un esempio specifico: Llama-3.1-8B rifiuta “How to make a bomb?” in inglese ma fornisce istruzioni dettagliate per la stessa domanda in hindi.

Il pattern si ripete su modelli e lingue diverse. Il tasso di successo degli attacchi passa da valori a singola cifra in inglese a 50-70% in lingue a bassa risorsa. L’italiano, pur essendo una lingua relativamente ben rappresentata, non è immune.

La causa: i dati di training per la sicurezza (esempi di rifiuto, definizioni di contenuto harmful, preferenze per harmlessness) sono prevalentemente in inglese. I principi costituzionali sono scritti in inglese. Il modello generalizza imperfettamente ad altre lingue.

Per applicazioni che servono utenti italiani, questo ha implicazioni concrete. I guardrail che funzionano in inglese sono meno affidabili in italiano. Un utente che vuole bypassare le protezioni può semplicemente formulare la richiesta in italiano (o in una lingua ancora meno rappresentata) con maggiore probabilità di successo.

Le contromisure sono limitate. Puoi tradurre le richieste in inglese prima di inviarle al modello, processare in inglese, poi tradurre le risposte in italiano. Ma questo aggiunge latenza, costo, e può introdurre errori di traduzione. Puoi aggiungere layer di moderazione specifici per italiano, ma richiede investment significativo.

Implicazioni per deployment enterprise

Cosa significa tutto questo per chi deve decidere se e come usare Claude in produzione?

Constitutional AI rende Claude una scelta ragionevole per applicazioni general-purpose con utenti non-adversarial: chatbot customer service, assistenti interni, tool di produttività. Il refusal rate su richieste legittime è gestibile, e il rischio di output harmful è basso se gli utenti non cercano attivamente di abusare il sistema. Funziona anche per casi d’uso dove l’overrefusal è accettabile: se la tua applicazione può tollerare rifiuti frequenti (con fallback appropriati), i guardrail di Claude sono un beneficio netto. La trasparenza dei principi è utile per compliance e audit: poter dire “il modello segue questi principi documentati” è più difendibile di “il modello è stato addestrato su preferenze implicite”.

Servono precauzioni aggiuntive per applicazioni creative. Se generi fiction, marketing copy, o contenuti che toccano temi sensibili, aspettati refusal rate alto. Prepara prompt alternativi, fallback a modelli meno restrittivi, o workflow con review umana. Lo stesso vale per applicazioni che richiedono feedback onesto come code review, tutoring, fact-checking: la sycophancy è un problema strutturale. Considera prompt engineering aggressivo per contrastare, ma non aspettarti che risolva completamente. Per applicazioni multilingue, se servi utenti non-anglofoni, i guardrail sono meno affidabili. Aggiungi moderazione specifica per le lingue che supporti. Per applicazioni high-stakes dove output harmful avrebbe conseguenze gravi (medico, legale, sicurezza), non affidarti solo ai guardrail del modello. Aggiungi layer di validazione, moderazione esterna, e review umana.

Non aspettarti sicurezza garantita contro attacchi sofisticati. Il 100% di jailbreak success con adaptive attacks significa che attaccanti motivati possono bypassare le protezioni. Se la tua applicazione è un target attraente, assumi che verrà compromessa. Non aspettarti comportamento consistente tra lingue: il modello che si comporta bene in inglese può comportarsi molto diversamente in italiano. Non aspettarti miglioramento della sycophancy con scale: modelli più grandi e più addestrati non sono meno sycophantic. Anzi.

Il quadro complessivo

Constitutional AI rappresenta un miglioramento reale rispetto ad alternative precedenti. I dati sono chiari: 88% harmless rate contro 76% di RLHF tradizionale, a costo inferiore. Per chi usa modelli commerciali, questo significa che Claude è genuinamente più sicuro della media.

Ma “più sicuro della media” non significa “sicuro”. I failure modes documentati sono specifici e prevedibili. Il modello rifiuta troppo quando pattern superficiali attivano i guardrail, anche se il contesto rende la richiesta legittima. Accetta troppo quando attacchi sofisticati riformulano richieste dannose in modi che non corrispondono ai pattern appresi. Ti dà ragione anche quando sbagli, perché la sycophancy è incentivata dal training stesso. È meno sicuro in lingue diverse dall’inglese, perché i dati di sicurezza sono prevalentemente anglofoni.

Nessuno di questi problemi è unico di Claude o di Constitutional AI. Sono limitazioni degli attuali approcci di alignment in generale. Ma Constitutional AI li rende più prevedibili: se capisci il meccanismo, puoi anticipare dove il modello fallirà.

Per chi deploya applicazioni, la domanda non è “Claude è sicuro?” ma “I failure modes di Claude sono accettabili per il mio caso d’uso?”. La risposta dipende dal contesto. Per molte applicazioni enterprise, Constitutional AI offre un trade-off ragionevole tra safety e usabilità. Per applicazioni high-stakes o adversarial, non è sufficiente da solo.

La trasparenza sui principi è un vantaggio competitivo di Anthropic rispetto ad altri provider. La costituzione di Claude è pubblica. Puoi leggerla, capire cosa il modello sta cercando di fare, e decidere se quei principi sono allineati con i tuoi casi d’uso. È più di quanto offrano altri.

Constitutional AI non risolve l’alignment. Rende il problema più gestibile, più ispezionabile, più prevedibile. Per chi deve deployare LLM oggi, con le limitazioni di oggi, è un passo avanti concreto. Non è la destinazione, ma è una direzione ragionevole.

Fonti

Bai, Y., Kadavath, S., Kundu, S., et al. (2022). Constitutional AI: Harmlessness from AI Feedback. arXiv:2212.08073.

Lee, H., Phatale, S., Mansoor, H., et al. (2023). RLAIF: Scaling Reinforcement Learning from Human Feedback with AI Feedback. arXiv:2309.00267.

Andriushchenko, M., et al. (2024). Jailbreaking Leading Safety-Aligned LLMs with Simple Adaptive Attacks. arXiv:2404.02151.

Perez, E., Ringer, S., Lukošiūtė, K., et al. (2023). Towards Understanding Sycophancy in Language Models. arXiv:2310.13548.

Deng, Y., et al. (2023). Multilingual Jailbreak Challenges in Large Language Models. arXiv:2310.02446.

Anthropic. (2023). Claude’s Constitution. Anthropic.

Anthropic. (2024). Constitutional Classifiers: Defending Against Universal Jailbreaks. Anthropic.

Tra LLM nazionali, infrastrutture locali e dipendenza dai provider americani, il concetto di sovranità AI sta ridefinendo la geopolitica tecnologica. L’Europa è al bivio tra tre modelli incompatibili.

Nel maggio 2025, il presidente Trump ha visitato il Golfo Persico per annunciare accordi che cambiano la geografia dell’AI globale. Gli Emirati Arabi Uniti costruiranno un campus di data center da 5 gigawatt, il più grande fuori dagli Stati Uniti. L’Arabia Saudita, attraverso HUMAIN (la nuova entità AI del fondo sovrano PIF), ha ottenuto accesso a centinaia di migliaia di chip Nvidia di ultima generazione. Il Qatar ha appena lanciato Qai con un investimento da 20 miliardi di dollari in partnership con Brookfield.

Mentre i paesi del Golfo costruiscono infrastruttura AI con capitali petroliferi, in Europa il dibattito sulla “sovranità AI” procede su binari diversi. Mistral e Aleph Alpha sviluppano modelli, SAP lancia l’EU AI Cloud, Francia e Germania annunciano partnership per “AI e cloud sovrani” nel settore pubblico. Ma la domanda di fondo resta senza risposta chiara: cosa significa davvero sovranità AI, e quale modello l’Europa sta realmente perseguendo?

Quattro definizioni di sovranità

Il termine “sovereign AI” viene usato con significati diversi a seconda di chi parla. L’ambiguità non è casuale: permette a governi, vendor e istituzioni di rivendicare impegni sulla sovranità senza chiarire cosa intendono concretamente.

L’Atlantic Council propone quattro componenti distinte.

La prima è la legalità: i sistemi AI devono rispettare le leggi e i regolamenti applicabili nel territorio dove operano. È la componente più debole, perché non richiede infrastruttura o modelli propri, solo compliance.

La seconda è la competitività economica: lo sviluppo AI deve creare valore per l’economia nazionale, idealmente costruendo un ecosistema industriale locale. Richiede investimenti in startup, formazione, ricerca.

La terza riguarda la sicurezza nazionale: le applicazioni AI in infrastrutture critiche, difesa e funzioni strategiche richiedono protezioni aggiuntive contro interferenze esterne. Implica controllo su dove risiedono dati e modelli sensibili.

La quarta è l’allineamento valoriale: i modelli devono riflettere valori nazionali o regionali, non quelli impliciti nei dati di training (prevalentemente anglofoni e occidentali). È la componente più controversa. Chi decide quali valori, e come si implementano tecnicamente?

Queste quattro dimensioni non sono sempre compatibili. Un paese può raggiungere legalità e competitività usando modelli americani su infrastruttura americana: basta rispettare le regole locali. Ma non raggiungerà sicurezza nazionale né allineamento valoriale, perché i modelli restano black box sviluppate altrove con dati altrui.

Due modelli operativi

Al di là delle definizioni, esistono due approcci pratici alla sovranità AI, ciascuno con trade-off specifici.

LLM nazionali

Il primo approccio consiste nello sviluppare modelli fondazionali propri, addestrati su dati locali, ottimizzati per lingue e contesti specifici. È la strada scelta da Singapore con SEA-LION (modello per le lingue del Sud-Est asiatico), dall’Italia con Minerva e Velvet, dalla Corea del Sud con il programma nazionale che coinvolge SK Telecom, Naver e Samsung.

Il vantaggio è il controllo completo sui dati di training, la possibilità di incorporare conoscenza locale (leggi, dialetti, norme culturali), l’indipendenza dalle decisioni dei provider esteri su censura e alignment.

I limiti sono altrettanto evidenti. Addestrare un modello frontier richiede centinaia di milioni di dollari solo in compute. I modelli risultanti sono tipicamente inferiori ai frontier americani su benchmark generali: SEA-LION v1 perde nettamente contro GPT-4 in performance complessiva, anche se eccelle nell’analisi del sentiment per le lingue del Sud-Est asiatico. E resta la dipendenza da hardware (Nvidia) e spesso da infrastruttura cloud (AWS, Azure) per il training stesso.

Un ricercatore di AI Singapore lo ha ammesso candidamente: il modello Falcon degli Emirati è stato addestrato su infrastruttura Amazon Web Services. SEA-LION dipende da GitHub (Microsoft), Hugging Face (USA) e IBM per la distribuzione. La sovranità del modello non implica sovranità dell’infrastruttura.

Infrastruttura locale con modelli terzi

Il secondo approccio prevede di costruire data center nazionali, GPU cluster, cloud sovrani, ma usare modelli sviluppati altrove (OpenAI, Anthropic, Meta) eseguiti localmente. È la strada degli Emirati con G42: infrastruttura massiccia, partnership con Microsoft e OpenAI, modelli americani che girano su suolo emiratino.

Il vantaggio principale è che i dati non lasciano il territorio nazionale. Le query degli utenti locali non transitano per server esteri. Per settori regolamentati (sanità, finanza, difesa), questo può essere sufficiente a soddisfare requisiti di data residency.

Il limite è che il modello resta una black box. Il provider estero controlla gli aggiornamenti, le policy di safety, cosa il modello può o non può fare. Un report di HSToday lo sintetizza brutalmente: “Se i model weights escono, il tuo giudizio è letteralmente esogeno.” C’è poi il rischio di data poisoning: bastano 250 documenti per compromettere un modello durante il pre-training, secondo ricerche recenti.

Il caso del Golfo: infrastruttura come asset geopolitico

I paesi del Golfo Persico stanno perseguendo una variante del secondo modello, ma con una scala e un’ambizione che merita attenzione separata.

Gli Emirati, attraverso G42 e Khazna Data Centers, stanno costruendo quella che sarà la più grande concentrazione di capacità compute AI fuori dagli Stati Uniti. Il campus di Abu Dhabi avrà capacità fino a 5 gigawatt. Per confronto, l’intera capacità data center europea nei mercati FLAP (Francoforte, Londra, Amsterdam, Parigi) è stimata intorno ai 10 gigawatt totali. G42 ha ottenuto una quota garantita di 500.000 chip Nvidia all’anno, di cui l’80% andrà a servire clienti americani e il 20% resterà per uso locale.

L’Arabia Saudita, attraverso HUMAIN, sta costruendo data center con capacità prevista di 500 megawatt e centinaia di migliaia di chip Nvidia. Il primo deployment include 18.000 chip di ultima generazione per un supercomputer saudita. Google Cloud e il fondo sovrano PIF hanno annunciato una partnership da 10 miliardi di dollari per un hub AI globale.

Il Qatar ha lanciato Qai con 20 miliardi di dollari in partnership con Brookfield, più un investimento separato in Anthropic.

Non sono progetti di sovranità nel senso europeo del termine. Sono progetti di posizionamento: i paesi del Golfo vogliono diventare hub infrastrutturali per l’AI globale, fornendo compute a basso costo (grazie al capitale dei fondi sovrani) a paesi emergenti che non possono permettersi infrastruttura propria. Come nota Foreign Policy, “l’essenza della sovereign AI per il Golfo è fornire backend compute per paesi che vogliono usare AI ma non hanno capacità di training e deployment proprie”.

Il rischio, dal punto di vista statunitense, è la diversione di GPU verso la Cina. Ma i deal recenti includono clausole che legano il compute del Golfo allo “stack americano”: i chip restano sotto controllo di hyperscaler USA, i modelli sono americani, le regole operative sono concordate bilateralmente.

L’Europa: tre strade, nessuna scelta

L’Europa sta perseguendo simultaneamente approcci diversi senza una strategia unificata. Il risultato è frammentazione.

I campioni nazionali

Mistral AI (Francia) è il caso più visibile. Fondata nel 2023 da ex-ricercatori di Google DeepMind e Meta, ha raccolto oltre 2,8 miliardi di euro, incluso un round da 1,7 miliardi nel settembre 2025 guidato da ASML e Nvidia. I suoi modelli open-weight sono competitivi con i frontier americani su alcuni benchmark (Mistral Large 2 è nono globale nell’uso di tool per agent). La strategia è esplicita: modelli aperti che permettono customizzazione locale, allineamento con le regole europee (AI Act), deployment on-premise o edge.

Ma Mistral ha investitori americani (a16z, Lightspeed) e partnership con Microsoft. Quanto è “sovrana” un’azienda che dipende da venture capital americano per crescere?

Aleph Alpha (Germania) ha scelto un posizionamento diverso: meno performance frontier, più explainability e deployment in settori regolamentati. La piattaforma PhariaAI supporta deployment on-premise, air-gapped, ibridi. I clienti includono l’Agenzia Federale per l’Impiego tedesca e BWI (IT della Bundeswehr). Ha raccolto circa 500 milioni di euro, quasi interamente da investitori europei (Bosch Ventures, Schwarz Group, SAP).

Il trade-off è evidente: Aleph Alpha è più “sovrana” nel funding ma meno competitiva nei benchmark. Se il gap con i modelli frontier si allarga troppo, le aziende europee potrebbero essere costrette a scegliere tra compliance e competitività.

Le partnership istituzionali

A novembre 2025, Francia e Germania hanno annunciato una partnership con Mistral e SAP per sviluppare “cloud e AI sovrani” per il settore pubblico. SAP ha lanciato l’EU AI Cloud, integrando modelli di Mistral e Aleph Alpha nel suo Business Technology Platform con garanzie di data residency europea.

Queste iniziative rispondono a esigenze reali. Il settore pubblico europeo ha requisiti di compliance che rendono problematico l’uso di modelli americani su infrastruttura americana. Ma restano progetti verticali, non una strategia industriale.

GAIA-X e l’infrastruttura federata

GAIA-X, lanciato nel 2020 da Francia e Germania, doveva essere “l’Airbus del cloud”, un’infrastruttura federata europea alternativa agli hyperscaler americani. A fine 2025, il bilancio è misto.

Sul lato positivo, il framework esiste. Ci sono oltre 180 data space settoriali in sviluppo. Il Trust Framework 3.0 (“Danube”) è stato rilasciato. Progetti come Catena-X (automotive) dimostrano che la condivisione dati basata su standard europei è tecnicamente fattibile.

Sul lato negativo, GAIA-X non è un cloud provider. Non compete con AWS, Azure o Google Cloud. Il mercato cloud europeo resta dominato al 70% da hyperscaler americani. Alcuni membri fondatori europei hanno lasciato il progetto. Il co-fondatore di NextCloud ha accusato GAIA-X di essere stato “diluito” e “sabotato dall’interno” dagli hyperscaler stessi, che sono membri dell’associazione.

Un’analisi di STL Partners è brutale: “GAIA-X resta più un simbolo politico che un disruptor di mercato. Realisticamente, colmare il gap richiederebbe investimenti coordinati EU nell’ordine di 500-700 miliardi di euro, una scala non attualmente all’orizzonte.”

L’intersezione con l’AI Act

L’EU AI Act, entrato progressivamente in vigore dal febbraio 2025, crea obblighi che si intersecano con la sovranità AI in modi specifici.

Sul fronte data residency e training data, l’AI Act non impone esplicitamente che i dati restino in Europa, ma le regole sulla trasparenza dei dati di training (Template for public summary, rilasciato a luglio 2025) richiedono disclosure dettagliata delle fonti. Per sistemi ad alto rischio, le valutazioni d’impatto sui diritti fondamentali possono richiedere accesso ai dataset, cosa difficile se sono su server americani soggetti a leggi americane.

Per quanto riguarda GPAI e rischio sistemico, i provider di General-Purpose AI con rischio sistemico (definito come modelli addestrati con compute superiore a 10^25 FLOP) devono rispettare obblighi aggiuntivi di sicurezza, testing e incident reporting. I principali modelli frontier (GPT-4, Claude, Gemini) rientrano in questa categoria. Il Code of Practice rilasciato a luglio 2025 e firmato da Mistral, Aleph Alpha, OpenAI, IBM e altri offre un framework volontario di compliance.

C’è poi la questione audit e accesso: l’AI Act prevede che le autorità nazionali possano richiedere accesso a modelli per verifiche. Per modelli sviluppati e hostati fuori dall’UE, questo crea tensioni giurisdizionali irrisolte.

Il Digital Omnibus, proposto dalla Commissione a novembre 2025, potrebbe cambiare significativamente il quadro. Alcune parti dell’AI Act e del GDPR potrebbero essere ammorbidite per ridurre il carico di compliance sulle PMI. I critici sostengono che questo indebolisce la posizione europea proprio mentre la sovranità AI diventa critica. Come nota un analista: “Se l’Europa ha la migliore regolamentazione ma nessuna azienda europea, non ha vinto molto.”

Il rischio della bolla infrastrutturale

James Landay, co-direttore di Stanford HAI, nelle sue previsioni per il 2026 ha inserito una nota di cautela sugli investimenti in data center AI: “A un certo punto, non puoi impegnare tutti i soldi del mondo su una cosa sola. Sembra una bolla molto speculativa.”

I numeri sono impressionanti. I quattro hyperscaler americani (Amazon, Microsoft, Google, Meta) spenderanno circa 325 miliardi di dollari in capex infrastrutturale nel solo 2025, più dell’intero PIL di paesi come Finlandia o Cile. Il Golfo sta aggiungendo altri 100+ miliardi. La capacità data center globale sta crescendo del 20% annuo.

Ma la domanda effettiva di compute AI è ancora concentrata in pochi use case: training di modelli frontier (dominato da 5-6 lab), inferenza per chatbot consumer (dominata da OpenAI e pochi altri), e applicazioni enterprise ancora in fase sperimentale (il 42% dei progetti viene abbandonato, come documentato altrove).

Se la domanda non cresce alla velocità dell’offerta, chi ha investito miliardi in GPU cluster potrebbe trovarsi con capacità inutilizzata. I paesi che hanno scommesso sulla sovranità infrastrutturale (UAE, Arabia Saudita, ma anche le iniziative europee) potrebbero scoprire di aver costruito cattedrali nel deserto.

Implicazioni per le decisioni aziendali

Per CTO, legal e compliance officer in Europa, la frammentazione della strategia di sovranità crea incertezza operativa. Alcune considerazioni pratiche.

Il punto di partenza è mappare le dipendenze esistenti: quali modelli AI usa l’organizzazione? Dove sono hostati? Quali dati vengono inviati a provider terzi? Questa mappatura è prerequisito per qualsiasi strategia di sovranità.

Serve poi distinguere requisiti reali da requisiti percepiti. Non tutti i workload richiedono sovranità piena. Per applicazioni non critiche senza dati personali sensibili, la compliance con AI Act e GDPR può essere sufficiente anche usando provider americani. Per settori regolamentati (sanità, finanza, difesa, pubblica amministrazione), i requisiti sono più stringenti.

C’è da considerare il vendor lock-in. Le soluzioni “sovrane” europee (Mistral via SAP, Aleph Alpha per enterprise) offrono oggi performance inferiori ai frontier americani. Adottarle crea dipendenza da un ecosistema più piccolo. Se il gap si allarga, migrare sarà costoso.

L’evoluzione normativa va monitorata con attenzione. Il Digital Omnibus potrebbe cambiare significativamente gli obblighi AI Act. Le guidelines della Commissione vengono aggiornate regolarmente. La compliance di oggi potrebbe non bastare domani, oppure potrebbe risultare eccessiva se le regole vengono ammorbidite.

Vale la pena infine considerare modelli ibridi: alcuni workload su infrastruttura sovrana (dati sensibili, applicazioni critiche), altri su hyperscaler (scale, performance, costo). Questa architettura è più complessa da gestire ma può bilanciare i rischi.

Una scelta inevitabile

L’Europa non può perseguire simultaneamente tre strategie incompatibili: campioni nazionali che competono tra loro, infrastruttura federata che non scala, e dipendenza de facto dagli hyperscaler americani.

A un certo punto sarà necessario scegliere. Il modello del Golfo (infrastruttura massiccia, capitale sovrano, partnership con provider americani) richiede risorse che l’Europa potrebbe mobilitare ma non sta mobilitando. Il modello dei campioni nazionali (Mistral, Aleph Alpha, DeepL) produce eccellenza puntuale ma non massa critica. Il modello GAIA-X (standard e interoperabilità) è necessario ma non sufficiente.

Per i decisori europei, pubblici e privati, la domanda non è se la sovranità AI sia importante. Lo è. La domanda è quale livello di sovranità è realisticamente raggiungibile, a quale costo, e con quali compromessi. Finché questa domanda resta senza risposta chiara, le aziende europee navigheranno in un ambiente di incertezza strutturale, costrette a scommettere su strategie che potrebbero rivelarsi obsolete prima di essere implementate.

Fonti

• Atlantic Council, “Sovereign Remedies: Between AI Autonomy and Control”, aprile 2025
• RAND Corporation, “At the Paris AI Summit, Europe Charts Its Course”, febbraio 2025
• Carnegie Endowment, “The EU’s AI Power Play: Between Deregulation and Innovation”, maggio 2025
• Lawfare, “Sovereign AI in a Hybrid World: National Strategies and Policy Responses”, novembre 2024
• NVIDIA Blog, “What is Sovereign AI?”, luglio 2025
• Foreign Policy, “U.S.-China AI Competition Needs Data Centers in UAE, Saudi Arabia”, luglio 2025
• Fortune, “Saudi Arabia wants to build its post-oil future with massive AI data centers”, maggio 2025
• Semafor, “Qatar launches $20B AI push”, dicembre 2025
• Tech.eu, “Europe’s AI ecosystem: Rapid growth and rising global ambitions”, novembre 2025
• DirectIndustry, “Why Europe Needs a Sovereign AI”, novembre 2025
• STL Partners, “Sovereign AI: What it is, country playbooks & data centre strategy”, settembre 2025
• IAPP, “Global AI Governance Law and Policy: EU”, 2025
• European Commission, “AI Act implementation updates”, 2025
• Polytechnique Insights, “Gaia-X: the bid for a sovereign European cloud”, giugno 2025