Esta semana em cloud (18–24/mai): o agente saiu do slide e virou problema de infra

Q: Por que o agente virou um problema de runtime, e não de modelo?

O sinal mais forte veio do Google. O GKE Agent Sandbox atingiu disponibilidade geral, e o anúncio veio acompanhado de um projeto open-source novo, o Agent Substrate . A leitura importante aqui não é o marketing de "futuro da IA" — é o reconhecimento de que agente é uma carga de trabalho com comportamento estranho: rajadas curtíssimas e intensas de processamento, seguidas de longos períodos parados, e a necessidade de executar código de terceiros (ou não confiável) sem comprometer o cluster.

Banner - Esta semana em cloud (18–24/mai): o agente saiu do slide e virou problema de infra

TL;DR: A semana de 18 a 24 de maio consolidou uma virada: o agente de IA deixou de ser demo e virou carga de infraestrutura. GKE Agent Sandbox foi para GA, Foundry IQ centralizou conhecimento, Agent 365 levou agentes ao SIEM, OpenTelemetry graduou na CNCF e a Microsoft datou o fim do TLS 1.0/1.1 em 2027. Conclusão: quem opera infra no Brasil precisa tratar agente como workload de produção — runtime, governança, observabilidade e custo sob controle —, não como experimento.

Toda semana a indústria de cloud anuncia coisas demais para uma pessoa acompanhar. O trabalho do editorial não é listar — é encontrar o fio que costura os anúncios e dizer o que muda para quem opera infraestrutura no Brasil. E o fio desta semana é claro: o agente de IA parou de ser assunto do time de IA e virou problema de plataforma, SRE e SecOps.

Não foi um único lançamento que marcou isso. Foi o fato de que, em sete dias, cada camada da pilha de agentes — runtime, conhecimento, segurança, observabilidade e até a conta no fim do mês — ganhou produto, padrão ou prazo concreto. Quando isso acontece de forma sincronizada nos três grandes provedores e na CNCF, não é coincidência de calendário: é uma tecnologia saindo da fase de demonstração e entrando na fase de operação. E operação é onde mora a Nuvem Online.

Por que o agente virou um problema de runtime, e não de modelo?

O sinal mais forte veio do Google. O GKE Agent Sandbox atingiu disponibilidade geral, e o anúncio veio acompanhado de um projeto open-source novo, o Agent Substrate. A leitura importante aqui não é o marketing de "futuro da IA" — é o reconhecimento de que agente é uma carga de trabalho com comportamento estranho: rajadas curtíssimas e intensas de processamento, seguidas de longos períodos parados, e a necessidade de executar código de terceiros (ou não confiável) sem comprometer o cluster.

Os números que o Google divulgou ajudam a entender o esforço de engenharia: warm pools que alocam 300 sandboxes por segundo, com 90% das alocações em até 200 milissegundos, pod snapshots que suspendem workloads ociosas e as retomam em segundos, e isolamento via gVisor para o cenário multitenant. O Agent Substrate vai além e admite o incômodo de frente: o control plane do Kubernetes não foi desenhado para milhões de tool calls de sub-segundo. É um control plane minimalista para densidade extrema, sobre a mesma base segura do Sandbox.

No Google I/O '26, a mesma tese apareceu na camada de cima, com Gemini 3.5 Flash, Antigravity integrado à Agent Platform e o CodeMender aplicando patches sob aprovação humana. E a AWS reforçou pelo flanco da modernização: o AWS Transform completou um ano tendo processado mais de 4,5 bilhões de linhas de código. Abordagens diferentes — Google na infra de execução, AWS na modernização de legado — mas a conclusão converge: agente é workload de produção, e produção tem requisitos de isolamento, latência e custo.

O contraponto prático veio da comunidade, e é o aprendizado mais útil da semana para quem opera no Brasil: a NetEase Games relatou ter derrubado o cold start de inferência de LLMs no Kubernetes de 42 minutos para menos de 30 segundos — não comprando mais GPU, mas resolvendo o data path com o framework Fluid (orquestração de cache de datasets). A lição é direta: autoscaling de GPU é inútil se os pesos do modelo demoram para chegar ao nó. Antes de assinar instâncias mais caras, vale olhar onde o dado está parado.

Onde o agente guarda o que sabe (e por que isso vira arquitetura)?

Se a primeira camada é "onde o agente roda", a segunda é "o que o agente sabe" — e aqui a Microsoft fez o movimento mais maduro da semana com o Foundry IQ, apresentado como um "cérebro de conhecimento compartilhado" para múltiplos agentes. O problema que ele ataca é familiar para qualquer time que passou de um para vários agentes: cada agente acaba com seu próprio pipeline de RAG, sua própria indexação e sua própria lógica de retrieval. O resultado é esforço duplicado, custo de indexação multiplicado e — o pior — respostas inconsistentes para a mesma pergunta, dependendo de qual agente respondeu.

A proposta inverte a arquitetura: indexa-se a base uma vez (conectando SharePoint, OneLake, Blob Storage, Fabric) e múltiplos agentes consultam a mesma fonte de verdade, com agentic retrieval que quebra a pergunta em subperguntas e itera. O modelo mental que a Microsoft sugere é honesto: agentes são os trabalhadores, o Foundry IQ é o cérebro corporativo. Some a isso o Memory Store no Foundry (ensinar o agente a lembrar entre sessões) e o Data Agent Kit do Google (que leva habilidades de dados para a IDE/CLI do engenheiro), e fica evidente o padrão: conhecimento e memória estão deixando de ser preocupação de cada agente para virar capacidade de plataforma.

Para o gestor brasileiro, a recomendação é sóbria. Para um agente isolado, centralizar conhecimento é prematuro — over-engineering. A partir do segundo agente que responde dúvidas parecidas, é o contrário: replicar pipeline de RAG vira dívida técnica que se paga em inconsistência e custo. O gatilho de decisão é a frota, não a tecnologia.

Está saindo do agente-piloto para uma frota de agentes em produção? A Nuvem Online ajuda a desenhar runtime, conhecimento e governança sem multiplicar custo e risco.

Quem vigia o agente? A semana em que SecOps assumiu a IA

Agente que age na infraestrutura é, por definição, um ator com permissões — e ator com permissões precisa aparecer no radar de segurança. Foi exatamente essa a mudança que o conector Agent 365 para Microsoft Sentinel (em public preview) materializou: tratar agentes de IA como entidades de primeira classe no SIEM, centralizando sua telemetria no data lake e permitindo threat hunting via KQL, baseline de comportamento e rastreamento de blast radius quando algo dá errado.

Os casos de uso citados não são teóricos: access drift (o agente acumula permissões inseguras conforme suas funções evoluem), exposição de dados (o agente foi configurado com acesso excessivo) e detecção de prompt injection (capturar o fluxo de raciocínio para identificar quando o comportamento foi manipulado). Em paralelo, dois temas reforçaram o cerco: a discussão sobre Shadow AI, defendendo que o controle precisa migrar para o ponto de interação — o navegador do usuário — porque monitoramento de backend bloqueia tarde demais; e os padrões de human-in-the-loop no Foundry, que insistem numa taxonomia de reversibilidade: ação irreversível exige aprovação humana explícita, sempre.

A leitura para o Brasil junta segurança e conformidade. LGPD, PCI-DSS, ISO 27001 e SOC 2 não foram escritas pensando em agentes, mas se aplicam a eles: se você não consegue auditar quem (ou qual agente) acessou qual dado e por quê, a lacuna de rastreabilidade vira risco de compliance. A boa notícia é que a estrutura para fechar esse gap começou a existir nesta semana. A má notícia é que ela não se instala sozinha — exige decisão arquitetural antes da frota crescer.

E quem vigia a infraestrutura? OpenTelemetry fecha a discussão

Enquanto a segurança ganhava ferramentas, a observabilidade ganhou um marco: o OpenTelemetry graduou na CNCF, consolidando-se como padrão de fato para coleta de logs, métricas e traces. Para quem opera multicloud — e no Brasil é comum transitar entre AWS, Azure, GCP e OCI — a graduação é a validação de que adotar o OTel hoje significa uma base estável e vendor-neutral para os próximos anos: instrumenta-se uma vez, roteia-se para qualquer backend, e a troca de ferramenta de análise não exige refazer instrumentação. Isso é redução de lock-in e economia de FinOps no mesmo movimento.

Mas observabilidade tem buracos, e a CNCF foi honesta sobre um deles na mesma semana. Uma análise expôs uma lacuna silenciosa no kubectl debug: sessões de debug com containers efêmeros não retêm o contexto de encerramento na API do Kubernetes. Código de saída, duração e logs desaparecem assim que o estado do pod muda — porque EphemeralContainerStatus não tem o campo lastState que um container comum tem. Não é bug, é decisão de design. Na prática, num handoff entre engenheiros de plantão a evidência do incidente some, e em ambiente regulado isso vira lacuna de auditoria. A mitigação é conhecida (log estruturado externo, captura via Watch API), mas o ponto editorial é outro: observabilidade graduada não significa observabilidade completa. Detalhe é onde o incidente mora.

O básico que ninguém aplaude (mas que derruba produção)

Por baixo de todo o barulho de IA, a semana entregou o tipo de anúncio que não vira manchete mas decide se você vai ter um fim de semana tranquilo em 2027. A Microsoft datou o fim do TLS 1.0 e 1.1 no Azure App Service, Functions e Logic Apps: 31 de maio de 2027. O prazo parece distante, mas o trabalho real — auditar quem ainda fala TLS legado com você (ERPs, sistemas bancários, integrações governamentais, dispositivos antigos, runtimes defasados) — leva meses e depende de terceiros que você não controla. Quem começar a mapear em 2026 transforma um incidente de indisponibilidade num projeto rotineiro.

No mesmo bloco, dois movimentos de simplificação importam para o Brasil. O Azure Files com identidades exclusivas do Entra ID para acesso SMB foi a GA — permitindo aposentar controladores de domínio on-premises mantidos só por causa de compartilhamento de arquivos, com menos custo, menos superfície de ataque e o fim da dor de time skew, GPO e sincronização. E a Object REST API compatível com S3 no Azure NetApp Files chegou ao GA, eliminando o dilema de duplicar dados entre file storage e object store: o mesmo volume NFS/SMB passa a ser lido como objeto por Databricks, ML e Fabric, sem migração. Onde SAP e ERPs legados convivem com times de dados cloud-native, isso é interoperabilidade que economiza retrabalho.

E, fechando o ciclo com FinOps, o relatório de tamanho de itens no OneLake (preview) atacou a opacidade de storage no Microsoft Fabric — mostrando consumo por item, incluindo dados de sistema e soft-deleted que antes eram invisíveis na fatura. É o lembrete de que custo de cloud só se controla com visibilidade granular, não com susto no fim do mês.

O que levar desta semana

Se houver uma frase para resumir a semana de 18 a 24 de maio, é esta: o agente de IA migrou do roadmap de inovação para o backlog de operação. Runtime, conhecimento, segurança e observabilidade ganharam, todos ao mesmo tempo, ferramentas e padrões pensados para produção. Isso muda a pergunta que o gestor de infra precisa fazer. Não é mais "vamos usar agentes?", e sim "nossa plataforma sabe rodar, governar, observar e pagar por agentes sem virar um ponto cego?".

A postura da Nuvem Online é a de sempre: a tecnologia nova é bem-vinda, mas o critério é portabilidade e controle. Adote padrões abertos (OpenTelemetry, projetos da CNCF) antes de soluções fechadas. Centralize conhecimento e segurança antes de a frota crescer, não depois. E nunca deixe o básico — TLS, identidade, custo, auditoria — apodrecer enquanto a atenção vai toda para a IA. É o básico que derruba produção; é o agente bem governado que dá vantagem.

Perguntas Frequentes

Rodar agentes de IA exige uma infraestrutura diferente do Kubernetes que já tenho?
Não exige jogar fora o que existe, mas exige ajustar. Agentes têm um perfil de carga atípico: rajadas curtas de execução seguidas de longa ociosidade, e milhões de chamadas de ferramenta de sub-segundo. Recursos como o GKE Agent Sandbox (pod snapshots, warm pools, isolamento via gVisor) e projetos como o Agent Substrate existem justamente porque o control plane do Kubernetes tradicional não foi desenhado para essa frequência. Para a maioria das empresas no Brasil, o caminho é adotar esses padrões sobre o cluster atual, não migrar de plataforma.
Por que devo me preocupar agora com a descontinuação do TLS 1.0/1.1 se o prazo é maio de 2027?
Porque o trabalho difícil não é virar a chave no Azure — é mapear quem ainda fala TLS legado com você. Sistemas bancários, ERPs, integrações governamentais e dispositivos antigos costumam estar fora do seu controle e dependem de fornecedores terceiros. Auditar logs no Azure Monitor, identificar runtimes defasados (.NET Framework antigo, Node e Python legados) e pressionar fornecedores leva meses. Começar em 2026 transforma um incidente de indisponibilidade em 2027 num projeto rotineiro.
Qual o ganho prático de adotar OpenTelemetry agora que ele graduou na CNCF?
A graduação sinaliza estabilidade de API e maturidade para produção crítica. Na prática, você instrumenta uma vez e roteia logs, métricas e traces para qualquer backend, reduzindo vendor lock-in e ingestão duplicada — o que vira economia direta de FinOps. Em ambiente multicloud (AWS, Azure, GCP, OCI), ter um idioma comum de telemetria é o que permite trocar de ferramenta de análise sem refazer instrumentação.
Como começar a tratar agentes de IA como entidades de segurança?
O primeiro passo é visibilidade: agente que age na sua infra precisa aparecer no seu SIEM como qualquer identidade. O conector Agent 365 para Microsoft Sentinel (em public preview) centraliza a telemetria de agentes e permite hunting via KQL, baseline de comportamento e rastreamento de blast radius. Combine isso com controles no ponto de uso (contra Shadow AI) e padrões de human-in-the-loop para ações irreversíveis. Sem isso, cada novo agente é um ponto cego.
Centralizar o conhecimento dos agentes (tipo Foundry IQ) faz sentido para quem tem poucos agentes?
Faz sentido a partir do segundo agente que responde perguntas parecidas. O ganho não é tecnológico, é arquitetural: em vez de cada agente ter seu próprio pipeline de RAG, indexação e lógica de retrieval, você indexa a base uma vez e múltiplos agentes consultam a mesma fonte de verdade. Isso elimina respostas inconsistentes, reduz custo de indexação e centraliza governança e permissões. Para um único agente, é prematuro; para uma frota, vira necessidade.