← Voltar a todos os artigos
Desafios

Deixa o LLM falar, não tocar: a arquitetura de ciclo fechado que sobrevive em produção (3/3)

Por Marc Molas·13 de maio de 2026·11 min de leitura

Este é o post 3 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 2 cobriu a Região Operativa Soberana Viável.

A terceira peça do paper AI Infrastructure Sovereignty de Sergio Cruzes que devia viajar mais longe do que tem viajado é a parte em que ele traça uma linha arquitetural dura: num sistema de infraestrutura de IA em ciclo fechado, os LLMs são consultivos e interpretativos. Não executam. A execução é trabalho de agentes determinísticos limitados, validados por um gémeo digital, com dois caminhos de feedback estritamente separados.

Implemento IA agêntica em ambientes regulados para viver. Estou "investido" nesta tecnologia no sentido mais literal e facturável. E acho que a arquitetura do paper é a correta — e é exatamente por isso que quero sinalizar que a maioria dos produtos vendidos como plataformas agênticas em 2026 viola-a em silêncio. Põem o LLM mais perto do actuador do que o desenho do paper permite, e depois comercializam essa proximidade como a feature.

Este é o terceiro post sobre o paper, depois das peças soberania-não-é-residência-de-dados e FSOR. Se aquelas cobriram o que tens de controlar, esta é sobre como o ciclo de controlo tem de ser ligado sem pegar fogo à data hall.

A arquitetura de referência de quatro camadas, num parágrafo

O paper propõe quatro camadas empilhadas:

  1. Física — data centres de IA, redes óticas, sistemas de energia. O substrato.
  2. Observabilidade — normalização em streaming, alinhamento de timestamps, certificação de frescura, fusão entre domínios. Produz o vector de estado unificado θ(t).
  3. Controlo Coordenado — agentes de domínio (compute, energia, arrefecimento, ótico) + camada de coordenação + gémeo digital + uma camada de assistência LLM.
  4. Execução Segura — apenas ações validadas pelo gémeo digital chegam à infraestrutura viva.

A fronteira interessante é entre 3 e 4. A não-fronteira interessante — a que a camada de hype quer esbater — é entre a assistência LLM e tudo o resto dentro da camada 3.

O que Cruzes diz de facto sobre LLMs

O paper é invulgarmente explícito. A camada LLM tem "um papel meramente consultivo e interpretativo". Existe para:

  • Traduzir intenção humana em objectivos estruturados que os agentes determinísticos possam consumir.
  • Gerar explicações sobre o que o sistema agêntico decidiu e porquê.
  • Ser uma superfície de linguagem natural por cima do sistema de controlo real, não um participante nele.

E depois o paper diz a parte quieta em voz alta:

Permitir que outputs de LLM conduzam ações de infraestrutura diretamente — sem validação através do controlo determinístico de restrições do sistema agêntico e da simulação pré-execução do gémeo digital — introduz um modo de falha em que instruções plausíveis mas incorrectas são executadas em infraestrutura viva.

Este é o modo de falha LLM-em-produção que pessoalmente assisti em cinco revisões de incidente diferentes nos últimos dezoito meses, nenhuma delas em controlo de data centre mas todas em ambientes regulados: o LLM produz algo que parece o comando correcto, o sistema envolvente está demasiado ansioso para o executar, e o post-mortem transforma-se num exercício de "confiámos em texto onde devíamos ter confiado em política". A versão data-centre desse incidente não seria um vexame de slack-bot. Seria um evento térmico.

A estrutura agêntica de dois níveis

Dentro da camada de controlo coordenado, o paper separa:

  • Nível 1 — agentes de domínio. Raciocinadores especializados para colocação de compute, gestão de energia, controlo de arrefecimento, encaminhamento ótico. Cada um tem conhecimento hard-coded das restrições e física do seu domínio. Estes fazem a verdadeira proposta de ações.
  • Nível 2 — camada de coordenação. Verificação de viabilidade conjunta entre todas as propostas do nível 1. Se o compute quer colocar um workload no site A, mas o agente de arrefecimento diz que A está fora do orçamento dado o bolbo húmido atual, e o agente ótico diz que o link para A está em modo degradado, o coordenador apanha a contradição. Se não existe ação conjuntamente viável, escala para humanos em vez de escolher silenciosamente a opção menos má.

O LLM não é nível 1 e não é nível 2. O LLM senta-se fora deste loop. Explica o que o loop fez. Aceita intenção humana e reformula-a como um objectivo estruturado alimentado ao loop. Não coloca workloads. Não faz throttling de racks. Não reencaminha caminhos óticos.

Este é um desenho defensável, amigável para o regulador. É também um desenho a que a maioria das plataformas "agênticas" no mercado hoje não corresponde, porque a pressão de marketing é incluir o LLM na decisão — é aí que vive a demo do truque de magia.

Dois caminhos de feedback, mantidos estritamente separados

O detalhe que um engenheiro vai apreciar e um marketeiro vai passar por cima é a disciplina dos dois caminhos de feedback:

  • Feedback Aresultados medidos fluem da camada física de volta para cima através da observabilidade. Isto fecha o loop de controlo. Os agentes aprendem que a ação que executaram produziu (ou não) a alteração de estado esperada.
  • Feedback Bresíduos de previsão (a diferença entre o que o gémeo digital esperava e o que de facto aconteceu) fluem de volta apenas para o gémeo digital. É assim que o gémeo deteta a sua própria deriva em relação à realidade física.

O paper insiste que estes canais permaneçam estritamente separados. Confunde-os e destróis a deteção de deriva. Se o gémeo digital recebe o mesmo stream de medição que o loop de controlo dos agentes, sem isolamento, então uma deriva lenta na precisão do gémeo vai parecer variância operacional normal aos agentes, e não verás a deriva até o gémeo tomar uma decisão que o sistema físico rejeita num incidente.

Este é o tipo de rigor arquitetural que não vende licenças de plataforma mas que te mantém fora de um post-mortem.

Onde a maioria das plataformas "agênticas" atuais quebra isto em silêncio

Vou generalizar a partir do que vejo em arquiteturas de clientes e demos de fornecedor, sem nomear nomes:

  1. LLM no caminho de ação. O produto vende "um agente que opera a tua infraestrutura". Por baixo do capô, o LLM tanto interpreta o pedido como emite o comando. Não há agente determinístico de nível 1 com restrições hard-coded entre o LLM e o actuador. Este é o modo de falha que o paper nomeia explicitamente.

  2. Gémeo digital como ativo de marketing, não como porta de validação. Muitos produtos mostram um "gémeo digital" renderizado em 3D na demo. Poucos exigem que o gémeo valide cada ação proposta antes da execução. O gémeo é decorativo. Na arquitetura do paper, o gémeo é uma porta; se a simulação do gémeo divergir da política, a ação é bloqueada.

  3. Telemetria de loop único. Tanto o agente como o gémeo consomem o mesmo stream sem separação. Feedback A e B estão confundidos, a deteção de deriva é pouco fiável, e o sistema perde silenciosamente a propriedade em que o paper insiste.

  4. Sem contrato de escalonamento. Quando a camada de coordenação não encontra uma ação conjuntamente viável, o que acontece? No paper, degradação graciosa com escalonamento estruturado para humanos, que mantêm autoridade final. Em muitos produtos, o sistema simplesmente escolhe a ação de custo mais baixo segundo uma heurística de fallback e escreve um log de debug. Isso não é degradação graciosa; é falha silenciosa com sistema de logging.

  5. Human-on-the-loop como checkbox. Existe um dashboard humano; é revisto semanalmente. Operacionalmente, os agentes mexem-se mais depressa do que a cadência de revisão há meses. Esta é a versão data-centre do HITL teatral que o relatório da McKinsey sinalizou para sistemas agênticos em geral. Mesma doença, raio de explosão maior.

Se a tua plataforma falha em qualquer um destes testes, tens um sistema de infraestrutura agêntica no sentido de marketing e uma demo com permissões elevadas no sentido operacional.

Porque acho que a arquitetura do paper está correta

Três razões, tiradas de como isto realmente se desenrola em clientes que têm de defender a pilha:

1. O LLM é excelente na camada onde os seus erros são recuperáveis. Traduzir "quero agendar o próximo training run algures dentro do nosso envelope de carbono" num objectivo estruturado é uma utilização excelente de um LLM. Se a tradução estiver errada, o objectivo estruturado falha a validação e o pedido volta com erro. Nenhuma ação física foi tomada. Recuperável. Excelente.

2. O LLM é perigoso na camada onde os seus erros não são recuperáveis. Gerar o comando exacto de throttling de rack é o sítio errado para usar o LLM, porque se o comando gerado for plausível-mas-errado e executar, o sistema físico já se moveu. Não há "desfazer" num ciclo térmico. A separação do paper coloca o LLM exatamente onde as suas forças aterram e remove-o de onde as suas fraquezas mordem.

3. Vocabulário no formato do regulador. Um supervisor num setor regulado vai perguntar, em qualquer revisão de incidente: o que tomou a decisão, o que a validou, que evidência tens? O desenho do paper tem uma resposta limpa para cada uma. O desenho com LLM-no-caminho-de-ação tem, na melhor das hipóteses, "o modelo decidiu", que é a resposta que dispara os próximos dois anos de trabalho de remediação.

Quero ser claro: sou positivo sobre LLMs. Implemento-os, tenho skin in the game em IA a funcionar em produção. Não estou a fazer o argumento "LLMs são pouco fiáveis, não os uses". Estou a fazer um argumento de colocação: os LLMs são a ferramenta certa na camada de linguagem natural e explicação, e a ferramenta errada na camada de execução. O paper formaliza a colocação para a qual bons operadores já estavam a convergir informalmente.

O que isto significa para o resto da IA agêntica, não só data centres

O paper é especificamente sobre controlo de infraestrutura de IA, mas a arquitetura generaliza-se limpamente para a maioria dos deployments agênticos regulados:

  • Agente bancário que processa pagamentos. O LLM traduz a intenção do cliente. Agente determinístico com política e limites emite o débito efetivo. Gémeo digital (ou verificações pré-voo contra um ledger em sandbox) valida antes do commit.
  • Agente de triagem em saúde. O LLM medeia o diálogo, sumariza o histórico. Agente determinístico aplica o protocolo. Human-in-the-loop em qualquer ação que produza efeito clínico.
  • Agente de controlo industrial. O LLM explica setpoints ao operador e aceita alvos de setpoint a partir de linguagem natural. Controlador determinístico move efetivamente a válvula, depois de um simulador validar que o movimento não viola limites de processo.

Em todos os três, o esqueleto arquitetural é o mesmo que o do data centre no paper: o LLM nunca segura o actuador. Segura a explicação, a superfície de linguagem natural, e a tradução de intenção. A fronteira não se move porque o regulador e a física não se movem.

Esta é a mesma linha que desenhei nos meus posts sobre implantação com prova e arquitetura de governança verificável, de um ângulo diferente. O paper de Cruzes fornece a versão infraestrutura-física de um argumento que está a convergir entre setores regulados: LLM útil, LLM não autoritário, agente determinístico no caminho da consequência.

O que poria no roadmap de plataforma este trimestre

Se tivesse de traduzir este terceiro post em ações para uma equipa de plataforma a correr — ou a planear correr — IA agêntica num ambiente sério:

  1. Mapeia o teu grafo de ações. Para cada operação que um "agente" pode executar, marca que camada a emite: LLM, agente determinístico de nível 1, ou humano. Se o LLM aparece em qualquer lado na coluna de execução, tens trabalho de refactor a fazer antes que o regulador o faça por ti.

  2. Põe um gémeo digital à frente do actuador. Mesmo que tosco. O ponto não é a fidelidade; o ponto é a porta. Uma ação que o gémeo não consegue simular, ou que o gémeo mostra a violar uma restrição, não executa. Ponto. Esta única disciplina remove uma categoria de incidentes que parecem catastróficos no post-mortem e triviais em retrospectiva.

  3. Separa feedback A e B. Resultados vão para o loop de controlo. Resíduos do gémeo vão para o gémeo. Mesma telemetria de origem, dois pipelines, duas políticas de retenção, duas linhas de propriedade. É trabalho de infra sem glamour; é também o trabalho que torna a deteção de deriva real.

  4. Escreve o contrato de escalonamento. Define o que acontece quando não existe ação conjuntamente viável. A resposta é humanos, com um handoff claro e um SLA publicado de resposta. Qualquer outra coisa é um fallback silencioso que vai aparecer num incidente.

  5. Audita o teu fornecedor contra os quatro testes acima. LLM não no caminho de ação; gémeo como porta de validação real; caminhos de feedback separados; escalonamento explícito. Qualquer "plataforma agêntica" que falhe dois ou mais destes não é um sistema com grade de regulador; é uma demo de produtividade com permissões elevadas.

A linha que desenho — e porque a aguento

Sou crítico do atual hype de IA agêntica não porque a tecnologia não seja real — é, demonstravelmente, e facturo por ela — mas porque a arquitetura comercializada está consistentemente mais perto do actuador do que a arquitetura de engenharia devia estar. O paper de Cruzes, a trabalhar no domínio operacional mais exigente disponível (infraestrutura de IA viva sob restrições físicas conjuntas), chega a uma disciplina que se traduz limpamente para todo deployment agêntico regulado: LLMs falam e explicam. Agentes determinísticos propõem. Coordenadores verificam viabilidade. Gémeos digitais validam. Humanos autorizam a política e detêm o escalonamento. O sistema físico apenas vê ações que passaram todas as quatro portas anteriores.

A plataforma agêntica mais rápida em 2026 não será aquela cujo LLM chega mais perto do metal. Será aquela cujo LLM está honestamente colocado onde as suas forças vivem, com o resto da pilha desenhada para absorver as suas fraquezas. Essa plataforma não vai fazer a demo de truque de magia. Vai passar a auditoria numa terça-feira de outubro às 09:30 sem ninguém precisar de tirar o dia de folga.

Esse é o sistema que quero continuar a construir. Tudo o resto é teatro com permissões.


Fontes:

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

A pôr IA agêntica em produção e sem certezas se a tua arquitetura aguentaria uma revisão de incidente? Fala com um CTO — ajudamos-te a colocar o LLM exatamente onde as suas forças aterram e em mais lado nenhum.

Pronto para construir a sua equipa de engenharia?

Fale com um parceiro técnico e implemente desenvolvedores validados por CTOs em 72 horas.