O sandbox tradicional não é suficiente para isolar um agente de IA?

Isola, mas não escala. O sandbox por pod dedicado protege a execução, só que mantém recursos ociosos enquanto o agente espera — inviável quando você roda dezenas ou centenas deles. A discussão da semana na CNCF apontou o caminho híbrido: isolamento forte na borda (como o dos Cloud Run Sandboxes) combinado com execução sob demanda, workers compartilhados e suspensão automática. Isolamento e custo deixaram de ser problemas separados.

Preciso de infraestrutura nova para conter agentes em produção?

Na maior parte dos casos, não. O padrão que mais ressoou na semana foi criar uma fronteira de rede para o tráfego de saída do agente usando peças já maduras — NGINX como proxy e OpenTelemetry para auditar cada chamada. Você ganha controle granular do que o agente pode acessar e um rastro observável, sem introduzir um componente proprietário novo. A infra que falta é menos hardware e mais disciplina de arquitetura.

O que a LGPD e a soberania de dados têm a ver com rodar agentes?

Tudo. Um agente autônomo processa dados, chama ferramentas e toma decisões que precisam ser auditáveis desde o primeiro dia. O ciclo de vida de agentes só fecha com um loop de iteração que cuida de deriva de performance, patches de segurança e novas regulamentações — e é nesse loop que mora a conformidade com a LGPD. Somado à pergunta de onde a inferência roda, isso volta ao de sempre: governança auditável e portabilidade sob o seu controle.

Esta semana em cloud (06–12/jul): o agente já está dentro, faltou contê-lo

Q: Como avalio se meu agente é confiável antes de colocá-lo em produção?

Medindo a sessão, não o turno — e desconfiando da própria régua. O roteiro do Microsoft Foundry insiste que a unidade de análise de um agente é a sessão inteira, e que você precisa calibrar as ferramentas de avaliação (simuladores, rubricas, amostradores de trace) antes de confiar nos números. O trabalho do Google Data Cloud foi na mesma direção: benchmarks binários escondem onde o agente quebra, e até bases consagradas tinham erros de ground truth. Avalie os avaliadores.

Q: Por que meu agente de operações toma decisões erradas mesmo com um bom modelo?

Porque o gargalo raramente é o modelo — é o contexto. O 'problema dos 4 corpos do SRE' descreve a necessidade de correlacionar código, estado de infraestrutura, sinais de runtime e conhecimento operacional. Sem um grafo unificado e versionado ligando essas quatro fontes, o agente falha de forma plausível: a resposta soa certa e está errada. Invista primeiro no substrato de contexto, depois no agente.

Banner - Esta semana em cloud (06–12/jul): o agente já está dentro, faltou contê-lo

TL;DR — O relatório State of AI Infrastructure do Google Cloud confirmou o que a semana gritou: 83% das empresas precisam atualizar a infraestrutura para rodar agentes em produção. Os lançamentos responderam em três frentes — contenção (o sandbox não basta; chegam Cloud Run Sandboxes e fronteiras de rede com NGINX), avaliação (calibrar quem avalia o agente, não só o agente) e contexto (o SRE Agent só decide bem com um grafo unificado). O modelo virou o menor dos seus problemas.

Na semana passada, o modelo de ponta virou commodity e a disputa subiu para o plano de controle: quem governa a identidade, a autorização e a telemetria do agente vence. Entre 6 e 12 de julho, a pergunta desceu mais um degrau — do "quem governa" para o "onde isso roda". E um relatório colocou número na resposta: a infraestrutura que a maioria das empresas tem não foi feita para o agente.

O gatilho foi o State of AI Infrastructure, segundo relatório anual do Google Cloud, com 1.402 líderes de TI ouvidos. O dado-manchete: 83% das organizações precisam de upgrades significativos para rodar agentic AI em produção. Não é o modelo que falta — o mesmo Claude Sonnet 5 já roda em três nuvens. Falta o chão embaixo dele. E os outros números explicam por quê: 79% citam segurança, governança e MLOps como o principal desafio para escalar inferência, e 62% já sentem custo alto de inferência puxado por egress de dados, storage inflado e hardware especializado ocioso.

O resto da semana leu como a resposta prática a esse diagnóstico. Os lançamentos e análises se organizaram em três frentes — contenção, avaliação e contexto —, exatamente os três buracos que o relatório aponta.

Por que o sandbox não basta para conter um agente?

Porque o agente autônomo é um novo tipo de insider: ele executa código, chama ferramentas e faz requisições de rede por conta própria. A resposta reflexa — jogar cada agente num sandbox — resolve o isolamento e cria dois problemas: custo e escala. A análise que circulou na CNCF foi direta: o sandbox por pod dedicado protege, mas deixa recursos ociosos esperando o agente agir; quando você opera dezenas ou centenas deles, a conta não fecha. O caminho realista é híbrido — isolamento forte na borda somado a execução sob demanda, com workers compartilhados e suspensão automática.

Dois anúncios da semana atacaram esse híbrido por ângulos diferentes:

O que apareceu	Ideia central	O que resolve
Cloud Run Sandboxes (preview, Google Cloud)	Ambiente isolado e instantâneo para rodar código não confiável — gerado por IA ou por usuários — dentro do próprio Cloud Run, sem custo extra	Isolamento de credenciais, rede bloqueada por padrão e filesystem efêmero, sem montar infraestrutura de sandbox própria
Network boundary com NGINX + OpenTelemetry (CNCF)	Uma fronteira para o tráfego de saída do agente usando NGINX como proxy e OTel para auditar cada chamada	Controle granular do que o agente acessa e um rastro observável — sem componente proprietário novo

Leia as duas linhas juntas e a moral aparece: a contenção do agente não exige tecnologia nova, exige tratar o agente como não confiável por padrão. É o que a indústria vem chamando de Agent Zero Trust — dar ao agente uma identidade estritamente escopada, bloquear a rede na origem e observar tudo que ele faz. Rede fechada por padrão e cada chamada auditada não são luxo; são o mínimo para não descobrir depois que o agente teve acesso a mais do que devia.

Antes de soltar um agente na sua rede, vale desenhar a fronteira dele — o que ele acessa, por onde, e com qual rastro. A gente monta esse boundary com você.

Como saber se o agente é confiável? Avaliando os avaliadores

Conter é metade do trabalho; a outra é saber se o agente entrega. E aqui a semana trouxe uma correção de rota incômoda: as métricas que a maioria usa mentem por otimismo.

O time de observabilidade do Microsoft Foundry publicou um roteiro de cinco passos com uma tese central: medir um agente não é medir um modelo. A unidade de análise é a sessão, não o turno isolado — e, antes de confiar em qualquer nota, você precisa calibrar as próprias ferramentas de avaliação (simuladores, rubricas, amostradores de trace). Sem isso, o número reflete o otimismo da sua stack de teste, não a qualidade real do agente.

O Google Data Cloud chegou à mesma conclusão por outro caminho. Notas binárias de passa/não-passa escondem onde o agente realmente quebra; o Discovery Bench usa teoria da informação (surpresa) para modular a ambiguidade das consultas e mapear o terreno de capacidades. O achado é o alerta: um benchmark consagrado continha erros de ground truth, e um agente podia despencar de um F1 = 1,0 para 0,0 com uma pequena mudança na consulta. A lição para quem vai colocar agente em produção: avalie os avaliadores antes de assinar embaixo do dashboard verde.

E quando o próprio agente opera a infra — de onde vem o contexto?

A terceira frente é a que mais interessa a quem opera. O Azure SRE Agent consolidou a promessa de automatizar triagem de incidentes, health checks e triagem de bugs, com governança granular (RBAC, audit trail) e memória persistente — clientes citados relatam até 80% de redução no tempo de investigação. É atraente, e é onde o risco se esconde.

O contraponto veio da CNCF, com o "problema dos 4 corpos do SRE": o limitante de operações autônomas não é a capacidade do modelo, é a falta de contexto integrado. Um agente só decide bem se correlacionar quatro fontes — código, estado de infraestrutura, sinais de runtime e conhecimento operacional. Sem um grafo unificado e versionado ligando as quatro, ele falha de forma plausível: a recomendação soa perfeita e está errada. A conclusão bate com o que temos defendido sobre avaliar, medir custo e governar agentes em produção: invista primeiro no substrato — contexto e observabilidade — e só então no agente que consome esse substrato. Não à toa, a mesma stack que você usa para observar workloads humanos — uma observabilidade self-hosted sem lock-in, do tipo LGTM sobre Kubernetes — é o que dá ao agente de operação o contexto que ele precisa para não alucinar decisões.

O que isso muda para quem opera infra no Brasil?

Muda a ordem das prioridades. A tentação, com 83% das empresas correndo atrás, é comprar o agente mais capaz e ligar. O que a semana mostrou é que o modelo é o menor dos seus problemas — a lacuna está no chão embaixo dele: contenção (rede fechada por padrão, identidade escopada, rastro auditável), avaliação (medir a sessão e calibrar a régua) e contexto (o grafo que liga código, infra e runtime).

Para o Brasil, some duas restrições que o relatório também toca. A primeira é custo: com 62% já sentindo o peso da inferência, egress e hardware ocioso, soltar agentes sem fronteira de rede e sem suspensão automática é queimar orçamento. A segunda é conformidade: um agente que processa dados sob a LGPD precisa de audit log e governança desde o design — não como remendo. A boa notícia é que quase nada disso exige tecnologia proprietária nova. NGINX, OpenTelemetry, OIDC, um grafo de contexto versionado: as peças já estão no ecossistema cloud native, sob o seu controle. O agente já está dentro da sua operação. Faltou construir a cerca — e ela é feita de coisas que você já sabe operar.

Fontes: