Soberania de IA não é residência de dados. São megawatts, fibra e temperatura de bolbo húmido. (1/3)

Este é o post 1 de 3 numa série sobre o paper de Sergio Cruzes "AI Infrastructure Sovereignty". A parte 2 cobre a Região Operativa Soberana Viável; a parte 3 cobre a arquitetura LLM-como-consultor.

Há umas semanas Sergio Cruzes (Ciena) pôs no arXiv um paper chamado AI Infrastructure Sovereignty (2602.10900v4). É o tipo de paper que não fica viral no LinkedIn porque não promete a ninguém um aumento de produtividade de 10x, mas devia ser lido por quem assina uma "estratégia de soberania de IA" este ano. A sua tese central é simples e incómoda: a soberania de IA já não é um problema de software nem um problema legal. É um problema de infraestrutura. Cláusulas de localização de dados, regiões cloud regionais e postura GDPR são necessárias mas estão longe de ser suficientes. A soberania real vive em megawatts, rotas de fibra e na temperatura de bolbo húmido à porta da tua data hall.

Do sítio onde me sento — a construir DevOps e platform engineering para empresas que têm de defender a sua pilha de IA à frente de um regulador — este reenquadramento estava em atraso, e a maioria dos roadmaps públicos de soberania que revi nos últimos doze meses ainda opera uma camada demasiado acima.

Soberania legal vs soberania operacional

O paper faz uma distinção que devia tornar-se vocabulário padrão:

• Soberania legal é a camada que toda a gente já percebe: jurisdição, compliance, proteções de PI, frameworks de localização de dados. GDPR, EU AI Act, CLOUD Act, etiquetas tipo SecNumCloud. Aqui vivem advogados e procurement.
• Soberania operacional é "a capacidade prática de observar o estado do sistema, tomar decisões com base em condições locais, validar essas decisões, e agir dentro de políticas e limites físicos definidos." Aqui vivem engenheiros e operadores. Ou melhor, deviam viver. Na maioria das conversas de soberania, esta camada não aparece.

As duas camadas não são a mesma coisa, e uma sem a outra é decoração de montra. Controlo legal sem capacidade operacional é nominal. Podes ter o contrato, os relatórios de auditoria e a cláusula de residência de dados e continuar a depender do hardware de outro, da rede ótica de outro e do acordo de compra de energia de outro para correr efetivamente o sistema. Quando esse outro está condicionado por controlos de exportação, sanções, ou uma decisão unilateral de plataforma, a tua soberania evapora-se independentemente do que diga o contrato.

Esta é a parte que a maioria das conversas sobre "cloud soberana europeia" salta elegantemente. Discutimos onde vivem os bytes e ignoramos de onde vêm os joules.

O que "infraestrutura" significa de facto no paper

Cruzes é invulgarmente concreto para um paper de soberania. As três camadas que trata como substrato não são abstrações:

1. Data centres de IA — racks a empurrar para lá dos 20–30 kW (o tecto do arrefecimento a ar) para refrigeração líquida como standard. Clusters de training a exigir dezenas a centenas de megawatts por site. Potência que não traça uma curva plana mas pica durante operações colectivas à escala do milissegundo ao segundo. Nada disto é exótico no mundo dos hyperscalers; quase nada disto é controlado localmente nas clouds soberanas europeias que revi.

2. Redes óticas — a parte que a maioria das discussões software-centristas de soberania ignora por completo. A velocidade da luz dá um chão duro de ~5 ms por 1.000 km. Os clusters de training toleram cerca de 1 ms de latência de comunicação colectiva, o que se traduz num raio geográfico de 100 km. A inferência é mais tolerante mas continua a ter de estar perto da procura. Os cabos submarinos — os que carregam a maior parte do tráfego intercontinental de IA — são "difíceis de reparar. As disrupções podem durar semanas." A soberania de um caminho de fibra não é uma cláusula contratual; é a servidão de passagem física e o barco que precisas para a arranjar.

3. Sistemas de energia — capacidade de rede, intensidade de carbono, água para arrefecimento. O paper propõe uma Feasible Sovereign Operating Region (FSOR): a interseção onde disponibilidade de energia, intensidade de carbono e orçamento de água podem ser satisfeitos conjuntamente. Volto à FSOR no próximo post porque merece tratamento próprio. O ponto aqui é estrutural: uma região sem folga de rede suficiente, com um mix energético de alto carbono ou com stress hídrico sazonal não é soberana para IA de fronteira, por muito boas que sejam as suas leis de proteção de dados.

Quando o pões assim, não podes seriamente reivindicar soberania para um workload de IA que corre em aceleradores importados, numa rede ótica operada por terceiros, alimentado por uma rede elétrica que não controlas, arrefecido por água que não cotas. Podes reivindicar qualquer coisa, mas não soberania no sentido operacional.

Porque a narrativa de cloud regional se parte aqui

Se levas a sério as definições de Cruzes, a narrativa europeia dominante de soberania — "vamos ter regiões cloud soberanas operadas por entidades da UE" — resolve no máximo uma das três camadas, e provavelmente menos de metade dessa. Uma região soberana implementada sobre:

• Aceleradores importados sob regimes de controlo de exportação estrangeiros,
• Capacidade ótica alugada a fornecedores de trânsito sediados noutro sítio,
• Acordos de compra de energia sem telemetria operacional para a rede elétrica,
• Água de arrefecimento de uma bacia sem gestão local,

é uma região no sentido legal e um inquilino no sentido operacional. O supervisor aceitará a camada legal. A física não.

Não estou a dizer que o esforço de cloud regional está errado. Estou a dizer que resolve a parte do problema que os advogados podem verificar e deixa intocada a parte com que engenheiros e operadores têm de viver. Da primeira vez que um ponto de controlo transfronteiriço — sanções de exportação, uma alteração de licenciamento de um fornecedor de plataforma, um corte de fibra submarina — atingir a região, o fosso entre "legalmente soberano" e "operacionalmente soberano" passa a ser a única coisa que importa.

A camada de telemetria é a verdadeira camada de soberania

A afirmação técnica mais subestimada do paper é esta: a soberania operacional depende de fusão de telemetria entre camadas, e a entidade que faz essa fusão segura as verdadeiras chaves.

Hoje existem quatro ecossistemas de protocolo distintos que têm de ser juntados para produzir uma representação unificada do estado de um data centre de IA:

Domínio	Protocolos	Maturidade
Redes óticas	OpenConfig / gNMI	A mais alta
Compute / energia	Redfish, IPMI, APIs BMC de fornecedor	Heterogénea
Arrefecimento / facilities	BACnet, Modbus	Grade de facilities, não real-time
Sustentabilidade da rede	WattTime, Electricity Maps (atualização ~5 min)	Comercial, externa

Estes quatro não foram desenhados para falar uns com os outros. Emitem schemas diferentes, cadências diferentes, garantias de frescura diferentes. Juntá-los num único vector de estado — Cruzes chama-lhe θ(t) — não é trabalho de commodity. É o trabalho que decide se consegues detectar uma falha em cascata (pico de potência → evento térmico → migração de workload → congestionamento de rede) antes que te apanhe de surpresa, ou se ficas a sabê-lo no post-mortem.

E aqui está o argumento decisivo da soberania operacional: quem é dono da camada de fusão de telemetria é dono da verdadeira superfície de controlo. Se delegas esse trabalho a uma plataforma externa — uma "AI infrastructure suite" de hyperscaler, um produto de observabilidade empacotado por um fornecedor — delegaste a visibilidade operacional com ela. O teu dashboard diz "tudo verde". Já não sabes o que o tornaria vermelho, em que termos, ou com que latência.

Diria isto mais cru do que o paper: a fusão de telemetria é o novo sistema de registo para infraestrutura de IA, e a maioria dos operadores europeus não o tem. Têm dashboards construídos sobre o pipeline de outro. O que está bem até deixar de estar.

O que isto significa para um cliente regulado este ano

Para o tipo de cliente com quem trabalho — banca, saúde, energia, setor público — traduzir isto numa postura prática significa abandonar dois pressupostos confortáveis e adoptar três incómodos:

1. Larga o pressuposto de que a residência de dados é a conversa de soberania. É a camada mais fácil, a que o teu DPO já consegue explicar, e a que um adversário competente ou um acidente regulatório contorna mais depressa. Pertence à resposta, não como resposta inteira.

2. Adopta o pressuposto de que precisas de um inventário de dependências físicas. Para cada workload de IA em produção ou planeado: quais aceleradores (e sob que regime de exportação), quais caminhos óticos (e de quem é a servidão), qual a fonte de energia (e de quem é o PPA), qual o recurso de arrefecimento (e de quem é a água). A maioria das equipas não consegue responder a isto para a sua pilha atual hoje. O primeiro trabalho é o inventário, não a arquitetura.

3. Adopta o pressuposto de que a fusão de telemetria é tua responsabilidade. Mesmo que operes em cima do ferro de outro, podes — e em setores regulados deves — ser dono da camada que funde os teus sinais operacionais numa representação de estado que tu podes raciocinar, auditar e apresentar a um supervisor sem tradução. Sem isso, os teus relatórios de incidente serão sempre escritos no vocabulário do teu fornecedor, no calendário do teu fornecedor.

4. Reclassifica o sistema, não o modelo. Continuo a dizê-lo, incluindo na minha leitura do relatório de confiança em IA da McKinsey 2026: o regulador quer o sistema sociotécnico completo classificado, o que agora inclui explicitamente a camada física. O dossier de gestão de risco do Artigo 9 para um sistema de IA de alto risco que não reconheça as dependências energéticas, óticas e de arrefecimento está incompleto pela própria lógica do paper.

5. Aceita que a soberania é um espectro, não um binário. Cruzes é claro sobre isto: nenhuma região alcança soberania absoluta. Todas existem algures numa curva definida por quais camadas são controladas localmente e quais dependências externas são aceites. O roadmap honesto de soberania é o que nomeia as dependências e as coteja, não o que se gaba de as remover todas.

A parte de que sou crítico no hype de IA em torno da soberania

Sou conhecido por ser positivo sobre LLMs e sistemas agênticos em produção — implemento-os, facturo por eles, os meus clientes pagam-nos, o meu próprio tempo está "investido" neles no sentido mais literal. Não sou a pessoa que precisa de ser convencida de que a IA é real.

Dito isto, o discurso público de soberania em torno da IA hoje tem um modo de falha específico que o paper torna legível: trata a soberania como um problema de conteúdo e não como um problema de substrato. O pitch é "os teus dados ficam no país", e o corolário não dito é "tudo abaixo dos teus dados é problema de outro". Cruzes mostra que o substrato não é problema de outro; é o problema, porque o substrato é o que um actor externo pode efetivamente reter.

A versão hype de IA soberana é um modelo treinado com dados locais, alojado numa região cloud local, comercializado sob uma bandeira local, a correr no mesmo silício importado e na mesma capacidade ótica de longo curso que a pilha de toda a gente. A versão do paper de IA soberana é o mesmo modelo, mas com a pergunta sob que restrições físicas posso continuar a operar se as minhas dependências externas forem revogadas? honestamente respondida. A primeira versão é um slide. A segunda é um runbook.

Se o teu programa de soberania consegue responder ao slide e não consegue responder ao runbook, estás exactamente onde está o resto da indústria. O trabalho deste ano é inverter esses dois estados.

O que poria no roadmap de plataforma este trimestre

Para uma equipa de plataforma ou infraestrutura num setor regulado, três passos concretos antes do próximo board update:

1. Mapeia a pilha de dependências físicas para cada workload de IA em produção. Uma tabela, quatro colunas: família de acelerador + regime regulatório, caminho ótico + operador, fonte de energia + termos do PPA, recurso de arrefecimento + gestão local. A tabela não vai ficar bonita. É exatamente esse o ponto.

2. Inicia uma baseline de fusão de telemetria, mesmo que tosca. Escolhe um único workload, puxa OpenConfig da tua camada ótica, Redfish do compute, o que conseguires das facilities, e um feed comercial de intensidade de carbono. Constrói um θ(t) com resolução de 60 segundos para esse workload. Vais descobrir uma quantidade embaraçosa de incógnitas desconhecidas. É esse o valor do exercício.

3. Escreve um memo de soberania de uma página que distinga soberania legal de soberania operacional para o teu CFO e o teu supervisor. Mesmo que tudo o que consigas entregar este trimestre seja a coluna legal, dominar o vocabulário mantém a conversa do conselho honesta. Prefiro entrar numa reunião com o supervisor a dizer "controlamos as camadas 1 e 2, dependemos do fornecedor X para as camadas 3 e 4, eis a contingência" do que entrar a reivindicar uma soberania que não tenho.

A linha que desenho

O enquadramento do paper — legal vs operacional, com a física como restrição vinculativa — é o correcto para manter internamente mesmo quando a versão de marketing da soberania é o que se cita externamente. A IA é real, a implementação está a acelerar, o valor é genuíno. Nada disso muda o facto de que a camada à qual a soberania de facto se decide se moveu para debaixo do vocabulário actual da indústria.

Se o teu programa de soberania este ano ainda termina na cláusula de residência de dados, não estás errado. Estás apenas uma camada demasiado acima. O trabalho interessante — e o trabalho com que um regulador se importará nos próximos doze meses — está a acontecer abaixo do teu dashboard.

---

Fontes:

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

A construir infraestrutura de IA que tem de se defender à frente de um regulador e sem certezas sobre onde o teu programa de soberania efetivamente termina? Fala com um CTO — ajudamos-te a separar a camada legal da operacional antes que alguém o faça por ti.