A Região Operativa Soberana Viável: porque o teu roadmap de IA bate num muro de energia–carbono–água (2/3)

Este é o post 2 de 3 numa série sobre o paper de Sergio Cruzes "AI Infrastructure Sovereignty". A parte 1 enquadrou porque a soberania é infraestrutura, não residência de dados; a parte 3 cobre a arquitetura LLM-como-consultor.

A ideia mais útil em AI Infrastructure Sovereignty de Sergio Cruzes é uma que não vi nomeada explicitamente em mais lado nenhum: a Feasible Sovereign Operating Region (FSOR). A interseção em que três limites físicos duros podem ser satisfeitos conjuntamente, não um de cada vez:

1. Energia — capacidade de rede e as flutuações rápidas que os workloads de IA injetam.
2. Intensidade de carbono — o mix em tempo real da rede que alimenta o site.
3. Água — disponibilidade de arrefecimento sob stress sazonal.

A maioria dos roadmaps de IA que revi nos últimos doze meses otimiza um dos três e assume silenciosamente os outros dois. Não compõem. A FSOR é a parte do plano onde têm de o fazer.

Este é um seguimento de o post sobre soberania não ser residência de dados. Se a peça anterior defendia que a soberania real vive em infraestrutura física, esta é sobre o que acontece quando tentas mesmo operar nessa infraestrutura física sob as restrições que o paper torna explícitas.

Os três limites não são independentes — esse é o ponto

A sustentabilidade da IA tem sido historicamente reportada como três KPIs separados: PUE para eficiência energética, gCO₂eq/kWh para carbono da rede, WUE para água. Três números, três equipas, três relatórios trimestrais. A contribuição do paper é insistir que são um único problema conjunto de viabilidade, não três aditivos.

Um site de cluster de training está operável num dado momento apenas se as três condições seguintes forem simultaneamente verdadeiras:

• A rede elétrica tem a folga de potência para absorver o perfil bursty do workload, incluindo picos de milissegundo a segundo durante operações colectivas.
• A intensidade de carbono em tempo real dessa rede está dentro do envelope de política a que te comprometeste (ou aquele que um regulador de sustentabilidade aceitará).
• O orçamento de água local — bolbo húmido ambiente, reservas da bacia, variação sazonal — suporta a carga de arrefecimento à densidade de potência exigida.

Tira qualquer uma destas, e o cluster não está a operar na FSOR; está a operar fora da política e a acumular dívida futura — financeira, regulatória ou reputacional. As três restrições podem estar em tensão no mesmo site:

• Uma região com energia abundante de baixo carbono pode ter capacidade de rede insuficiente para absorver 100+ MW de carga bursty sem desestabilizar a rede local.
• Uma região com água e capacidade de rede abundantes pode ter um mix de alto carbono que empurra o workload para fora do envelope de sustentabilidade declarado.
• Uma região com energia limpa e água adequada pode ficar num caminho de fibra com dependências de latência ou operador que a tornam inadmissível para o workload de qualquer forma.

A FSOR é a interseção. Costuma ser mais pequena do que qualquer um dos seus conjuntos constituintes sugere, e a maioria dos operadores ainda não a calculou de facto.

Porque o training é o caso mais difícil

O paper faz uma classificação de workloads que devia estar na parede de cada equipa de plataforma:

Workload	Perfil de potência	Procura de arrefecimento	Procura de rede	Portabilidade
Training	Bursty, alto	Extrema	Muito alta	Baixa
Inferência	Sustentado	Moderada–alta	Alta	Média
Batch analytics	Variável	Moderada	Baixa–moderada	Alta

A coluna decisiva é portabilidade. Os clusters de training não conseguem explorar sites distantes de baixo carbono por uma razão estrutural — latência de comunicação colectiva. A velocidade da luz fixa o chão: ~5 ms por 1.000 km. O training tolera cerca de 1 ms de latência de comunicação colectiva, o que colapsa o raio geográfico para cerca de 100 km. Dentro de 100 km, aceitas o mix de energia, a situação da água e a folga de rede que encontrares, ou não treinas.

Esta é a parte do discurso de sustentabilidade da IA onde as coisas começam a doer. A história do "vamos mover o nosso training para onde a energia for mais verde" é um slide, não uma arquitetura. O paper di-lo claramente: o training de IA de fronteira é inerentemente preso ao site e concentrado nas poucas localizações que satisfazem as três restrições da FSOR em simultâneo. É por isso que a capacidade efetiva de training no mundo se agrupa num conjunto pequeno de geografias; não é preferência da indústria, é a FSOR a fazer o seu trabalho.

A inferência é mais tolerante — replicável entre regiões, mas ainda ligada à geografia da procura. O batch analytics é a única categoria onde a relocalização carbon-aware é efetivamente alcançável à escala. A maioria das demos de "IA carbon-aware" lá fora renomeia batch analytics como o título principal. Está bem, mas não trata do training, que é onde o impacto de carbono, água e rede realmente vive.

Onde os roadmaps europeus quietamente partem

Se levas a FSOR a sério, várias linhas dos atuais roadmaps europeus de infraestrutura de IA deixam de aguentar o seu próprio peso:

• "Colocar o training no Norte da Europa pela rede verde." Parcialmente verdade. A rede é mais verde; a folga de rede em muitas regiões-alvo já está constrangida pela ocupação de data centres existentes e pelas expansões de hyperscalers. Carbono ✓, energia ✗.
• "Usar a capacidade solar do Sul da Europa para training de IA." Disponibilidade de energia às vezes ✓; orçamento de água sob condições de bolbo húmido estival frequentemente ✗. A penalidade de arrefecimento no pico de época colapsa a FSOR.
• "IA na edge elimina o problema do data centre." Para inferência no extremo da edge, às vezes. Para training, não. O paper é explícito: o training é preso ao site e as suas restrições não se resolvem com fan-out de edge.
• "Refrigeração líquida resolve o problema da densidade." Resolve o tecto do arrefecimento a ar (o limiar de ~20–30 kW por rack). Não resolve o orçamento de água; em muitas configurações torna a situação do WUE mais legível, não melhor, porque traz a procura de arrefecimento para um regime que tem de ser medido em vez de aproximado.

Não digo nada disto para ser dismissivo — apoio cada um desses programas em princípio. Digo-o porque a próxima ronda de incidentes operacionais na infraestrutura europeia de IA vai viver precisamente no fosso entre o pressuposto do título ("região de energia limpa") e a FSOR conjunta ("região de energia limpa que, em agosto às 19:00 hora local, com a concorrência atual na rede, não consegue operar este workload em política").

A telemetria de que precisas para sequer conhecer a tua FSOR

Não consegues provar que estás a operar dentro de uma FSOR se não a consegues medir. A arquitetura de referência do paper explicita isto: a fusão de telemetria entre camadas é uma precondição, não um nice-to-have. Para cada um dos três eixos da FSOR, o conjunto mínimo de sinal não é trivial:

Eixo de energia

• Consumo de potência por rack e a derivada (para ver picos de operações colectivas, não só médias).
• Sinal de folga da rede a montante — normalmente um feed comercial ou uma integração direta com a utility.
• Contabilidade em tempo real do PPA (que fração do consumo atual está efetivamente coberta pelas renováveis contratadas vs. rede spot).

Eixo de carbono

• Feed em tempo real de intensidade de carbono da rede (WattTime, Electricity Maps, TSO nacional). Cadência de atualização ~5 minutos.
• Distinção entre emissões marginais vs. médias — a maior parte dos envelopes de política está escrita em médias, mas para decisões de deslocação de workload o marginal é o que importa.
• Atribuição: emissões de que workload pertencem a que inquilino, entidade de facturação ou perímetro regulatório.

Eixo de água

• Temperaturas de entrada/saída do líquido, caudais.
• Bolbo húmido ambiente e uma previsão (para que a FSOR tenha uma projeção nas próximas seis horas, não só um snapshot atual).
• Sinal de gestão da bacia / utility — normalmente uma integração externa, frequentemente não real-time.

Na linguagem do meu último post, isto é o vector de estado θ(t) para sustentabilidade. Sem ele, a tua FSOR é um palpite. Com ele, tens o substrato para tomar decisões reais de scheduling, throttling e migração de forma defensável.

A razão pela qual a maioria das equipas de plataforma não tem esta camada é que custa trabalho de engenharia real e não produz demo. Produz um sistema que, ao fim de três meses, diz "não conseguimos operar o workload X neste site entre as 17:00 e as 23:00 nos dias úteis de verão." Esse é um output politicamente incómodo, o que é parte da razão pela qual a telemetria de FSOR continua subconstruída.

O que a camada agêntica deve fazer — e o que não deve

Cruzes propõe uma arquitetura de controlo em que IA agêntica ajuda a operar dentro da FSOR. Vou cobrir a fronteira LLM-vs-agente-determinístico no próximo post. Para a FSOR especificamente, a arquitetura diz três coisas úteis:

1. A otimização respeita a primazia das restrições. Limites duros — envelopes de sustentabilidade, física — não são objectivos suaves na função de perda. Sobrepõem-se. Um agente que propõe uma colocação de workload que viola o orçamento de água deve ser rejeitado pela camada de coordenação, não penalizado por um termo de regularização.

2. O acordo entre domínios é o verdadeiro trabalho. Um agente de colocação de compute que escolhe o site de menor carbono só está correcto se o agente de arrefecimento, o agente de rede e o agente da rede elétrica concordarem que é conjuntamente viável. A otimização mono-domínio é exatamente o modo de falha para o qual a FSOR existe para prevenir.

3. Validação por gémeo digital antes da execução. Nenhuma proposta de agente toca em infraestrutura viva até um gémeo digital a ter simulado contra a dinâmica física. Esta é a disciplina que separa correr IA para infraestrutura de IA de correr uma demo de IA para infraestrutura de IA.

O ponto que quero extrair aqui para os meus clientes regulados: a história de IA-agêntica-em-data-centre não é uma história de autonomia. É uma história de enforcement de restrições vestida com vocabulário de agentes. O trabalho interessante é tornar as restrições legíveis por máquina e a validação determinística, não tornar os agentes mais espertos.

A parte de que sou crítico no hype sustentabilidade-IA

Implemento LLMs e sistemas agênticos para viver. Não vou argumentar que a tecnologia não é útil. O que vou argumentar é que o hype sustentabilidade-IA está atualmente a otimizar a camada errada.

• "IA para otimização da rede elétrica" vendida como a resposta quando a IA é também um motor importante do stress na rede. As duas coisas são verdade ao mesmo tempo. A segunda frase falta na maioria dos decks.
• Relocalização de training carbon-aware apresentada como uma alavanca de curto prazo. É uma alavanca de longo prazo condicional à resolução da restrição de latência dos 100 km, que ninguém resolveu. A alavanca de curto prazo é batch analytics carbon-aware, que é real e útil mas não é training.
• Reporte de WUE tratado como uma checkbox. Está bem como número; só se torna significativo dentro de uma FSOR que o junta aos eixos de carbono e energia. Um site com excelente WUE numa rede de alto carbono numa bacia em stress hídrico não está a ganhar nada; está a deslocar a externalidade.
• "Refrigeração líquida = sustentável" dito sem a contabilidade conjunta. A refrigeração líquida é o que torna racks >30 kW possíveis; se melhora a pegada global depende inteiramente da matemática da FSOR nesse site específico.

A versão honesta de IA carbon-aware é: para o pequeno conjunto de workloads com alta portabilidade, em regiões com uma FSOR real, podemos deslocar carga de formas que reduzam materialmente a pegada. Esse é valor genuíno. É também uma reivindicação muito mais estreita do que a do slide.

O que poria no roadmap de infraestrutura este trimestre

Para uma equipa de plataforma que leu a secção da FSOR do paper e quer agir antes do próximo ciclo de divulgação de sustentabilidade:

1. Constrói um mapa de portabilidade de workloads. Para cada workload de IA, marca a sua categoria (training / inferência / batch / serving) e o seu orçamento real de portabilidade — raio geográfico, downtime permitido para migração, restrições de statefulness. Este único artefacto diz-te que workloads poderiam sequer ser movidos numa base FSOR.

2. Calcula a FSOR para um site. Escolhe a tua localização mais carregada. Calcula a região conjunta viável nos três eixos para as próximas 72 horas usando a telemetria que conseguires juntar. Publica como dashboard interno. Vais descobrir pontos cegos imediatamente. Esse é o valor.

3. Define o envelope de restrições. Traduz as tuas políticas comprometidas de carbono, energia e água em restrições legíveis por máquina. Se a tua política é "média <X gCO₂/kWh", escreve-a como função da hora do dia e da estação. Políticas soft que só vivem num PDF não podem entrar na FSOR.

4. Etiqueta workloads por portabilidade, não só por tier. A etiqueta de portabilidade é o que o teu futuro scheduler de workloads — agêntico ou outro — usará para decidir o que se pode mover. Esta é a precondição para batch shifting carbon-aware ser mais do que uma demo.

5. Trata a FSOR como parte do dossier de gestão de risco. Num ambiente regulado, vais ser questionado sobre dependências energéticas, de carbono e de água de sistemas de IA de alto risco dentro deste ciclo regulatório. É melhor teres uma análise FSOR no dossier do que escrevê-la na semana da auditoria.

A linha que desenho

A FSOR não é um nome esperto para o que já fazemos; é uma disciplina que maioritariamente ainda não fazemos. Os três KPIs de sustentabilidade que reportamos trimestralmente não são testados em conjunto em operação. O hype em torno de IA carbon-aware achata a distinção de portabilidade de workload que decide se algo é deslocável de todo. O discurso europeu de soberania escolhe um dos três eixos e assume que os outros dois são problema de outro.

Se estás a correr infraestrutura de IA em 2026 e a pergunta "qual é a FSOR para o workload X no site Y nas próximas 72 horas?" não pode ser respondida pela tua plataforma a partir de um sistema vivo em menos de cinco minutos, ainda não tens uma FSOR — tens três KPIs que por acaso são reportados no mesmo slide.

O trabalho é fazível. É maioritariamente trabalho de telemetria, schema e política, com uma pequena camada de lógica agêntica por cima. A equipa que o fizer antes do ciclo regulatório a apanhar estará visivelmente à frente da que não o fizer.

---

Fontes:

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

A correr workloads de IA com compromissos de sustentabilidade que não tens a certeza se a tua infraestrutura consegue cumprir? Fala com um CTO — ajudamos-te a calcular uma FSOR real antes que o ciclo de divulgação o faça por ti.