La sovranità IA non è residenza dei dati. Sono megawatt, fibra ottica e temperatura a bulbo umido. (1/3)

Questo è il post 1 di 3 di una serie sul paper AI Infrastructure Sovereignty di Sergio Cruzes. La parte 2 copre la Feasible Sovereign Operating Region; la parte 3 copre l'architettura LLM-come-consulente.

Qualche settimana fa Sergio Cruzes (Ciena) ha messo su arXiv un paper intitolato AI Infrastructure Sovereignty (2602.10900v4). È il tipo di paper che non diventa virale su LinkedIn perché non promette a nessuno un aumento di produttività del 10x, ma dovrebbe essere letto da chiunque firmi una "strategia di sovranità IA" quest'anno. La sua tesi centrale è semplice e scomoda: la sovranità IA non è più un problema software o legale. È un problema di infrastruttura. Le clausole di localizzazione dei dati, le region cloud regionali e la postura GDPR sono necessarie ma molto lontane dall'essere sufficienti. La sovranità reale vive nei megawatt, nei tracciati di fibra ottica e nella temperatura a bulbo umido fuori dalla tua data hall.

Da dove lavoro io — costruendo DevOps e platform engineering per aziende che devono difendere il loro stack IA davanti a un regolatore — questa riformulazione è in ritardo, e la maggior parte delle roadmap di sovranità pubbliche che ho rivisto negli ultimi dodici mesi continua a operare un livello troppo in alto.

Sovranità legale vs sovranità operativa

Il paper introduce una distinzione che dovrebbe diventare vocabolario standard:

• Sovranità legale è il livello che tutti già capiscono: giurisdizione, compliance, protezioni IP, framework di localizzazione dei dati. GDPR, EU AI Act, CLOUD Act, etichette tipo SecNumCloud. Qui vivono avvocati e procurement.
• Sovranità operativa è "la capacità pratica di osservare lo stato del sistema, prendere decisioni in base alle condizioni locali, validare quelle decisioni e agire entro politiche definite e limiti fisici." Qui vivono ingegneri e operatori. O meglio, dovrebbero vivere. Nella maggior parte delle conversazioni sulla sovranità, questo livello manca.

I due livelli non sono la stessa cosa, e uno senza l'altro è facciata. Il controllo legale senza capacità operativa è nominale. Puoi tenere il contratto, gli audit report e la clausola di residenza dei dati e continuare a dipendere dall'hardware di qualcun altro, dalla rete ottica di qualcun altro e dal PPA energetico di qualcun altro per far girare il sistema. Quando quel qualcun altro è vincolato da controlli sulle esportazioni, sanzioni o una decisione unilaterale di piattaforma, la tua sovranità evapora a prescindere da cosa dica il contratto.

Questa è la parte che la maggior parte delle conversazioni su "cloud sovrano europeo" salta elegantemente. Discutiamo dove vivono i byte e ignoriamo da dove arrivano i joule.

Cosa significa davvero "infrastruttura" nel paper

Cruzes è insolitamente concreto per un paper sulla sovranità. I tre livelli che tratta come substrato non sono astrazioni:

1. Data center IA — rack che spingono oltre i 20–30 kW (il soffitto del raffreddamento ad aria) verso il liquid cooling come standard. Cluster di training che richiedono da decine a centinaia di megawatt per sito. Potenza che non disegna una curva piatta ma fa picchi durante le operazioni collettive nella scala millisecondo-secondo. Niente di tutto questo è esotico nel mondo hyperscaler; quasi nulla di tutto questo è controllato localmente nei cloud sovrani europei che ho rivisto.

2. Reti ottiche — la parte che la maggior parte delle discussioni sulla sovranità centrate sul software ignora completamente. La velocità della luce impone un pavimento duro di ~5 ms per 1.000 km. I cluster di training tollerano circa 1 ms di latenza di collective-comm, che si traduce in un raggio geografico di circa 100 km. L'inference è più tollerante ma deve comunque stare vicina alla domanda. I cavi sottomarini — quelli che portano la maggior parte del traffico IA intercontinentale — sono "difficili da riparare. Le interruzioni possono durare settimane." La sovranità di un tracciato in fibra non è una clausola contrattuale; è il diritto di passaggio fisico e la nave che ti serve per ripararlo.

3. Sistemi energetici — capacità di rete, intensità di carbonio, acqua per il raffreddamento. Il paper propone una Feasible Sovereign Operating Region (FSOR): l'intersezione in cui disponibilità energetica, intensità di carbonio e budget idrico possono essere soddisfatti congiuntamente. Tornerò sulla FSOR nel prossimo post perché merita una trattazione propria. Il punto qui è strutturale: una regione senza sufficiente headroom di rete, con un mix energetico ad alta carbonio o con stress idrico stagionale non è sovrana per l'IA di frontiera indipendentemente da quanto buone siano le sue leggi sulla protezione dei dati.

Una volta messa così, non puoi seriamente rivendicare la sovranità per un workload IA che gira su acceleratori importati, su una rete ottica gestita da un terzo, traendo potenza da una rete che non controlli, raffreddato con acqua di cui non determini il prezzo. Puoi rivendicare qualcosa, ma non sovranità in senso operativo.

Perché la narrativa cloud-region si rompe qui

Se prendi le definizioni di Cruzes sul serio, la narrativa dominante della sovranità europea — "avremo region cloud sovrane gestite da entità UE" — risolve al massimo uno dei tre livelli, e probabilmente meno della metà di quello. Una region sovrana implementata su:

• Acceleratori importati sotto regimi di controllo dell'export stranieri,
• Capacità ottica affittata a provider di transito con sede altrove,
• PPA energetici senza telemetria operativa sulla rete,
• Acqua di raffreddamento da un bacino senza stewardship locale,

è una region in senso legale e un tenant in senso operativo. Il supervisore accetterà il livello legale. La fisica no.

Non sto dicendo che lo sforzo cloud-region sia sbagliato. Sto dicendo che risolve la parte del problema che gli avvocati possono verificare e lascia intatta la parte con cui ingegneri e operatori devono convivere. La prima volta che un punto di controllo transfrontaliero — sanzioni sull'export, un cambio di licenza di un vendor di piattaforma, un'interruzione di fibra sottomarina — colpirà la region, il divario tra "legalmente sovrana" e "operativamente sovrana" sarà l'unica cosa che conta.

Il livello della telemetria è il vero livello della sovranità

L'affermazione tecnica più sottovalutata del paper è questa: la sovranità operativa dipende dalla fusione di telemetria cross-layer, e l'entità che esegue quella fusione detiene le vere chiavi.

Oggi ci sono quattro ecosistemi protocollari distinti che devono essere uniti per produrre una rappresentazione di stato unificata di un data center IA:

Dominio	Protocolli	Maturità
Reti ottiche	OpenConfig / gNMI	Massima
Calcolo / power	Redfish, IPMI, API BMC vendor	Eterogenea
Cooling / facilities	BACnet, Modbus	Facilities-grade, non real-time
Sostenibilità di rete	WattTime, Electricity Maps (~5 min)	Commerciale, esterna

Questi quattro non sono stati progettati per parlarsi. Emettono schemi diversi, cadenze diverse, garanzie di freschezza diverse. Unirli in un singolo vettore di stato — Cruzes lo chiama θ(t) — non è lavoro commodity. È il lavoro che determina se puoi rilevare un guasto a cascata (picco di potenza → evento termico → migrazione di workload → congestione di rete) prima che ti sorprenda, o se lo leggi nel post-mortem.

Ed ecco il punto chiave della sovranità operativa: chiunque possieda il livello di fusione della telemetria possiede la vera superficie di controllo. Se deleghi quel lavoro a una piattaforma esterna — la "AI infrastructure suite" di un hyperscaler, il prodotto di observability bundled di un vendor — hai delegato anche la visibilità operativa. La tua dashboard dice "tutto verde". Non sai più cosa la farebbe diventare rossa, a quali condizioni o con quale latenza.

Lo metterei più diretto del paper: la fusione di telemetria è il nuovo sistema di registro dell'infrastruttura IA, e la maggior parte degli operatori europei non ce l'ha. Hanno dashboard costruite sulla pipeline di qualcun altro. Va bene finché non va più.

Cosa significa per un cliente regolamentato quest'anno

Per il tipo di cliente con cui lavoro — banche, sanità, energia, settore pubblico — tradurre questo in una postura pratica significa abbandonare un paio di assunzioni comode e adottarne tre scomode:

1. Abbandonare l'assunzione che la residenza dei dati sia la conversazione sulla sovranità. È il livello più facile, quello che il tuo DPO sa già spiegare, e quello che un avversario competente o un incidente regolatorio aggira più velocemente. Sta nella risposta, non come tutta la risposta.

2. Adottare l'assunzione che serva un inventario delle dipendenze fisiche. Per ogni workload IA in produzione o pianificato: quali acceleratori (e sotto quale regime di export), quali tracciati ottici (e di chi è il diritto di passaggio), quale fonte energetica (e di chi è il PPA), quale risorsa di raffreddamento (e di chi sono i diritti sull'acqua). La maggior parte dei team non sa rispondere oggi per il proprio stack esistente. Il primo lavoro è l'inventario, non l'architettura.

3. Adottare l'assunzione che la fusione di telemetria sia tua responsabilità. Anche se operi sopra il ferro di qualcun altro, puoi — e nei settori regolamentati dovresti — possedere il livello che fonde i tuoi segnali operativi in una rappresentazione di stato tua, su cui ragionare, fare audit e presentare a un supervisore senza traduzione. Senza quello, i tuoi report di incidente saranno sempre scritti nel vocabolario del tuo vendor, sui tempi del tuo vendor.

4. Riclassificare il sistema, non il modello. Continuo a ripeterlo, anche nella mia lettura del rapporto McKinsey sulla fiducia in IA 2026: il regolatore vuole classificato il sistema sociotecnico completo, che ora include esplicitamente il livello fisico. Il fascicolo di gestione del rischio dell'Articolo 9 per un sistema IA ad alto rischio che non riconosce le dipendenze energetiche, ottiche e di raffreddamento è incompleto per la logica stessa del paper.

5. Accettare che la sovranità sia uno spettro, non un binario. Cruzes è chiaro: nessuna regione raggiunge sovranità assoluta. Tutte esistono da qualche parte su una curva definita da quali livelli sono controllati localmente e quali dipendenze esterne sono accettate. La roadmap di sovranità onesta è quella che nomina le dipendenze e le prezza, non quella che pretende di rimuoverle tutte.

La parte di cui sono critico nell'hype IA sulla sovranità

Sono pubblicamente positivo su LLM e sistemi agentici in produzione — li deploy, li fatturo, i miei clienti li pagano, il mio tempo è "investito" in essi nel senso più letterale. Non sono la persona da convincere che l'IA è reale.

Detto questo, il discorso pubblico sulla sovranità IA oggi ha una modalità di fallimento specifica che il paper rende leggibile: tratta la sovranità come un problema di contenuto e non come un problema di substrato. Il pitch è "i tuoi dati restano nel paese," e il corollario non detto è "tutto sotto i tuoi dati è problema di qualcun altro." Cruzes mostra che il substrato non è problema di qualcun altro; è il problema, perché il substrato è ciò che un attore esterno può effettivamente togliere.

La versione hype della sovranità IA è un modello addestrato su dati locali, ospitato in una region cloud locale, marketato sotto bandiera locale, che gira sullo stesso silicio importato e sulla stessa capacità ottica a lunga distanza dello stack di tutti gli altri. La versione del paper della sovranità IA è lo stesso modello, ma con la domanda sotto quali vincoli fisici posso continuare a operare se le mie dipendenze esterne vengono revocate? risposta onestamente. La prima versione è una slide. La seconda è un runbook.

Se il tuo programma di sovranità sa rispondere alla slide e non sa rispondere al runbook, sei esattamente dove sta il resto dell'industria. Il lavoro di quest'anno è invertire quei due stati.

Cosa metterei sulla roadmap di piattaforma questo trimestre

Per un team di piattaforma o infrastruttura in un settore regolamentato, tre mosse concrete prima del prossimo board update:

1. Mappare lo stack di dipendenze fisiche per ogni workload IA in produzione. Una tabella, quattro colonne: famiglia di acceleratori + regime regolatorio, tracciato ottico + operatore, fonte energetica + termini PPA, risorsa di raffreddamento + stewardship locale. La tabella non sarà bella. Quello è il punto.

2. Avviare una baseline di telemetry-fusion, anche rozza. Scegli un singolo workload, tira OpenConfig dal tuo livello ottico, Redfish dal compute, quello che riesci dalle facilities e un feed commerciale di intensità di carbonio. Costruisci un θ(t) a risoluzione di 60 secondi per quel workload. Scoprirai una quantità imbarazzante di unknown unknowns. Quello è il valore dell'esercizio.

3. Scrivere un memo di sovranità di una pagina che distingua sovranità legale e operativa per il tuo CFO e il tuo supervisore. Anche se questo trimestre riesci a consegnare solo la colonna legale, possedere il vocabolario mantiene onesta la conversazione di comitato. Preferisco entrare in una riunione con un supervisore dicendo "controlliamo i livelli 1 e 2, dipendiamo dal vendor X per i livelli 3 e 4, ecco la contingenza" piuttosto che entrare rivendicando una sovranità che non ho.

La linea che traccio

L'inquadramento del paper — legale vs operativo, con la fisica come vincolo cogente — è quello giusto da tenere internamente anche quando la versione marketing della sovranità è quella citata esternamente. L'IA è reale, il deployment accelera, il valore è genuino. Niente di tutto questo cambia il fatto che il livello a cui la sovranità si decide davvero si è spostato sotto la maggior parte del vocabolario corrente dell'industria.

Se il tuo programma di sovranità quest'anno termina ancora alla clausola di residenza dei dati, non sei in errore. Sei solo un livello troppo in alto. Il lavoro interessante — e il lavoro a cui un regolatore terrà nei prossimi dodici mesi — sta succedendo sotto la tua dashboard.

---

Fonti:

• Sergio Cruzes (Ciena Corporation), AI Infrastructure Sovereignty, arXiv:2602.10900v4, aprile 2026. arxiv.org

Stai costruendo infrastruttura IA che deve difendersi davanti a un regolatore e non sei sicuro di dove termini davvero il tuo programma di sovranità? Parla con un CTO — ti aiutiamo a separare il livello legale da quello operativo prima che lo faccia qualcun altro.