La Feasible Sovereign Operating Region: per què el teu roadmap d'IA topa amb un mur d'energia–carboni–aigua (2/3)

Aquest és el post 2 de 3 d'una sèrie sobre el paper AI Infrastructure Sovereignty de Sergio Cruzes. La part 1 plantejava per què la sobirania és infraestructura, no residència de dades; la part 3 tracta de l'arquitectura de l'LLM com a assessor.

La idea més útil del paper AI Infrastructure Sovereignty de Sergio Cruzes és una que no he vist formulada explícitament enlloc més: la Feasible Sovereign Operating Region (FSOR). La intersecció dins la qual tres límits físics estrictes es poden satisfer alhora, no d'un en un:

1. Energia — la capacitat de la xarxa elèctrica i les fluctuacions ràpides que els workloads d'IA hi injecten.
2. Intensitat de carboni — el mix en temps real de la xarxa que alimenta el site.
3. Aigua — la disponibilitat per refrigerar sota estrès estacional.

La majoria de roadmaps d'IA que he revisat en els últims dotze mesos n'optimitzen una de les tres i donen per fetes les altres dues sense dir-ho. Les peces no encaixen soles. L'FSOR és la part del pla on han d'encaixar per força.

Aquest post continua el de la sobirania no és residència de dades. Si l'anterior defensava que la sobirania real viu en la infraestructura física, aquest va del que passa quan intentes operar de debò dins d'aquesta infraestructura física amb les restriccions que el paper fa explícites.

Els tres límits no són independents — i aquí hi ha tota la qüestió

La sostenibilitat de la IA s'ha reportat històricament com a tres KPIs separats: el PUE per a l'eficiència energètica, els gCO₂eq/kWh per al carboni de la xarxa, el WUE per a l'aigua. Tres números, tres equips, tres informes trimestrals. La contribució del paper és insistir que són un únic problema de factibilitat conjunta, no pas tres problemes que se sumen.

Un site amb un clúster d'entrenament és operable en un moment donat només si es compleixen alhora aquestes tres condicions:

• La xarxa elèctrica té el marge de potència per absorbir el perfil a ràfegues del workload, incloent-hi els pics que van del mil·lisegon al segon durant les operacions col·lectives.
• La intensitat de carboni en temps real d'aquesta xarxa es manté dins de l'envolupant de política que has compromès (o la que un regulador de sostenibilitat estigui disposat a acceptar).
• El pressupost d'aigua local — bulb humit ambient, reserves de la conca, variació estacional — aguanta la càrrega de refrigeració a la densitat de potència requerida.

Si en falla qualsevol de les tres, el clúster ja no opera dins de l'FSOR: opera fora de política i acumula deute futur — financer, regulatori o reputacional. I les tres restriccions poden estar en tensió en un mateix site:

• Una regió amb abundància d'energia baixa en carboni pot tenir una capacitat de xarxa insuficient per absorbir més de 100 MW de càrrega a ràfegues sense desestabilitzar la xarxa local.
• Una regió amb aigua i capacitat de xarxa de sobres pot tenir un mix d'alt carboni que empeny el workload fora de l'envolupant de sostenibilitat que ha declarat.
• Una regió amb energia neta i aigua suficient pot dependre d'un traçat de fibra amb latències o dependències d'operador que, tot i així, la fan inadmissible per al workload.

L'FSOR és la intersecció. Sovint és més petita del que suggereix cadascun dels conjunts que la formen, i la majoria d'operadors no l'han arribat a calcular mai.

Per què l'entrenament és el cas més difícil

El paper fa una classificació de workloads que hauria d'estar penjada a la paret de tots els equips de plataforma:

Workload	Perfil de potència	Demanda de refrigeració	Demanda de xarxa	Portabilitat
Entrenament	A ràfegues, alt	Extrema	Molt alta	Baixa
Inferència	Sostingut	Moderada–alta	Alta	Mitjana
Batch analytics	Variable	Moderada	Baixa–moderada	Alta

La columna que ho decideix tot és la portabilitat. Els clústers d'entrenament no poden aprofitar sites llunyans baixos en carboni per una raó estructural: la latència de la comunicació col·lectiva. La velocitat de la llum posa el mínim: ~5 ms per cada 1.000 km. L'entrenament tolera aproximadament 1 ms de latència de comunicació col·lectiva, cosa que redueix el radi geogràfic a uns 100 km. Dins d'aquests 100 km, agafes el mix energètic, la situació d'aigua i el marge de xarxa que hi trobes — o no entrenes.

És aquí on el discurs de la sostenibilitat de la IA comença a coure. El relat de «mourem l'entrenament allà on l'energia sigui més verda» és una diapositiva, no una arquitectura. El paper ho diu sense embuts: l'entrenament dels models de frontera està intrínsecament lligat al site i concentrat a les poques localitzacions que satisfan les tres restriccions de l'FSOR alhora. Per això la capacitat real d'entrenament del món es concentra en un grapat de geografies: no és una preferència de la indústria, és l'FSOR fent la seva feina.

La inferència dona més marge — es pot replicar entre regions, però continua lligada a la geografia de la demanda. El batch analytics és l'única categoria on la relocalització conscient del carboni és realment assolible a escala. La majoria de demos de «IA conscient del carboni» que es veuen pel mercat venen batch analytics com si fos el titular. No està malament, però no toca l'entrenament, que és on viu de debò l'impacte en carboni, aigua i xarxa.

On els roadmaps europeus fan aigües sense fer soroll

Si et prens seriosament l'FSOR, diverses línies dels roadmaps actuals d'infraestructura d'IA europea deixen de sostenir-se soles:

• «Situar l'entrenament al nord d'Europa per la xarxa verda.» Parcialment cert. La xarxa és més verda; però el marge de xarxa en moltes de les regions objectiu ja està limitat per l'ocupació actual de data centers i per les expansions dels hyperscalers. Carboni ✓, energia ✗.
• «Aprofitar la capacitat solar del sud d'Europa per entrenar IA.» L'energia, de vegades ✓; el pressupost d'aigua amb el bulb humit de l'estiu, sovint ✗. La penalització de refrigeració en plena temporada col·lapsa l'FSOR.
• «L'edge AI elimina el problema del data center.» Per a la inferència a l'extrem mateix, de vegades. Per a l'entrenament, no. El paper hi és explícit: l'entrenament està lligat al site i les seves restriccions no es resolen repartint-les per l'edge.
• «La refrigeració líquida resol el problema de densitat.» Resol el sostre de la refrigeració per aire (el llindar de ~20–30 kW per rack). El que no resol és el pressupost d'aigua; en moltes configuracions fa la situació del WUE més llegible, no pas millor, perquè porta la demanda de refrigeració a un règim que s'ha de mesurar, no aproximar.

No dic res d'això per menystenir ningú — en principi, dono suport a tots aquests programes. Ho dic perquè la pròxima fornada d'incidents operatius a la infraestructura d'IA europea passarà precisament en l'escletxa entre el supòsit del titular («regió d'energia neta») i l'FSOR conjunta («regió d'energia neta que, un dia d'agost a les 19:00 hora local, amb la concurrència actual de la xarxa, no pot operar aquest workload dins de política»).

La telemetria que et cal només per saber quina és la teva FSOR

No pots demostrar que operes dins d'una FSOR si no la pots mesurar. L'arquitectura de referència del paper ho explicita: la fusió de telemetria entre capes és una precondició, no un extra. Per a cadascun dels tres eixos de l'FSOR, el conjunt mínim de senyals no és gens trivial:

Eix d'energia

• Consum de potència per rack i la seva derivada (per veure els pics de les operacions col·lectives, no només les mitjanes).
• Senyal de marge de la xarxa aigües amunt — normalment un feed comercial o una integració directa amb la companyia elèctrica.
• Comptabilitat de PPA en temps real (quina fracció del consum actual cobreixen de debò les renovables que tens contractades vs. la xarxa al mercat spot).

Eix de carboni

• Feed d'intensitat de carboni de la xarxa en temps real (WattTime, Electricity Maps, el TSO nacional), actualitzat cada ~5 minuts.
• La distinció entre emissions marginals i mitjanes — la majoria d'envolupants de política s'escriuen amb mitjanes, però per decidir si mous un workload el que compta és la marginal.
• Atribució: les emissions de cada workload, a quin tenant, entitat de facturació o perímetre regulatori pertanyen.

Eix d'aigua

• Temperatures d'entrada i sortida del refrigerant, i cabals.
• Bulb humit ambient i la seva previsió (perquè l'FSOR tingui una projecció a sis hores vista, no només una foto de l'instant).
• Senyal de gestió de la conca o de la companyia d'aigües — normalment una integració externa, i sovint no en temps real.

En el llenguatge del meu últim post, això és el vector d'estat θ(t) de la sostenibilitat. Sense això, la teva FSOR és una suposició. Amb això, tens el substrat per prendre decisions reals d'scheduling, throttling i migració que es puguin defensar.

Si la majoria d'equips de plataforma no tenen aquesta capa és perquè costa feina d'enginyeria de debò i no produeix cap demo. Produeix un sistema que, al cap de tres mesos, et diu «no podem operar el workload X en aquest site entre les 17:00 i les 23:00 els dies feiners d'estiu». És un resultat políticament incòmode, i això explica en part que la telemetria de l'FSOR continuï sent una assignatura pendent.

Què se suposa que ha de fer la capa agèntica — i què no

Cruzes proposa una arquitectura de control en què la IA agèntica ajuda a operar dins de l'FSOR. El límit entre LLM i agent determinista el deixo per al pròxim post. Sobre l'FSOR en concret, l'arquitectura diu tres coses útils:

1. L'optimització respecta la primacia de les restriccions. Els límits estrictes — envolupants de sostenibilitat, física — no són objectius tous dins la loss function. Prevalen. Un agent que proposi una assignació de workload que violi el pressupost d'aigua ha de ser rebutjat per la capa de coordinació, no penalitzat amb un terme de regularització.

2. La feina de debò és l'acord entre dominis. Un agent d'assignació de còmput que tria el site amb menys carboni només és correcte si l'agent de refrigeració, el de xarxa i el de la xarxa elèctrica coincideixen que és conjuntament factible. L'optimització d'un sol domini és exactament el mode de fallada que l'FSOR existeix per evitar.

3. Validació amb bessó digital abans d'executar. Cap proposta d'un agent no toca infraestructura viva fins que un bessó digital l'ha simulada contra la dinàmica física. Aquesta és la disciplina que separa operar IA per a infraestructura d'IA de fer-ne una demo.

El que en vull treure per als meus clients regulats és això: el relat de la IA agèntica als data centers no és un relat d'autonomia. És un relat d'imposició de restriccions vestit amb vocabulari d'agents. La feina interessant és fer les restriccions llegibles per màquina i la validació determinista, no fer els agents més llestos.

El que critico del hype de la sostenibilitat amb IA

Em guanyo la vida desplegant LLMs i sistemes agèntics. No argumentaré que la tecnologia no sigui útil. El que sí que argumentaré és que el hype de la sostenibilitat amb IA està optimitzant, ara mateix, la capa equivocada.

• «La IA per optimitzar la xarxa elèctrica» venuda com la resposta, quan la IA és alhora un dels grans motors de l'estrès d'aquesta xarxa. Totes dues coses són certes a la vegada. La segona frase és la que falta a la majoria de decks.
• La relocalització d'entrenament conscient del carboni presentada com una palanca a curt termini. És una palanca a llarg termini, condicionada a resoldre la restricció de latència dels 100 km, que ningú no ha resolt. La palanca a curt termini és el batch analytics conscient del carboni, que és real i útil, però no és entrenament.
• El reporting de WUE tractat com una casella per marcar. Com a xifra no està malament; només té sentit dins d'una FSOR que la lligui als eixos de carboni i energia. Un site amb un WUE excel·lent sobre una xarxa d'alt carboni i en una conca amb estrès hídric no hi guanya res: desplaça l'externalitat.
• «Refrigeració líquida = sostenible», afirmat sense fer la comptabilitat conjunta. La refrigeració líquida és el que fa possibles els racks de més de 30 kW; que millori o no la petjada global depèn del tot dels números de l'FSOR en aquell site concret.

La versió honesta de la IA conscient del carboni és aquesta: per al petit conjunt de workloads amb alta portabilitat, en regions amb una FSOR real, podem desplaçar càrrega de maneres que redueixen materialment la petjada. Això és valor genuí. I també és una afirmació molt més modesta que la de la diapositiva.

Què posaria al roadmap d'infraestructura aquest trimestre

Per a un equip de plataforma que hagi llegit la secció de l'FSOR del paper i vulgui actuar abans del pròxim cicle de divulgació de sostenibilitat:

1. Construeix un mapa de portabilitat de workloads. Per a cada workload d'IA, marca'n la categoria (entrenament / inferència / batch / serving) i el pressupost de portabilitat real — radi geogràfic, temps d'aturada admissible per migrar, restriccions d'estat. Aquest únic artefacte ja et diu quins workloads es podrien arribar a moure per criteris d'FSOR.

2. Calcula l'FSOR d'un site. Tria la ubicació amb més càrrega. Calcula la regió factible conjunta dels tres eixos per a les pròximes 72 hores amb la telemetria que puguis ajuntar. Publica-la com a dashboard intern. Hi descobriràs punts cecs immediatament. El valor és exactament aquest.

3. Defineix l'envolupant de restriccions. Tradueix les polítiques de carboni, energia i aigua que has compromès a restriccions llegibles per màquina. Si la teva política és «mitjana < X gCO₂/kWh», escriu-la com a funció de l'hora del dia i de l'estació de l'any. Les polítiques toves que només existeixen en un PDF no poden entrar a l'FSOR.

4. Etiqueta els workloads per portabilitat, no només per tier. L'etiqueta de portabilitat és la que farà servir el teu futur planificador de workloads — agèntic o no — per decidir què es pot moure. És la precondició perquè el batch shifting conscient del carboni sigui alguna cosa més que una demo.

5. Tracta l'FSOR com a part de l'expedient de gestió de riscos. En un entorn regulat, dins d'aquest mateix cicle regulatori et preguntaran per les dependències d'energia, carboni i aigua dels sistemes d'IA d'alt risc. Més val tenir l'anàlisi de l'FSOR a l'expedient que haver-la d'escriure la setmana de l'auditoria.

On poso la ratlla

L'FSOR no és un nom enginyós per a allò que ja fem; és una disciplina que, en general, encara no practiquem. Els tres KPIs de sostenibilitat que reportem cada trimestre no es posen a prova conjuntament a operacions. El hype de la IA conscient del carboni esborra la distinció de portabilitat de workloads que decideix si hi ha res que es pugui moure. I el discurs europeu de sobirania tria un dels tres eixos i dona per fet que els altres dos són problema d'algú altre.

Si operes infraestructura d'IA el 2026 i la teva plataforma no pot respondre, des d'un sistema en viu i en menys de cinc minuts, la pregunta «quina és l'FSOR del workload X al site Y durant les pròximes 72 hores?», encara no tens una FSOR: tens tres KPIs que casualment surten a la mateixa diapositiva.

La feina és perfectament abastable. És sobretot feina de telemetria, d'esquemes i de política, amb una capa fina de lògica agèntica al damunt. L'equip que la faci abans que el cicle regulatori l'atrapi anirà visiblement per davant del que no la faci.

---

Fonts:

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

Estàs executant workloads d'IA amb compromisos de sostenibilitat que no saps del cert si la teva infraestructura pot complir? Parla amb un CTO — t'ajudem a calcular una FSOR real abans que ho faci per tu el cicle de divulgació.