La sobirania d'IA no és residència de dades. Són megawatts, fibra i temperatura de bulb humit. (1/3)

Aquest és el post 1 de 3 d'una sèrie sobre el paper d'AI Infrastructure Sovereignty de Sergio Cruzes. La part 2 tracta de la Feasible Sovereign Operating Region; la part 3 tracta de l'arquitectura LLM-com-a-assessor.

Fa unes setmanes Sergio Cruzes (Ciena) va publicar a arXiv un paper titulat AI Infrastructure Sovereignty (2602.10900v4). És d'aquests papers que no es fan virals a LinkedIn perquè no prometen a ningú un increment de productivitat 10x, però l'hauria de llegir qualsevol persona que signi una "estratègia de sobirania d'IA" aquest any. La seva tesi central és simple i incòmoda: la sobirania d'IA ja no és un problema de software ni un problema legal. És un problema d'infraestructura. Les clàusules de localització de dades, les regions cloud regionals i la postura GDPR són necessàries però ni de bon tros suficients. La sobirania real viu en megawatts, rutes de fibra i la temperatura de bulb humit fora de la teva sala de servidors.

Des d'on jo treballo — construint DevOps i platform engineering per a empreses que han de defensar la seva pila d'IA davant d'un regulador — aquest reenquadrament és tardà, i la majoria de roadmaps públics de sobirania que he revisat els últims dotze mesos encara operen una capa massa amunt.

Sobirania legal vs sobirania operativa

El paper fa una distinció que hauria d'esdevenir vocabulari estàndard:

• Sobirania legal és la capa que tothom ja entén: jurisdicció, compliment, proteccions d'IP, marcs de localització de dades. GDPR, l'EU AI Act, el CLOUD Act, etiquetes tipus SecNumCloud. Advocats i procurement viuen aquí.
• Sobirania operativa és "la capacitat pràctica d'observar l'estat del sistema, prendre decisions basades en condicions locals, validar aquestes decisions i actuar dins de polítiques definides i límits físics." Enginyers i operadors viuen aquí. O més aviat, haurien de viure aquí. En la majoria de converses de sobirania, aquesta capa hi falta.

Les dues capes no són el mateix, i l'una sense l'altra és decoració. Control legal sense capacitat operativa és nominal. Pots tenir el contracte, els informes d'auditoria i la clàusula de residència de dades i tot i així dependre del hardware d'algú altre, de la xarxa òptica d'algú altre i del power purchase agreement d'algú altre per fer funcionar el sistema. Quan aquest algú altre està limitat per controls d'exportació, sancions, o una decisió unilateral de plataforma, la teva sobirania s'evapora independentment del que digui el contracte.

Aquesta és la part que la majoria de converses de "cloud sobirà europeu" se salten elegantment. Discutim on viuen els bytes i ignorem d'on vénen els joules.

Què vol dir "infraestructura" exactament al paper

Cruzes és inusualment concret per a un paper de sobirania. Les tres capes que tracta com a substrat no són abstraccions:

1. Data centers d'IA — racks que passen dels 20–30 kW (el sostre de la refrigeració per aire) cap a refrigeració líquida com a estàndard. Clústers d'entrenament que demanen desenes a centenars de megawatts per site. Potència que no dibuixa una corba plana sinó que té pics durant operacions col·lectives a escala de mil·lisegons a segons. Res d'això és exòtic al món dels hyperscalers; pràcticament res no està controlat localment als clouds sobirans europeus que he revisat.

2. Xarxes òptiques — la part que la majoria de discussions de sobirania centrades en software ignoren completament. La velocitat de la llum imposa un terra dur de ~5 ms per 1.000 km. Els clústers d'entrenament toleren al voltant d'1 ms de latència de comunicació col·lectiva, que es tradueix en un radi geogràfic d'uns 100 km. La inferència és més permissiva però encara ha de seure a prop de la demanda. Els cables submarins — els que porten la major part del trànsit intercontinental d'IA — són "difícils de reparar. Les interrupcions poden durar setmanes." La sobirania d'un camí de fibra no és una clàusula contractual; és el dret de pas físic i el vaixell que necessites per arreglar-la.

3. Sistemes energètics — capacitat de xarxa, intensitat de carboni, aigua per refrigeració. El paper proposa una Feasible Sovereign Operating Region (FSOR): la intersecció on disponibilitat d'energia, intensitat de carboni i pressupost d'aigua es poden satisfer conjuntament. Tornaré a l'FSOR al pròxim post perquè mereix un tractament propi. El que importa aquí és estructural: una regió sense suficient marge de xarxa, amb una mescla energètica d'alt carboni o amb estrès hídric estacional no és sobirana per a IA frontera per molt bones que siguin les seves lleis de protecció de dades.

Un cop ho enquadres així, no pots reclamar seriosament sobirania per a un workload d'IA executant-se sobre acceleradors importats, sobre una xarxa òptica operada per un tercer, traient energia d'una xarxa que no controles, refrigerat amb aigua que no preues. Pots reclamar alguna cosa, però no sobirania en el sentit operatiu.

Per què la narrativa de cloud-region es trenca aquí

Si t'agafes seriosament les definicions de Cruzes, la narrativa europea dominant de sobirania — "tindrem regions cloud sobiranes operades per entitats UE" — resol com a molt una de tres capes, i discutiblement menys de la meitat d'aquella. Una regió sobirana implementada sobre:

• Acceleradors importats sota règims estrangers de control d'exportació,
• Capacitat òptica llogada a proveïdors de trànsit amb seu en una altra banda,
• Power purchase agreements sense telemetria operativa cap a la xarxa,
• Aigua de refrigeració d'una conca sense administració local,

és una regió en sentit legal i un llogater en sentit operatiu. El supervisor acceptarà la capa legal. La física no.

No estic dient que l'esforç de cloud-region estigui equivocat. Estic dient que resol la part del problema que els advocats poden verificar i deixa intacta la part que enginyers i operadors han de viure. La primera vegada que un punt de control transfronterer — sancions d'exportació, un canvi de llicència d'un proveïdor de plataforma, una caiguda de fibra submarina — toqui la regió, la distància entre "legalment sobirà" i "operativament sobirà" serà l'única cosa que importarà.

La capa de telemetria és la capa real de sobirania

La reclamació tècnica més infravalorada del paper és aquesta: la sobirania operativa depèn de la fusió de telemetria cross-layer, i l'entitat que executa aquesta fusió té les claus reals.

Avui hi ha quatre ecosistemes de protocols diferenciats que cal unir per produir una representació d'estat unificada d'un data center d'IA:

Domini	Protocols	Maduresa
Xarxes òptiques	OpenConfig / gNMI	Més alta
Compute / power	Redfish, IPMI, APIs BMC de proveïdor	Heterogènia
Refrigeració / instal·lacions	BACnet, Modbus	Grau facilities, no temps real
Sostenibilitat de xarxa	WattTime, Electricity Maps (~5 min)	Comercial, externa

Aquests quatre no es van dissenyar per parlar entre ells. Emeten esquemes diferents, cadències diferents, garanties de frescor diferents. Unir-los en un vector d'estat únic — Cruzes en diu θ(t) — no és feina de commodity. És la feina que determina si pots detectar una fallida en cascada (pic de potència → event tèrmic → migració de workload → congestió de xarxa) abans que et sorprengui, o si te n'assabentes al post-mortem.

I aquí ve el cop de gràcia de la sobirania operativa: qui posseeix la capa de fusió de telemetria, posseeix la superfície de control real. Si delegues aquesta feina a una plataforma externa — una "AI infrastructure suite" d'un hyperscaler, un producte d'observabilitat empaquetat d'un proveïdor — has delegat la visibilitat operativa juntament amb ella. El teu dashboard diu "tot verd." Ja no saps què el posaria vermell, sota les condicions de qui, ni amb quina latència.

Ho diria més contundent que el paper: la fusió de telemetria és el nou system of record per a la infraestructura d'IA, i la majoria d'operadors europeus no en tenen un. Tenen dashboards construïts sobre el pipeline d'algú altre. Que està bé fins que no.

Què significa això per a un client regulat aquest any

Per al tipus de client amb qui treballo — banca, salut, energia, sector públic — traduir això a una postura pràctica vol dir abandonar un parell de suposicions còmodes i adoptar tres d'incòmodes:

1. Abandona la suposició que la residència de dades és la conversa de sobirania. És la capa més fàcil, la que el teu DPO ja sap explicar, i la que un adversari competent o un accident regulatori salta més de pressa. Pertoca a la resposta, no com a resposta sencera.

2. Adopta la suposició que necessites un inventari de dependències físiques. Per a cada workload d'IA en producció o planificat: quins acceleradors (i sota quin règim d'exportació), quins camins òptics (i de qui és el dret de pas), quina font d'energia (i de qui és el PPA), quin recurs de refrigeració (i de qui són els drets d'aigua). La majoria d'equips no poden respondre això per a la seva pila actual avui. La primera feina és l'inventari, no l'arquitectura.

3. Adopta la suposició que la fusió de telemetria és responsabilitat teva. Encara que operis sobre el ferro d'algú altre, pots — i als sectors regulats hauries de — posseir la capa que fusiona els teus senyals operatius en una representació d'estat sobre la qual tu puguis raonar, auditar i presentar a un supervisor sense traducció. Sense això, els teus informes d'incident sempre s'escriuran en el vocabulari del teu proveïdor, en el calendari del teu proveïdor.

4. Reclassifica el sistema, no el model. No paro de dir-ho, incloent-hi a la meva lectura de l'informe McKinsey 2026 sobre confiança en IA: el regulador vol classificar el sistema sociotècnic complet, que ara inclou explícitament la capa física. El fitxer de gestió de risc de l'Article 9 per a un sistema d'IA d'alt risc que no reconegui les dependències d'energia, òptiques i de refrigeració és incomplet per la pròpia lògica del paper.

5. Accepta que la sobirania és un espectre, no un binari. Cruzes és clar en això: cap regió aconsegueix sobirania absoluta. Totes existeixen en algun punt d'una corba definida per quines capes es controlen localment i quines dependències externes s'accepten. El roadmap de sobirania honest és el que anomena les dependències i les preua, no el que diu eliminar-les totes.

La part de la qual sóc crític en el hype d'IA al voltant de la sobirania

Estic on the record com a positiu envers els LLMs i els sistemes agèntics en producció — els desplego, els facturo, els meus clients hi paguen, el meu propi temps hi està "invertit" en el sentit més literal. No sóc la persona que cal convèncer que la IA és real.

Dit això, el discurs públic de sobirania al voltant de la IA avui té un mode de fallida específic que el paper fa llegible: tracta la sobirania com un problema de contingut i no com un problema de substrat. El pitch és "les teves dades es queden al país," i el corol·lari implícit és "tot el que hi ha sota les teves dades és problema d'algú altre." Cruzes demostra que el substrat no és problema d'algú altre; és el problema, perquè el substrat és el que un actor extern realment et pot retirar.

La versió hype de la IA sobirana és un model entrenat sobre dades locals, allotjat en una regió cloud local, comercialitzat sota una bandera local, executant-se sobre el mateix silici importat i la mateixa capacitat òptica de llarga distància que la pila de tothom. La versió del paper de la IA sobirana és el mateix model, però amb la pregunta sota quines restriccions físiques puc seguir operant si les meves dependències externes són revocades? respondre honestament. La primera versió és una diapositiva. La segona és un runbook.

Si el teu programa de sobirania pot respondre la diapositiva i no pot respondre el runbook, ets exactament on és la resta de la indústria. La feina d'aquest any és invertir aquests dos estats.

Què posaria al roadmap de plataforma aquest trimestre

Per a un equip de plataforma o d'infraestructura en un sector regulat, tres moviments concrets abans del proper board update:

1. Mapeja la pila de dependència física per a cada workload d'IA en producció. Una taula, quatre columnes: família d'accelerador + règim regulatori, camí òptic + operador, font d'energia + termes del PPA, recurs de refrigeració + administració local. La taula no serà bonica. Aquest és el punt.

2. Comença una línia base de fusió de telemetria, encara que sigui rudimentària. Tria un sol workload, treu OpenConfig de la capa òptica, Redfish del compute, el que puguis aconseguir de facilities, i un feed comercial de intensitat de carboni. Construeix una θ(t) a 60 segons de resolució per a aquell workload. Descobriràs una quantitat vergonyosa d'unknown unknowns. Aquest és el valor de l'exercici.

3. Escriu un memo d'una pàgina sobre sobirania que distingeixi sobirania legal d'operativa per al teu CFO i el teu supervisor. Encara que tot el que puguis lliurar aquest trimestre sigui la columna legal, posseir el vocabulari manté la conversa de board honesta. M'estimo més entrar a una reunió amb un supervisor dient "controlem les capes 1 i 2, depenem del proveïdor X per a les capes 3 i 4, aquí teniu la contingència" que entrar reclamant una sobirania que no tinc.

La línia que dibuixo

L'enquadrament del paper — legal vs operativa, amb la física com a restricció vinculant — és la correcta per mantenir internament fins i tot quan la versió de màrqueting de la sobirania és la que se cita externament. La IA és real, el desplegament s'està accelerant, el valor és genuí. Res d'això no canvia que la capa on la sobirania realment es decideix s'ha mogut sota el vocabulari actual de la majoria de la indústria.

Si el teu programa de sobirania aquest any encara acaba a la clàusula de residència de dades, no estàs equivocat. Només estàs una capa massa amunt. La feina interessant — i la feina que un regulador trobarà important dins dels propers dotze mesos — passa per sota del teu dashboard.

---

Fonts:

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

Construint infraestructura d'IA que ha de defensar-se davant d'un regulador i no segur d'on acaba realment el teu programa de sobirania? Parla amb un CTO — t'ajudem a separar la capa legal de l'operativa abans que ho faci algú altre.