La Feasible Sovereign Operating Region: por qué tu roadmap de IA choca con un muro de energía, carbono y agua (2/3)

Este es el post 2 de 3 de una serie sobre el paper de Sergio Cruzes AI Infrastructure Sovereignty. La parte 1 enmarcaba por qué la soberanía es infraestructura, no residencia de datos; la parte 3 cubre la arquitectura LLM-como-asesor.

La idea más útil del paper AI Infrastructure Sovereignty de Sergio Cruzes es una que no había visto nombrada explícitamente en otro sitio: la Feasible Sovereign Operating Region (FSOR). La intersección en la que tres límites físicos duros se pueden satisfacer conjuntamente, no de uno en uno:

1. Energía — capacidad de red y las fluctuaciones rápidas que las cargas de IA inyectan en ella.
2. Intensidad de carbono — el mix vivo de la red que alimenta el sitio.
3. Agua — disponibilidad de cooling bajo estrés estacional.

La mayoría de roadmaps de IA que he revisado en los últimos doce meses optimizan uno de los tres y asumen silenciosamente los otros dos. No componen. La FSOR es la parte del plan donde tienen que hacerlo.

Esto es una continuación de el post sobre soberanía-no-es-residencia-de-datos. Si la pieza anterior argumentaba que la soberanía real vive en infraestructura física, esta va sobre qué pasa cuando intentas operar de verdad en esa infraestructura física bajo las restricciones que el paper hace explícitas.

Los tres límites no son independientes — ese es justo el punto

La sostenibilidad de IA se ha reportado históricamente como tres KPIs separados: PUE para eficiencia de potencia, gCO₂eq/kWh para carbono de red, WUE para agua. Tres números, tres equipos, tres informes trimestrales. La contribución del paper es insistir en que son un único problema de factibilidad conjunto, no tres aditivos.

Un sitio con un clúster de training es operable en un momento dado solo si las tres cosas siguientes son simultáneamente ciertas:

• La red eléctrica tiene margen de potencia para absorber el perfil rafagudo de la carga, incluyendo picos de milisegundos-a-segundos durante operaciones colectivas.
• La intensidad de carbono viva de esa red está dentro del envelope de política con el que te has comprometido (o el que un regulador de sostenibilidad va a aceptar).
• El presupuesto local de agua — bulbo húmedo ambiente, reservas de la cuenca, variación estacional — soporta la carga de cooling a la densidad de potencia requerida.

Quita una sola de esas tres y el clúster no está operando en la FSOR; está operando fuera de la política y acumulando deuda futura — financiera, regulatoria o reputacional. Las tres restricciones pueden estar en tensión en el mismo sitio:

• Una región con energía abundante de bajo carbono puede tener capacidad de red insuficiente para absorber 100+ MW de carga rafaguda sin desestabilizar la red local.
• Una región con agua y capacidad de red abundantes puede tener un mix de alto carbono que empuje la carga fuera de su envelope de sostenibilidad declarado.
• Una región con energía limpia y agua adecuada puede sentarse en una ruta de fibra con latencia o dependencias de operador que la hagan inadmisible para la carga de todas formas.

La FSOR es la intersección. Suele ser más pequeña de lo que cualquiera de sus conjuntos constituyentes sugiere, y la mayoría de los operadores no la han calculado de verdad.

Por qué el training es el caso más duro

El paper hace una clasificación de cargas que debería estar en la pared de todo equipo de plataforma:

Carga	Perfil de potencia	Demanda de cooling	Demanda de red	Portabilidad
Training	Rafaguda, alta	Extrema	Muy alta	Baja
Inferencia	Sostenida	Moderada–alta	Alta	Media
Batch analytics	Variable	Moderada	Baja–moderada	Alta

La columna asesina es portabilidad. Los clústeres de training no pueden explotar sitios lejanos de bajo carbono por una razón estructural — la latencia de collective comm. La velocidad de la luz fija el suelo: ~5 ms por cada 1.000 km. El training tolera aproximadamente 1 ms de latencia de collective comm, lo que colapsa el radio geográfico a unos 100 km. Dentro de 100 km te quedas con el mix energético, la situación de agua y el margen de red que encuentres, o no entrenas.

Esta es la parte del discurso sobre sostenibilidad de IA en la que las cosas empiezan a doler. La historia de "moveremos el training a donde la energía sea más verde" es una diapositiva, no una arquitectura. El paper lo dice sin rodeos: el training de IA frontera es inherentemente site-bound y concentrado en las pocas localizaciones que satisfacen las tres restricciones FSOR simultáneamente. Por eso la capacidad real de training en el mundo se agrupa en un conjunto pequeño de geografías; no es preferencia de la industria, es la FSOR haciendo su trabajo.

La inferencia es más permisiva — replicable entre regiones, pero todavía atada a la geografía de la demanda. El batch analytics es la única categoría donde la relocalización carbon-aware es realmente alcanzable a escala. La mayoría de las demos "carbon-aware AI" del mercado rebrandean el batch analytics como titular. Vale, pero eso no aborda el training, que es donde el impacto en carbono, agua y red vive de verdad.

Dónde se rompen silenciosamente los roadmaps europeos

Si te tomas en serio la FSOR, varias líneas de los roadmaps actuales de infraestructura de IA europea dejan de sostener su propio peso:

• "Ubicar el training en el norte de Europa por el grid verde." Parcialmente cierto. La red es más verde; el margen de red en muchas regiones objetivo ya está restringido por la ocupación actual de data centers y por la expansión de hyperscalers. Carbono ✓, energía ✗.
• "Usar capacidad solar del sur de Europa para entrenar IA." Disponibilidad de energía a veces ✓; presupuesto de agua bajo condiciones de bulbo húmedo en verano frecuentemente ✗. La penalización de cooling en pico estacional colapsa la FSOR.
• "Edge AI elimina el problema del data center." Para inferencia en el very edge, a veces. Para training, no. El paper es explícito: el training es site-bound y sus restricciones no se resuelven con un fan-out al edge.
• "Liquid cooling resuelve el problema de densidad." Resuelve el techo del air cooling (el umbral de ~20–30 kW por rack). No resuelve el presupuesto de agua; en muchas configuraciones hace la situación de WUE más legible, no mejor, porque lleva la demanda de cooling a un régimen que hay que medir, no aproximar.

No digo nada de esto para descartar — apoyo cada uno de esos programas en principio. Lo digo porque la próxima ronda de incidentes operativos en la infraestructura de IA europea va a vivir precisamente en el gap entre el supuesto del titular ("región de energía limpia") y la FSOR conjunta ("región de energía limpia que, en agosto a las 19:00 hora local, con la concurrencia actual de red, no puede operar esta carga dentro de política").

La telemetría que necesitas para siquiera conocer tu FSOR

No puedes demostrar que estás operando dentro de una FSOR si no la puedes medir. La arquitectura de referencia del paper lo deja claro: la fusión de telemetría cross-layer es una precondición, no un nice-to-have. Para cada uno de los tres ejes FSOR, el conjunto mínimo de señales no es trivial:

Eje energía

• Consumo por rack y la derivada (para que veas picos de operaciones colectivas, no solo medias).
• Señal de margen de red aguas arriba — habitualmente un feed comercial o una integración directa con la utility.
• Contabilidad PPA en tiempo real (qué fracción del consumo actual está realmente cubierta por tus renovables contratadas frente al spot de red).

Eje carbono

• Feed vivo de intensidad de carbono de red (WattTime, Electricity Maps, TSO nacional). Cadencia de actualización ~5 minutos.
• Distinción entre emisiones marginales y medias — la mayoría de los envelopes de política están escritos en medias, pero para decisiones de workload-shifting lo que importa es la marginal.
• Atribución: qué emisiones de qué carga pertenecen a qué tenant, entidad de facturación o perímetro regulatorio.

Eje agua

• Temperaturas de entrada/salida de refrigerante, caudales.
• Bulbo húmedo ambiente y previsión (para que la FSOR tenga proyección a las próximas seis horas, no solo un snapshot actual).
• Señal de gestión de cuenca / utility — habitualmente una integración externa, frecuentemente no en tiempo real.

En el lenguaje de mi post anterior, esto es el state vector θ(t) para sostenibilidad. Sin él, tu FSOR es una conjetura. Con él, tienes el sustrato para tomar decisiones reales de scheduling, throttling y migración defendiblemente.

La razón por la que la mayoría de los equipos de plataforma no tienen esta capa es que cuesta trabajo de ingeniería real y no produce demo. Produce un sistema que, a los tres meses, dice "no podemos operar la carga X en este sitio entre las 17:00 y las 23:00 los días laborables de verano". Esa es una salida políticamente incómoda, lo cual forma parte de por qué la telemetría FSOR sigue infraconstruida.

Qué se supone que hace la capa agéntica — y qué no

Cruzes propone una arquitectura de control en la que la IA agéntica ayuda a operar dentro de la FSOR. Cubriré el límite LLM-vs-agente-determinista en el siguiente post. Para la FSOR específicamente, la arquitectura dice tres cosas útiles:

1. La optimización respeta la primacía de las restricciones. Los límites duros — envelopes de sostenibilidad, física — no son objetivos blandos en la función de pérdida. Mandan. Un agente que proponga una colocación de carga que viole el presupuesto de agua debería ser rechazado por la capa de coordinación, no penalizado por un término de regularización.

2. El acuerdo cross-domain es el trabajo real. Un agente de placement de compute que elige el sitio de menor carbono es correcto solo si el agente de cooling, el de red y el de grid están de acuerdo en que es conjuntamente factible. La optimización de un solo dominio es exactamente el modo de fallo que la FSOR existe para prevenir.

3. Validación con digital twin antes de ejecución. Ninguna propuesta de agente toca la infraestructura viva hasta que un digital twin la ha simulado contra la dinámica física. Esta es la disciplina que separa correr IA para infraestructura de IA de correr una demo de IA para infraestructura de IA.

El punto que quiero extraer aquí para mis clientes regulados: la historia de IA-agéntica-sobre-data-center no es una historia de autonomía. Es una historia de aplicación de restricciones disfrazada con vocabulario de agente. El trabajo interesante es hacer las restricciones machine-readable y la validación determinista, no hacer los agentes más listos.

Qué critico del hype de sostenibilidad-IA

Despliego LLMs y sistemas agénticos para ganarme la vida. No voy a discutir que la tecnología no es útil. Lo que sí voy a argumentar es que el hype actual de sostenibilidad-IA está optimizando la capa equivocada.

• "IA para optimización de red" vendida como la respuesta cuando la IA es también un driver mayor de estrés en la red. Las dos cosas son ciertas a la vez. La segunda frase falta en la mayoría de las presentaciones.
• Relocalización carbon-aware del training presentada como una palanca de corto plazo. Es una palanca de largo plazo condicionada a resolver la restricción de los 100 km de latencia, que nadie ha resuelto. La palanca de corto plazo es el batch analytics carbon-aware, que es real y útil pero no es training.
• Reporting de WUE tratado como un checkbox. Está bien como número; solo se vuelve significativo dentro de una FSOR que lo une a los ejes de carbono y energía. Un sitio con un WUE estupendo en una red de alto carbono y una cuenca con estrés hídrico no está ganando nada; está moviendo la externalidad.
• "Liquid cooling = sostenible" afirmado sin la contabilidad conjunta. El liquid cooling es lo que hace posibles los racks >30 kW; si mejora la huella global depende enteramente de las matemáticas FSOR en ese sitio específico.

La versión honesta de IA carbon-aware es: para el pequeño conjunto de cargas con alta portabilidad, en regiones con una FSOR real, podemos desplazar carga de formas que reducen materialmente la huella. Eso es valor genuino. También es una afirmación mucho más estrecha que la de la diapositiva.

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

Para un equipo de plataforma que haya leído la sección FSOR del paper y quiera actuar antes del próximo ciclo de disclosure de sostenibilidad:

1. Construye un mapa de portabilidad de cargas. Para cada carga de IA, marca su categoría (training / inferencia / batch / serving) y su presupuesto real de portabilidad — radio geográfico, downtime permitido para migrar, restricciones de statefulness. Este único artefacto te dice qué cargas podrían siquiera moverse sobre una base FSOR.

2. Calcula la FSOR para un sitio. Coge tu localización más cargada. Calcula la región conjunta factible a lo largo de los tres ejes para las próximas 72 horas usando la telemetría que puedas reunir. Publícalo como dashboard interno. Vas a descubrir blind spots inmediatamente. Ese es el valor.

3. Define el envelope de restricciones. Traduce tus políticas de carbono, energía y agua comprometidas a restricciones machine-readable. Si tu política es "media <X gCO₂/kWh", escríbela como función de la hora del día y la estación. Las políticas blandas que solo viven en un PDF no pueden entrar en la FSOR.

4. Etiqueta las cargas por portabilidad, no solo por tier. La etiqueta de portabilidad es la que tu futuro scheduler de cargas — agéntico o no — usará para decidir qué puede moverse. Esta es la precondición para que el batch shifting carbon-aware sea algo más que una demo.

5. Trata la FSOR como parte del fichero de gestión de riesgos. En un entorno regulado, te van a preguntar por las dependencias de energía, carbono y agua de los sistemas de IA de alto riesgo dentro de este ciclo regulatorio. Mejor tener un análisis FSOR en el fichero que escribirlo la semana de la auditoría.

La línea que dibujo

La FSOR no es un nombre ingenioso para lo que ya hacemos; es una disciplina que mayormente todavía no hacemos. Los tres KPIs de sostenibilidad que reportamos trimestralmente no se testean conjuntamente en operación. El hype alrededor de la IA carbon-aware aplana la distinción de portabilidad de cargas que decide si algo se puede desplazar siquiera. El discurso europeo sobre soberanía elige uno de los tres ejes y asume que los otros dos son problema de otro.

Si estás operando infraestructura de IA en 2026 y la pregunta "¿cuál es la FSOR para la carga X en el sitio Y durante las próximas 72 horas?" no la puede responder tu plataforma desde un sistema vivo en menos de cinco minutos, todavía no tienes una FSOR — tienes tres KPIs que casualmente se reportan en la misma diapositiva.

El trabajo es hacible. Es mayormente trabajo de telemetría, esquemas y políticas, con una pequeña capa de lógica agéntica encima. El equipo que lo haga antes de que el ciclo regulatorio le pille estará visiblemente por delante del que no.

---

Fuentes:

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

¿Corriendo cargas de IA con compromisos de sostenibilidad que no estás seguro de que tu infraestructura pueda honrar de verdad? Habla con un CTO — te ayudamos a calcular una FSOR real antes de que el ciclo de disclosure lo haga por ti.