Adotar o Claude Sonnet 5 dentro da minha nuvem me prende ao provedor?

O modelo em si, não — foi exatamente isso que a semana provou: o mesmo Claude Sonnet 5 ficou disponível no Microsoft Foundry, no Azure Databricks e no Google Cloud quase ao mesmo tempo. O que prende não é o modelo, é a camada em volta dele: se a identidade, a autorização de ferramentas, a telemetria e os audit logs vivem só no console proprietário do provedor, trocar de nuvem significa reconstruir a governança do zero. Mantenha esse plano de controle sob padrões abertos e o modelo vira peça substituível.

Qual a diferença entre o Foundry Control Plane e o Agent 365 da Microsoft?

São dois planos complementares para públicos diferentes. O Foundry Control Plane é voltado ao time de desenvolvimento — construir, avaliar e monitorar agentes. O Agent 365 é voltado a TI e segurança — gerenciar identidade, acesso e compliance dos agentes em toda a organização. Quem vai para produção em escala tende a precisar dos dois: um resolve a engenharia do agente, o outro resolve o 'quem pode o quê' corporativo.

Uso o MCP server gerenciado do provedor ou hospedo o meu?

O MCP server remoto e gerenciado (como o do Gemini Enterprise Agent Platform) reduz atrito: seu agente — mesmo construído numa IDE externa — fala com os recursos da nuvem sem você operar a canalização. O custo é o acoplamento ao provedor. Como o MCP é um protocolo aberto, você pode hospedar o seu próprio server e manter a portabilidade. A escolha é o trade-off de sempre: conveniência gerenciada versus controle e portabilidade.

O que é o protocolo A2A e por que ele importa contra o lock-in?

O A2A (Agent-to-Agent) é um protocolo que permite a agentes de frameworks diferentes se descobrirem e colaborarem — por exemplo, um agente do Microsoft Foundry conversando com um agente LangGraph. Importa porque quebra a premissa de que todos os seus agentes precisam viver no mesmo ecossistema: com A2A, o framework de cada agente vira detalhe de implementação, não uma decisão irreversível de arquitetura.

Por onde começo a montar um plano de controle de agentes que seja portável?

Pelas quatro peças que você não deve terceirizar: identidade (OIDC/OAuth 2.1), autorização de ferramentas em contexto, telemetria (OpenTelemetry) e audit log imutável. Trate o modelo e o console do provedor como substituíveis e ancore essas quatro em padrões abertos e sob sua gestão. O Agent Governance Toolkit open-source da Microsoft, que exporta audit e telemetria para destinos que você controla, é um ponto de partida concreto.

Esta semana em cloud (29/jun–05/jul): o modelo virou commodity, o plano de controle virou a cerca

TL;DR — O Claude Sonnet 5 pousou no Microsoft Foundry, no Azure Databricks e no Google Cloud na mesma semana: o modelo de ponta virou commodity. Só que cada nuvem despejou seu próprio plano de controle para agentes — Foundry Control Plane e Agent 365, o MCP server gerenciado do Google, o Claude apps gateway. O lock-in subiu de camada: saiu do modelo e foi para a governança. A saída são os padrões abertos que ficam sob o seu controle.

Na semana passada a pergunta era como confiar no agente de IA — autenticar quem ele representa, blindar sua memória e medir se ele acerta. Entre 29 de junho e 5 de julho, os grandes provedores responderam com a mesma cara: despejaram planos de controle para agentes. E, ao fazê-lo em bloco, revelaram sem querer o mapa do novo lock-in.

O gatilho mais eloquente foi um modelo aparecendo em três lugares ao mesmo tempo. O Claude Sonnet 5, da Anthropic, entrou em disponibilidade geral no Microsoft Foundry, passou a ser servido pelo AI Model Serving do Azure Databricks e ganhou um gateway dedicado no Google Cloud — tudo dentro da mesma janela. Quando o mesmo modelo de ponta roda em nuvens concorrentes, ele deixa de ser diferencial e vira commodity. E aí a pergunta interessante muda: se não é mais o modelo que prende o cliente, o que prende?

Por que o mesmo Claude apareceu em três nuvens na mesma semana?

Porque o valor migrou. Um modelo que está em toda parte não retém ninguém pela exclusividade — retém, no máximo, pela integração ao redor: autenticação, billing, latência e a proximidade dos seus dados. Foi esse o argumento repetido em cada anúncio. No Foundry, a venda é a integração nativa ao Azure (identidade, billing, agentic workflows). No Databricks, é inferência de alto nível com custo e latência de um modelo intermediário, colada aos dados que já vivem na plataforma. No Google Cloud, é manter a inferência dentro do seu próprio projeto, sob as políticas de lá.

Repare no padrão: ninguém está vendendo o modelo. Estão vendendo o lugar onde o modelo roda — e, principalmente, as réguas que cercam esse lugar. É aí que mora a disputa de 2026.

Se o modelo virou commodity, onde ficou o lock-in?

No plano de controle. A semana foi uma enxurrada dele, cada nuvem com o seu:

O que lançou	Provedor	Para que serve
Foundry Control Plane	Microsoft	Times de desenvolvimento construírem, avaliarem e monitorarem agentes
Agent 365	Microsoft	TI e segurança gerenciarem identidade, acesso e compliance dos agentes na organização
Foundry Toolboxes (GA)	Microsoft	Camada unificada de invocação de ferramentas, sem montar tool list na mão
Agent Identities Asset Connector (preview) + AI Agent Events no ASIM	Microsoft Sentinel	Dar contexto de identidade e telemetria dos agentes ao SIEM
MCP server remoto gerenciado	Google (Gemini Enterprise Agent Platform)	Agentes externos acessarem recursos do Google Cloud sem operar a canalização
Claude apps gateway	Anthropic + Google Cloud	Centralizar identidade via IdP, RBAC, telemetria por usuário e limites de gasto

Leia a coluna da direita e a moral aparece sozinha: identidade, autorização, telemetria, auditoria e limite de gasto. É exatamente a lista de coisas que definem se você controla seus agentes — ou se está apenas usando os de alguém. Foi para cá que o lock-in se mudou. Prender o cliente no modelo ficou impossível; prendê-lo no console que governa o modelo é a nova jogada. A Microsoft foi literal: são dois planos de controle (um para o dev, outro para a segurança), e o próprio anúncio admite que a empresa em escala precisará dos dois.

Antes de escolher o plano de controle de agentes de um provedor, vale mapear o que dele você conseguiria levar embora. A gente faz esse mapa com você.

O que há de aberto no meio de tanto plano proprietário?

Mais do que parece — e é aqui que fica o roteiro de fuga. Três sinais da mesma semana apontam para o contrário do jardim murado:

O Agent Governance Toolkit (AGT) da Microsoft é open-source. Ele registra cada chamada de ferramenta e cada decisão de política e exporta os audit logs e a telemetria para destinos que você escolhe (no exemplo, Blob Storage e Application Insights, mas o padrão de exportação é seu). Governança que sai do console fechado e vira dado seu.
O protocolo A2A conectou um agente do Foundry a um agente LangGraph rodando em containers. Interoperabilidade entre frameworks distintos significa que o framework de cada agente deixa de ser uma aposta de arquitetura.
Os MCP servers gerenciados — por mais que amarrem quando são do provedor — falam um protocolo aberto. O mesmo agente que hoje consome o MCP server do Google pode, amanhã, apontar para um MCP server que você hospeda.

Ou seja: o material para construir um plano de controle portável está na mesa. MCP para conectar ferramentas, A2A para conectar agentes, OpenTelemetry para observar, OIDC/OAuth para autenticar. O provedor oferece a versão gerenciada e conveniente de tudo isso; o padrão aberto por trás é o que garante que você possa sair.

O que isso muda para quem opera infra no Brasil?

Muda a pergunta que você faz na hora de adotar. Não é mais "qual o melhor modelo?" — porque o melhor modelo provavelmente já roda na sua nuvem e na concorrente. A pergunta virou "quanto do plano de controle é meu e quanto é do provedor?". Um agente autônomo com credencial ampla, telemetria presa no console de um fornecedor e audit log que não sai de lá é um risco de compliance e de portabilidade ao mesmo tempo.

O caminho prático é o que já vínhamos defendendo em como avaliar, medir custo e governar agentes em produção: trate o modelo e o console como peças substituíveis, e ancore as quatro coisas que não se terceiriza — quem autentica, quem autoriza, quem observa e quem audita — em padrões abertos sob a sua gestão. Vale para agentes tanto quanto valeu para identidade multi-tenant sem lock-in: a conveniência gerenciada é bem-vinda enquanto for reversível. No momento em que o plano de controle deixa de ser reversível, você não adotou um agente — adotou um dono.

Fontes: