La Región Operativa Soberana Factible: por qué tu roadmap de IA se estrella contra el muro de energía, carbono y agua (2/3)

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

La idea más útil del paper AI Infrastructure Sovereignty de Sergio Cruzes es una que no he visto nombrada explícitamente en ningún otro sitio: la Región Operativa Soberana Factible (FSOR, por sus siglas en inglés: Feasible Sovereign Operating Region). La intersección en la que tres límites físicos duros pueden satisfacerse conjuntamente, no de uno en uno:

1. Energía — la capacidad de la red eléctrica y las fluctuaciones rápidas que las cargas de IA le inyectan.
2. Intensidad de carbono — el mix, en tiempo real, de la red que alimenta la instalación.
3. Agua — la disponibilidad de refrigeración bajo estrés estacional.

La mayoría de los roadmaps de IA que he revisado en los últimos doce meses optimizan uno de los tres límites y dan los otros dos por supuestos, sin decirlo. No encajan entre sí. La FSOR es la parte del plan donde están obligados a encajar.

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

Los tres límites no son independientes — y esa es precisamente la cuestión

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

Una instalación con un clúster de training es operable en un momento dado solo si estas tres condiciones se cumplen a la vez:

• La red eléctrica tiene margen de potencia para absorber el perfil a ráfagas de la carga, incluidos los picos de milisegundos a segundos durante las operaciones colectivas.
• La intensidad de carbono de esa red, medida en tiempo real, está dentro de la envolvente de política que has comprometido (o de la que un regulador de sostenibilidad va a aceptar).
• El presupuesto local de agua — temperatura de bulbo húmedo, reservas de la cuenca, variación estacional — soporta la carga de refrigeración a la densidad de potencia requerida.

Quita cualquiera de las 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. Y las tres restricciones pueden estar en tensión en la misma instalación:

• Una región con energía baja en carbono abundante puede tener una capacidad de red insuficiente para absorber 100+ MW de carga a ráfagas sin desestabilizar la red local.
• Una región con agua y capacidad de red de sobra puede tener un mix alto en carbono que empuje la carga fuera de la envolvente de sostenibilidad que ha declarado.
• Una región con energía limpia y agua suficiente puede depender de una ruta de fibra con latencias o dependencias de operador que, de entrada, la hacen inadmisible para la carga.

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

Por qué el training es el caso más difícil

El paper hace una clasificación de cargas que debería estar colgada en la pared de todos los equipos de plataforma:

Carga	Perfil de potencia	Demanda de refrigeración	Demanda de red	Portabilidad
Training	A ráfagas, alta	Extrema	Muy alta	Baja
Inferencia	Sostenida	Moderada–alta	Alta	Media
Batch analytics	Variable	Moderada	Baja–moderada	Alta

La columna decisiva es la de portabilidad. Los clústeres de training no pueden aprovechar sitios lejanos bajos en carbono por una razón estructural: la latencia de la comunicación colectiva. La velocidad de la luz fija el suelo: ~5 ms por cada 1.000 km. El training tolera aproximadamente 1 ms de latencia en operaciones colectivas, lo que reduce el radio geográfico a unos 100 km. Dentro de esos 100 km, te quedas con el mix energético, la situación del agua y el margen de red que haya — o no entrenas.

Esta es la parte del discurso sobre sostenibilidad de la IA donde las cosas empiezan a doler. El relato de «moveremos el training allá donde la energía sea más verde» es una diapositiva, no una arquitectura. El paper lo dice sin rodeos: el training de IA de frontera está inherentemente ligado al emplazamiento y concentrado en las pocas ubicaciones que satisfacen las tres restricciones de la FSOR a la vez. Por eso la capacidad real de training del mundo se agrupa en un puñado de geografías; no es una preferencia de la industria, es la FSOR haciendo su trabajo.

La inferencia perdona más — es replicable entre regiones, aunque sigue atada a la geografía de la demanda. El batch analytics es la única categoría donde la relocalización carbon-aware es de verdad alcanzable a escala. La mayoría de las demos de «IA carbon-aware» que circulan reempaquetan batch analytics como titular. No está mal, pero no aborda el training, que es donde de verdad viven el impacto en carbono, agua y red.

Dónde se rompen, sin hacer ruido, los roadmaps europeos

Si te tomas la FSOR en serio, varias líneas de los roadmaps europeos actuales de infraestructura de IA dejan de sostenerse por sí solas:

• «Ubicar el training en el norte de Europa por su red verde.» Parcialmente cierto. La red es más verde; el margen de red en muchas de las regiones objetivo ya está limitado por la ocupación existente de centros de datos y las expansiones de los hyperscalers. Carbono ✓, energía ✗.
• «Usar la capacidad solar del sur de Europa para entrenar IA.» Disponibilidad de energía, a veces ✓; presupuesto de agua bajo las condiciones de bulbo húmedo del verano, muchas veces ✗. La penalización de refrigeración en plena temporada alta colapsa la FSOR.
• «El edge AI elimina el problema del centro de datos.» Para inferencia en el borde mismo, a veces. Para training, no. El paper es explícito en esto: el training está ligado al emplazamiento y sus restricciones no se resuelven repartiéndolo por el edge.
• «La refrigeración líquida resuelve el problema de densidad.» Resuelve el techo de la refrigeración por aire (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 refrigeración a un régimen que hay que medir en lugar de aproximar.

Nada de esto lo digo por desdén — apoyo cada uno de esos programas en principio. Lo digo porque la próxima tanda de incidentes operativos en la infraestructura de IA europea vivirá exactamente en el hueco 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 la red, no puede operar esta carga dentro de la política»).

La telemetría que necesitas para siquiera conocer tu FSOR

No puedes demostrar que operas dentro de una FSOR si no puedes medirla. La arquitectura de referencia del paper lo deja claro: la fusión de telemetría entre capas es una precondición, no un extra. Para cada uno de los tres ejes de la FSOR, el conjunto mínimo de señales no es trivial:

Eje de energía

• Consumo de potencia por rack y su derivada (para ver los picos de las operaciones colectivas, no solo las medias).
• Señal de margen de la red aguas arriba — normalmente un feed comercial o una integración directa con la eléctrica.
• Contabilidad de PPA en tiempo real (qué fracción del consumo actual está cubierta de verdad por tus renovables contratadas frente al mercado spot).

Eje de carbono

• Feed en tiempo real de intensidad de carbono de la red (WattTime, Electricity Maps, el TSO nacional). Cadencia de actualización: ~5 minutos.
• La distinción entre emisiones marginales y medias — la mayoría de las envolventes de política están escritas en medias, pero para decidir desplazamientos de carga 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 de agua

• Temperaturas de entrada y salida del refrigerante, caudales.
• Bulbo húmedo ambiente y su previsión (para que la FSOR tenga una proyección a seis horas vista, no solo una foto del instante).
• Señal de gestión de la cuenca o de la compañía de aguas — normalmente una integración externa, y muchas veces no en tiempo real.

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

La razón por la que la mayoría de los equipos de plataforma no tiene esta capa es que cuesta trabajo de ingeniería real y no produce ninguna demo. Produce un sistema que, a los tres meses, dice «no podemos operar la carga X en esta instalación entre las 17:00 y las 23:00 los días laborables de verano». Es un resultado políticamente incómodo, y eso explica en parte que la telemetría de la FSOR siga sin construirse.

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. La frontera entre el LLM y el agente determinista la cubro en el siguiente post. Para la FSOR en concreto, la arquitectura dice tres cosas útiles:

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

2. El verdadero trabajo es el acuerdo entre dominios. Un agente de colocación de cómputo que elige el sitio con menos carbono solo acierta si el agente de refrigeración, el de red y el de la red eléctrica coinciden en que es factible en conjunto. La optimización de un solo dominio es exactamente el modo de fallo que la FSOR existe para evitar.

3. Validación con gemelo digital antes de ejecutar. Ninguna propuesta de un agente toca la infraestructura real hasta que un gemelo digital la ha simulado contra la dinámica física. Esa es la disciplina que separa operar IA para infraestructura de IA de operar una demo de IA para infraestructura de IA.

La conclusión que quiero extraer aquí para mis clientes regulados: el relato de la IA agéntica sobre el centro de datos no es un relato de autonomía. Es un relato de aplicación de restricciones vestido con vocabulario de agentes. El trabajo interesante está en hacer las restricciones legibles por máquina y la validación determinista, no en hacer los agentes más listos.

Lo que critico del hype de la IA para sostenibilidad

Me gano la vida desplegando LLMs y sistemas agénticos. No voy a negar que la tecnología sea útil. Lo que sí voy a sostener es que el hype de la IA para sostenibilidad está optimizando, hoy, la capa equivocada.

• «IA para optimizar la red» vendida como la respuesta, cuando la IA es también una de las grandes causas de estrés de esa misma red. Las dos cosas son ciertas a la vez. La segunda frase falta en la mayoría de las presentaciones.
• La relocalización carbon-aware del training presentada como palanca a corto plazo. Es una palanca a largo plazo, condicionada a resolver la restricción de latencia de los 100 km, que nadie ha resuelto. La palanca a corto plazo es el batch analytics carbon-aware, que es real y útil, pero no es training.
• El reporting de WUE tratado como una casilla que marcar. Como número está bien; solo cobra sentido dentro de una FSOR que lo una a los ejes de carbono y energía. Una instalación con un WUE estupendo sobre una red alta en carbono y en una cuenca con estrés hídrico no está ganando nada; está moviendo la externalidad de sitio.
• «Refrigeración líquida = sostenible» afirmado sin la contabilidad conjunta. La refrigeración líquida es lo que hace posibles los racks de más de 30 kW; que mejore o no la huella total depende por completo de las cuentas de la FSOR en esa instalación concreta.

La versión honesta de la IA carbon-aware es esta: para el pequeño conjunto de cargas con alta portabilidad, en regiones con una FSOR real, podemos desplazar carga de maneras que reducen la huella de forma material. Eso es valor genuino. Y es también 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 de la FSOR del paper y quiera actuar antes del próximo ciclo de divulgación de sostenibilidad:

1. Construye un mapa de portabilidad de cargas. Para cada carga de IA, anota su categoría (training / inferencia / batch / serving) y su presupuesto real de portabilidad: radio geográfico, tiempo de parada admisible para migrar, restricciones de estado. Este único artefacto te dice qué cargas podrían siquiera moverse con criterios de FSOR.

2. Calcula la FSOR de una instalación. Elige tu ubicación más cargada. Calcula la región factible conjunta en los tres ejes para las próximas 72 horas con la telemetría que consigas reunir. Publica el resultado como dashboard interno. Descubrirás puntos ciegos de inmediato. Ese es el valor.

3. Define la envolvente de restricciones. Traduce tus políticas comprometidas de carbono, energía y agua a restricciones legibles por máquina. Si tu política es «media <X gCO₂/kWh», escríbela como función de la hora del día y de 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 planificador de cargas — agéntico o no — usará para decidir qué puede moverse. Es la precondición para que el desplazamiento carbon-aware de batch sea algo más que una demo.

5. Trata la FSOR como parte del expediente 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 mismo ciclo regulatorio. Mejor tener el análisis de la FSOR en el expediente que escribirlo la semana de la auditoría.

La línea que trazo

La FSOR no es un nombre ingenioso para lo que ya hacemos; es una disciplina que, en su mayor parte, todavía no practicamos. Los tres KPIs de sostenibilidad que reportamos cada trimestre no se comprueban conjuntamente en operación. El hype de la IA carbon-aware borra la distinción de portabilidad de cargas que decide si algo puede desplazarse siquiera. El discurso europeo de soberanía elige uno de los tres ejes y asume que los otros dos son problema de otro.

Si operas infraestructura de IA en 2026 y tu plataforma no puede responder a la pregunta «¿cuál es la FSOR de la carga X en la instalación Y para las próximas 72 horas?» desde un sistema vivo en menos de cinco minutos, todavía no tienes una FSOR: tienes tres KPIs que casualmente se presentan en la misma diapositiva.

El trabajo se puede hacer. Es, sobre todo, 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 lo alcance irá visiblemente por delante del que no.

---

Fuentes:

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

¿Operas cargas de IA con compromisos de sostenibilidad que no sabes si tu infraestructura puede cumplir de verdad? Habla con un CTO — te ayudamos a calcular una FSOR real antes de que el ciclo de divulgación lo haga por ti.