La soberanía de la IA no es residencia de datos. Son megavatios, fibra y temperatura de bulbo húmedo. (1/3)

Este es el post 1 de 3 de una serie sobre el paper de Sergio Cruzes AI Infrastructure Sovereignty. La parte 2 cubre la Feasible Sovereign Operating Region; la parte 3 cubre la arquitectura LLM-como-asesor.

Hace unas semanas Sergio Cruzes (Ciena) publicó en arXiv un paper titulado AI Infrastructure Sovereignty (2602.10900v4). Es el tipo de paper que no se hace viral en LinkedIn porque no promete a nadie un 10x de productividad, pero debería leerlo cualquiera que esté firmando una "estrategia de soberanía de IA" este año. Su tesis central es simple e incómoda: la soberanía de la IA ya no es un problema de software ni un problema legal. Es un problema de infraestructura. Las cláusulas de localización de datos, las regiones cloud regionales y la postura GDPR son necesarias pero ni de lejos suficientes. La soberanía real vive en megavatios, rutas de fibra y la temperatura de bulbo húmedo a las afueras de tu data hall.

Desde donde trabajo — montando DevOps y plataforma para empresas que tienen que defender su pila de IA ante un regulador — este reencuadre llega tarde, y la mayoría de los roadmaps de soberanía pública que he revisado en los últimos doce meses siguen operando una capa demasiado arriba.

Soberanía legal vs soberanía operativa

El paper hace una distinción que debería volverse vocabulario estándar:

• Soberanía legal es la capa que todo el mundo ya entiende: jurisdicción, compliance, protección de IP, marcos de localización de datos. GDPR, EU AI Act, CLOUD Act, etiquetas tipo SecNumCloud. Aquí viven abogados y compras.
• Soberanía operativa es "la capacidad práctica de observar el estado del sistema, tomar decisiones basadas en condiciones locales, validar esas decisiones y actuar dentro de políticas definidas y límites físicos". Aquí viven ingenieros y operadores. O más bien, deberían vivir. En la mayoría de las conversaciones sobre soberanía, esta capa no aparece.

Las dos capas no son lo mismo, y una sin la otra es decorado. Control legal sin capacidad operativa es nominal. Puedes tener el contrato, los informes de auditoría y la cláusula de residencia de datos y seguir dependiendo del hardware de otro, de la red óptica de otro y del power purchase agreement de otro para que el sistema funcione de verdad. Cuando ese otro queda limitado por controles de exportación, sanciones o una decisión unilateral de plataforma, tu soberanía se evapora independientemente de lo que diga el contrato.

Esta es la parte que la mayoría de las conversaciones sobre "EU sovereign cloud" se saltan elegantemente. Hablamos de dónde viven los bytes e ignoramos de dónde vienen los julios.

Qué significa "infraestructura" realmente en el paper

Cruzes es inusualmente concreto para un paper sobre soberanía. Las tres capas que trata como sustrato no son abstracciones:

1. Centros de datos de IA — racks que sobrepasan los 20–30 kW (el techo del air cooling) entrando en liquid cooling como estándar. Clústeres de training que demandan decenas a cientos de megavatios por sitio. Potencia que no dibuja una curva plana sino que pica durante operaciones colectivas en la escala de milisegundos a segundos. Nada de esto es exótico en el mundo hyperscaler; casi nada de esto está bajo control local en las soberanas europeas que he revisado.

2. Redes ópticas — la parte que la mayoría de las discusiones sobre soberanía centradas en software ignoran por completo. La velocidad de la luz fija un suelo duro de ~5 ms por cada 1.000 km. Los clústeres de training toleran alrededor de 1 ms de latencia en collective comm, lo que se traduce en un radio geográfico de unos 100 km. La inferencia es más permisiva pero igualmente tiene que sentarse cerca de la demanda. Los cables submarinos — los que llevan la mayor parte del tráfico intercontinental de IA — son "difíciles de reparar. Las interrupciones pueden durar semanas". La soberanía de una ruta de fibra no es una cláusula contractual; es el derecho de paso físico y el barco que necesitas para repararla.

3. Sistemas energéticos — capacidad de red, intensidad de carbono, agua para refrigeración. El paper propone una Feasible Sovereign Operating Region (FSOR): la intersección donde la disponibilidad de energía, la intensidad de carbono y el presupuesto de agua se pueden satisfacer conjuntamente. Volveré a la FSOR en el siguiente post porque merece tratamiento propio. El punto aquí es estructural: una región sin suficiente margen de red, con un mix energético de alto carbono o con estrés hídrico estacional no es soberana para IA frontera, por buena que sea su ley de protección de datos.

Una vez lo planteas así, no puedes seriamente reclamar soberanía para una carga de IA que corre sobre aceleradores importados, sobre una red óptica operada por un tercero, alimentándose de una red eléctrica que no controlas, refrigerada con agua que no pagas. Puedes reclamar algo, pero no soberanía en sentido operativo.

Por qué la narrativa de la región cloud se rompe aquí

Si te tomas en serio las definiciones de Cruzes, la narrativa dominante de soberanía europea — "tendremos regiones cloud soberanas operadas por entidades de la UE" — resuelve como mucho una de tres capas, y discutiblemente menos de la mitad de esa. Una región soberana implementada sobre:

• Aceleradores importados bajo regímenes de control de exportación extranjeros,
• Capacidad óptica arrendada a proveedores de tránsito con sede en otra parte,
• Power purchase agreements sin telemetría operativa hacia la red,
• Agua de refrigeración de una cuenca sin gestión local,

es una región en sentido legal y un tenant en sentido operativo. El supervisor aceptará la capa legal. La física no.

No estoy diciendo que el esfuerzo de las regiones cloud esté mal. Estoy diciendo que resuelve la parte del problema que los abogados pueden verificar y deja intacta la parte que ingenieros y operadores tienen que vivir. La primera vez que un punto de control transfronterizo — sanciones de exportación, cambio de licencia de un proveedor de plataforma, corte de un cable submarino — golpee la región, el gap entre "legalmente soberano" y "operativamente soberano" se convertirá en lo único que importa.

La capa de telemetría es la verdadera capa de soberanía

La afirmación técnica más infravalorada del paper es esta: la soberanía operativa depende de la fusión de telemetría cross-layer, y la entidad que realiza esa fusión es la que tiene las llaves de verdad.

Hoy hay cuatro ecosistemas de protocolos distintos que tienen que unirse para producir una representación unificada del estado de un data center de IA:

Dominio	Protocolos	Madurez
Redes ópticas	OpenConfig / gNMI	La más alta
Compute / power	Redfish, IPMI, APIs BMC de vendor	Heterogénea
Cooling / facilities	BACnet, Modbus	Grado facilities, no tiempo real
Sostenibilidad de red	WattTime, Electricity Maps (~5 min de actualización)	Comercial, externo

Estos cuatro no se diseñaron para hablar entre sí. Emiten esquemas distintos, cadencias distintas, garantías de freshness distintas. Unirlos en un único state vector — Cruzes lo llama θ(t) — no es trabajo commodity. Es el trabajo que determina si puedes detectar un fallo en cascada (pico de potencia → evento térmico → migración de carga → congestión de red) antes de que te pille de sorpresa, o si te enteras leyendo el post-mortem.

Y aquí viene el remate de la soberanía operativa: quien posee la capa de fusión de telemetría posee la superficie de control real. Si delegas ese trabajo a una plataforma externa — el "AI infrastructure suite" de un hyperscaler, el producto de observabilidad empaquetado de un vendor — has delegado la visibilidad operativa junto con él. Tu dashboard dice "todo en verde". Ya no sabes qué lo pondría en rojo, bajo los términos de quién ni con qué latencia.

Lo diría más directo que el paper: la fusión de telemetría es el nuevo sistema de registro para la infraestructura de IA, y la mayoría de los operadores europeos no tiene uno. Tienen dashboards montados sobre el pipeline de otro. Lo cual está bien hasta que deja de estarlo.

Qué significa esto para un cliente regulado este año

Para el tipo de cliente con el que trabajo — banca, salud, energía, sector público — traducir esto a una postura práctica significa dejar caer un par de supuestos cómodos y adoptar tres incómodos:

1. Deja de asumir que la residencia de datos es la conversación sobre soberanía. Es la capa más fácil, la que tu DPO ya sabe explicar, y la que un adversario competente o un accidente regulatorio saltan más rápido. Pertenece a la respuesta, no a toda la respuesta.

2. Adopta el supuesto de que necesitas un inventario de dependencias físicas. Para cada carga de IA en producción o planificada: qué aceleradores (y bajo qué régimen de exportación), qué rutas ópticas (y derecho de paso de quién), qué fuente de energía (y PPA de quién), qué recurso de cooling (y derechos de agua de quién). La mayoría de los equipos no puede responder esto hoy para su pila actual. El primer trabajo es el inventario, no la arquitectura.

3. Adopta el supuesto de que la fusión de telemetría es tu responsabilidad. Aunque operes sobre el hierro de otro, puedes — y en sectores regulados deberías — poseer la capa que fusiona tus señales operativas en una representación del estado tuya, sobre la que puedas razonar, auditar y presentar a un supervisor sin traducción. Sin eso, tus informes de incidente siempre se escribirán en el vocabulario de tu proveedor y en su agenda.

4. Reclasifica el sistema, no el modelo. Lo repito constantemente, también en mi lectura del informe McKinsey 2026 sobre confianza en IA: el regulador quiere el sistema sociotécnico completo clasificado, y eso ahora incluye explícitamente la capa física. El fichero de gestión de riesgos del Artículo 9 para un sistema de IA de alto riesgo que no reconozca las dependencias de energía, óptica y cooling está incompleto por la propia lógica del paper.

5. Acepta que la soberanía es un espectro, no un binario. Cruzes lo dice con claridad: ninguna región alcanza soberanía absoluta. Todas existen en algún punto de una curva definida por qué capas se controlan localmente y qué dependencias externas se aceptan. El roadmap de soberanía honesto es el que nombra las dependencias y las pone en precio, no el que afirma haberlas eliminado todas.

La parte que critico del hype sobre soberanía en IA

Estoy en el registro como positivo sobre LLMs y sistemas agénticos en producción — los despliego, los facturo, mis clientes los pagan, mi propio tiempo está "invertido" en ellos en el sentido más literal. No soy la persona a la que hay que convencer de que la IA es real.

Dicho eso, el discurso público sobre soberanía en IA tiene hoy un modo de fallo específico que el paper hace legible: trata la soberanía como un problema de contenido y no como un problema de sustrato. El pitch es "tus datos se quedan en el país", y el corolario no dicho es "todo lo que hay debajo de tus datos es problema de otro". Cruzes demuestra que el sustrato no es problema de otro; es el problema, porque el sustrato es lo que un actor externo puede retirarte de verdad.

La versión de hype de IA soberana es un modelo entrenado con datos locales, alojado en una región cloud local, comercializado bajo bandera local, corriendo sobre el mismo silicio importado y la misma capacidad óptica de larga distancia que la pila de todos los demás. La versión del paper de IA soberana es el mismo modelo, pero con la pregunta ¿bajo qué restricciones físicas puedo seguir operando si me revocan las dependencias externas? respondida con honestidad. La primera versión es una diapositiva. La segunda versión es un runbook.

Si tu programa de soberanía sabe responder la diapositiva y no sabe responder el runbook, estás exactamente donde está el resto de la industria. El trabajo de este año es darle la vuelta a esos dos estados.

Qué pondría en el roadmap de plataforma este trimestre

Para un equipo de plataforma o infraestructura en un sector regulado, tres movimientos concretos antes del próximo board update:

1. Mapea la pila de dependencias físicas para cada carga de IA en producción. Una tabla, cuatro columnas: familia de aceleradores + régimen regulatorio, ruta óptica + operador, fuente de energía + términos del PPA, recurso de cooling + gestión local. La tabla no será bonita. Ese es el punto.

2. Arranca una baseline de fusión de telemetría, aunque sea rudimentaria. Coge una sola carga, tira OpenConfig de tu capa óptica, Redfish del compute, lo que puedas sacar de facilities y un feed comercial de intensidad de carbono. Construye un θ(t) con resolución de 60 segundos para esa carga. Vas a descubrir una cantidad embarazosa de unknown unknowns. Ese es el valor del ejercicio.

3. Escribe un memo de soberanía de una página que distinga soberanía legal de operativa para tu CFO y tu supervisor. Aunque todo lo que puedas entregar este trimestre sea la columna legal, dominar el vocabulario mantiene honesta la conversación del board. Prefiero entrar a una reunión con el supervisor diciendo "controlamos las capas 1 y 2, dependemos del vendor X para las 3 y 4, aquí está la contingencia" a entrar reclamando una soberanía que no tengo.

La línea que dibujo

El encuadre del paper — legal vs operativa, con la física como restricción vinculante — es el correcto para mantener internamente aunque la versión marketing de soberanía sea la que se cite hacia fuera. La IA es real, el despliegue se acelera, el valor es genuino. Nada de eso cambia el hecho de que la capa en la que la soberanía realmente se decide se ha movido por debajo del vocabulario actual de la industria.

Si tu programa de soberanía este año sigue terminando en la cláusula de residencia de datos, no estás equivocado. Solo estás una capa demasiado arriba. El trabajo interesante — y el trabajo que le va a importar a un regulador en los próximos doce meses — está pasando por debajo de tu dashboard.

---

Fuentes:

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

¿Construyendo infraestructura de IA que tiene que defenderse ante un regulador y no estás seguro de dónde termina realmente tu programa de soberanía? Habla con un CTO — te ayudamos a separar la capa legal de la operativa antes de que lo haga otro por ti.