La Feasible Sovereign Operating Region: perché la tua roadmap IA sbatte contro un muro energia–carbonio–acqua (2/3)

Questo è il post 2 di 3 di una serie sul paper AI Infrastructure Sovereignty di Sergio Cruzes. La parte 1 ha inquadrato perché la sovranità è infrastruttura, non residenza dei dati; la parte 3 copre l'architettura LLM-come-consulente.

L'idea più utile del paper AI Infrastructure Sovereignty di Sergio Cruzes è una che non ho visto nominata esplicitamente altrove: la Feasible Sovereign Operating Region (FSOR). L'intersezione in cui tre limiti fisici duri possono essere soddisfatti congiuntamente, non uno alla volta:

1. Energia — capacità di rete e le rapide fluttuazioni che i workload IA le iniettano.
2. Intensità di carbonio — il mix in tempo reale della rete che alimenta il sito.
3. Acqua — disponibilità per il raffreddamento sotto stress stagionale.

La maggior parte delle roadmap IA che ho rivisto negli ultimi dodici mesi ottimizza uno dei tre e in silenzio assume gli altri due. Non si compongono. La FSOR è la parte del piano in cui si è obbligati a farlo.

Questo è un seguito del post sulla sovranità che non è residenza dei dati. Se il pezzo precedente sosteneva che la sovranità reale vive nell'infrastruttura fisica, questo riguarda ciò che succede quando provi davvero a operare in quell'infrastruttura fisica sotto i vincoli che il paper rende espliciti.

I tre limiti non sono indipendenti — è esattamente questo il punto

La sostenibilità IA è stata storicamente riportata come tre KPI separati: PUE per l'efficienza energetica, gCO₂eq/kWh per il carbonio di rete, WUE per l'acqua. Tre numeri, tre team, tre report trimestrali. Il contributo del paper è insistere che siano un singolo problema di feasibility congiunta, non tre additivi.

Un sito di cluster di training è operabile in un dato momento solo se tutte e tre le condizioni seguenti sono simultaneamente vere:

• La rete ha l'headroom di potenza per assorbire il profilo bursty del workload, inclusi i picchi millisecondo-secondo durante le operazioni collettive.
• L'intensità di carbonio in tempo reale di quella rete è dentro l'envelope di policy a cui ti sei impegnato (o quello che un regolatore di sostenibilità accetterà).
• Il budget idrico locale — bulbo umido ambientale, riserve di bacino, variazione stagionale — supporta il carico di raffreddamento alla densità di potenza richiesta.

Togline uno qualsiasi, e il cluster non sta operando nella FSOR; sta operando fuori dalla policy e accumulando debito futuro — finanziario, regolatorio o reputazionale. I tre vincoli possono essere in tensione nello stesso sito:

• Una regione con abbondante energia a basso carbonio può avere capacità di rete insufficiente per assorbire 100+ MW di carico bursty senza destabilizzare la rete locale.
• Una regione con abbondante acqua e capacità di rete può avere un mix ad alto carbonio che spinge il workload fuori dall'envelope di sostenibilità dichiarato.
• Una regione con energia pulita e acqua adeguata può trovarsi su un tracciato in fibra con dipendenze di latenza o operatore che la rendono comunque inammissibile per il workload.

La FSOR è l'intersezione. È spesso più piccola di quanto suggerisca uno qualsiasi dei suoi insiemi costituenti, e la maggior parte degli operatori non l'ha effettivamente calcolata.

Perché il training è il caso più difficile

Il paper propone una classificazione di workload che dovrebbe stare sul muro di ogni team di piattaforma:

Workload	Profilo di potenza	Domanda di cooling	Domanda di rete	Portabilità
Training	Bursty, alta	Estrema	Molto alta	Bassa
Inference	Sostenuta	Moderata–alta	Alta	Media
Batch analytics	Variabile	Moderata	Bassa–moderata	Alta

La colonna killer è la portabilità. I cluster di training non possono sfruttare siti distanti a basso carbonio per una ragione strutturale — la latenza di collective communication. La velocità della luce fissa il pavimento: ~5 ms per 1.000 km. Il training tollera circa 1 ms di latenza di collective-comm, che collassa il raggio geografico a circa 100 km. Entro 100 km, prendi il mix energetico, la situazione idrica e l'headroom di rete che trovi, o non addestri.

Questa è la parte del discorso sulla sostenibilità IA dove le cose iniziano a fare male. La storia "sposteremo il training dove l'energia è più verde" è una slide, non un'architettura. Il paper lo dice chiaramente: il training IA di frontiera è inerentemente legato al sito e concentrato nelle poche località che soddisfano tutti e tre i vincoli FSOR simultaneamente. È per questo che la capacità reale di training nel mondo si concentra in un piccolo insieme di geografie; non è preferenza dell'industria, è la FSOR che fa il suo lavoro.

L'inference è più tollerante — replicabile tra region, ma comunque legata alla geografia della domanda. Le batch analytics sono l'unica categoria in cui la relocazione carbon-aware è effettivamente raggiungibile su larga scala. La maggior parte delle demo "carbon-aware AI" in giro ribattezza le batch analytics come headline. Va bene, ma non affronta il training, che è dove l'impatto su carbonio, acqua e rete vive davvero.

Dove le roadmap europee si rompono in silenzio

Se prendi la FSOR sul serio, diverse linee delle attuali roadmap europee di infrastruttura IA smettono di reggere il proprio peso:

• "Localizziamo il training nel Nord Europa per la rete verde." Parzialmente vero. La rete è più verde; l'headroom di rete in molte regioni target è già vincolato dalla tenancy di data center esistenti e dalle espansioni hyperscaler. Carbonio ✓, energia ✗.
• "Usiamo la capacità solare del Sud Europa per il training IA." Disponibilità energetica a volte ✓; budget idrico sotto condizioni di bulbo umido estive spesso ✗. La penalità di raffreddamento in piena stagione collassa la FSOR.
• "L'edge AI elimina il problema del data center." Per l'inference all'edge estremo, a volte. Per il training, no. Il paper è esplicito: il training è legato al sito e i suoi vincoli non si risolvono con il fan-out all'edge.
• "Il liquid cooling risolve il problema della densità." Risolve il soffitto dell'air cooling (la soglia di ~20–30 kW per rack). Non risolve il budget idrico; in molte configurazioni rende la situazione WUE più leggibile, non migliore, perché porta la domanda di cooling in un regime che deve essere misurato anziché approssimato.

Non dico niente di questo per essere sprezzante — supporto ognuno di quei programmi in linea di principio. Lo dico perché il prossimo giro di incidenti operativi nell'infrastruttura IA europea vivrà esattamente nel divario tra l'assunzione headline ("regione con energia pulita") e la FSOR congiunta ("regione con energia pulita che, ad agosto alle 19:00 locali, con l'attuale concorrenza di rete, non può operare questo workload in policy").

La telemetria che serve anche solo per conoscere la tua FSOR

Non puoi provare di stare operando dentro una FSOR se non puoi misurarla. L'architettura di riferimento del paper lo dice chiaramente: la fusione di telemetria cross-layer è una precondizione, non un nice-to-have. Per ognuno dei tre assi FSOR, l'insieme minimo di segnale non è banale:

Asse energia

• Power draw per rack e la derivata (così vedi i picchi di collective-op, non solo le medie).
• Segnale di headroom di rete a monte — di solito un feed commerciale o un'integrazione diretta con l'utility.
• Contabilità PPA in tempo reale (quale frazione del draw corrente è effettivamente coperta dalle tue rinnovabili contrattate vs. spot grid).

Asse carbonio

• Feed live di intensità di carbonio di rete (WattTime, Electricity Maps, TSO nazionale). Cadenza di aggiornamento ~5 minuti.
• Distinzione tra emissioni marginali e medie — la maggior parte degli envelope di policy è scritta in medie, ma per le decisioni di workload-shifting conta il marginale.
• Attribuzione: a quale tenant, entità di billing o perimetro regolatorio appartengono le emissioni di quale workload.

Asse acqua

• Temperature di ingresso/uscita del coolant, portate.
• Bulbo umido ambientale e una previsione (così la FSOR ha una proiezione prossime sei ore, non solo uno snapshot corrente).
• Segnale di stewardship di bacino / utility — di solito un'integrazione esterna, spesso non real-time.

Nel linguaggio del mio post precedente, questo è il vettore di stato θ(t) per la sostenibilità. Senza, la tua FSOR è una congettura. Con, hai il substrato per prendere decisioni di scheduling, throttling e migrazione effettive in modo difendibile.

La ragione per cui la maggior parte dei team di piattaforma non ha questo livello è che costa lavoro di engineering reale e non produce demo. Produce un sistema che, dopo tre mesi, dice "non possiamo operare il workload X su questo sito tra le 17:00 e le 23:00 nei giorni feriali estivi." È un output politicamente scomodo, motivo per cui la telemetria FSOR resta sottocostruita.

Cosa dovrebbe fare il livello agentico — e cosa no

Cruzes propone un'architettura di controllo in cui l'IA agentica aiuta a operare dentro la FSOR. Coprirò il confine LLM-vs-agente-deterministico nel prossimo post. Per la FSOR nello specifico, l'architettura dice tre cose utili:

1. L'ottimizzazione rispetta la primazia dei vincoli. I limiti duri — envelope di sostenibilità, fisica — non sono obiettivi soft nella loss function. Hanno la priorità. Un agente che propone un piazzamento di workload che viola il budget idrico deve essere rifiutato dal livello di coordinamento, non penalizzato da un termine di regolarizzazione.

2. L'accordo cross-domain è il lavoro vero. Un agente di piazzamento compute che sceglie il sito a più basso carbonio è corretto solo se l'agente cooling, l'agente di rete e l'agente di grid concordano che è congiuntamente fattibile. L'ottimizzazione single-domain è esattamente la modalità di fallimento che la FSOR esiste per prevenire.

3. Validazione del digital twin prima dell'esecuzione. Nessuna proposta di agente tocca infrastruttura live finché un digital twin non l'ha simulata contro la dinamica fisica. Questa è la disciplina che separa il far girare IA per l'infrastruttura IA dal far girare una demo di IA per l'infrastruttura IA.

Il punto che voglio estrarre qui per i miei clienti regolamentati: la storia agentic-AI-on-data-centre non è una storia di autonomia. È una storia di enforcement dei vincoli vestita di vocabolario agentico. Il lavoro interessante è rendere i vincoli machine-readable e la validazione deterministica, non rendere gli agenti più intelligenti.

Di cosa sono critico nell'hype sostenibilità-IA

Faccio deploy di LLM e sistemi agentici per vivere. Non sto per sostenere che la tecnologia non sia utile. Quello che sto per sostenere è che l'hype sostenibilità-IA sta attualmente ottimizzando il livello sbagliato.

• "IA per ottimizzazione della rete" venduta come la risposta quando l'IA è anche un grande driver di stress sulla rete. Entrambe vere insieme. La seconda frase manca nella maggior parte delle slide.
• La relocazione del training carbon-aware presentata come leva a breve termine. È una leva a lungo termine condizionata alla risoluzione del vincolo di latenza dei 100 km, che nessuno ha risolto. La leva a breve termine è la batch analytics carbon-aware, che è reale e utile ma non è training.
• Il reporting WUE trattato come checkbox. Va bene come numero; diventa significativo solo dentro una FSOR che lo unisce agli assi carbonio ed energia. Un sito con ottimo WUE su una rete ad alto carbonio in un bacino sotto stress idrico non sta vincendo niente; sta solo spostando l'esternalità.
• "Liquid cooling = sostenibile" detto senza la contabilità congiunta. Il liquid cooling è ciò che rende possibili i rack >30 kW; se migliori l'impronta complessiva dipende interamente dalla matematica FSOR di quel sito specifico.

La versione onesta di carbon-aware AI è: per il piccolo insieme di workload ad alta portabilità, in regioni con una FSOR reale, possiamo spostare carico in modi che riducono materialmente l'impronta. Quello è valore genuino. È anche una rivendicazione molto più stretta della slide.

Cosa metterei sulla roadmap di infrastruttura questo trimestre

Per un team di piattaforma che ha letto la sezione FSOR del paper e vuole agire prima del prossimo ciclo di disclosure di sostenibilità:

1. Costruire una mappa di portabilità dei workload. Per ogni workload IA, segnare la sua categoria (training / inference / batch / serving) e il suo budget reale di portabilità — raggio geografico, downtime ammesso per migrazione, vincoli di statefulness. Questo singolo artefatto ti dice quali workload potrebbero essere spostati su base FSOR.

2. Calcolare la FSOR per un sito. Scegli la tua location più caricata. Calcola la regione fattibile congiunta sui tre assi per le prossime 72 ore usando qualsiasi telemetria riesci ad assemblare. Pubblicala come dashboard interna. Scoprirai punti ciechi immediatamente. Quello è il valore.

3. Definire l'envelope di vincoli. Tradurre le tue policy di carbonio, energia e acqua impegnate in vincoli machine-readable. Se la tua policy è "media <X gCO₂/kWh," scrivila come funzione del tempo del giorno e della stagione. Le policy soft che vivono solo in un PDF non possono entrare nella FSOR.

4. Taggare i workload per portabilità, non solo per tier. Il tag di portabilità è quello che il tuo futuro scheduler di workload — agentico o no — userà per decidere cosa può muoversi. Questa è la precondizione perché il batch shifting carbon-aware sia più di una demo.

5. Trattare la FSOR come parte del fascicolo di gestione del rischio. In un ambiente regolamentato, ti verrà chiesto dell'energia, del carbonio e delle dipendenze idriche dei sistemi IA ad alto rischio entro questo ciclo regolatorio. Meglio avere un'analisi FSOR nel fascicolo che scriverla la settimana dell'audit.

La linea che traccio

La FSOR non è un nome elegante per quello che già facciamo; è una disciplina che per lo più ancora non facciamo. I tre KPI di sostenibilità che riportiamo trimestralmente non sono testati congiuntamente in operations. L'hype attorno alla carbon-aware AI appiattisce la distinzione di portabilità del workload che decide se qualcosa è spostabile. Il discorso europeo sulla sovranità prende uno dei tre assi e assume che gli altri due siano problema di qualcun altro.

Se stai facendo girare infrastruttura IA nel 2026 e la domanda "qual è la FSOR per il workload X al sito Y nelle prossime 72 ore?" non può essere risposta dalla tua piattaforma da un sistema live in meno di cinque minuti, non hai ancora una FSOR — hai tre KPI che capita siano riportati sulla stessa slide.

Il lavoro è fattibile. È principalmente lavoro di telemetria, schema e policy, con un piccolo livello di logica agentica sopra. Il team che lo fa prima che il ciclo regolatorio recuperi sarà visibilmente avanti rispetto al team che non lo fa.

---

Fonti:

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

Stai facendo girare workload IA con impegni di sostenibilità che non sei sicuro che la tua infrastruttura possa onorare? Parla con un CTO — ti aiutiamo a calcolare una FSOR reale prima che lo faccia il ciclo di disclosure.