Três Fornecedores. Uma Semana. Governança Virou Decisão de Procurement.

Três fornecedores. Uma semana. Três primitivas distintas de governança, todas elas embaladas como produto que você compra.

Há um ano escrevemos que governança vira feature de produto. A tese era que o plano de controle de agentes de IA chegaria como infraestrutura, não como política. A primeira onda foi a Cloudflare. Depois a Datadog. Depois a validação por órgão de padrão na forma da ISO 42001. Cada um desses movimentos foi um único fornecedor numa única categoria, e o argumento acumulado era que o padrão se generalizaria.

A primeira semana de maio de 2026 encerrou o argumento. AWS, Google Cloud e Datadog publicaram, no mesmo arco e na mesma janela de calendário, primitivas de governança que aterrissam no mesmo comitê de compras. As primitivas não competem entre si. Elas se empilham. E isso muda a pergunta que todo CIO está olhando agora.

O que a AWS lançou: controle de cloud com credencial de agente

No dia 6 de maio, a AWS anunciou o AWS MCP Server em GA. Vá além da manchete. O mecanismo é a notícia.

O servidor expõe mais de 15 mil operações de API da AWS via Model Context Protocol, o que já seria interessante por si só. Mas o detalhe operativo está no modelo de IAM. Chamadas feitas por agente carregam uma context key de IAM que as distingue das chamadas feitas por humanos. O CloudTrail registra cada invocação por padrão, com a identidade do agente preservada na trilha de auditoria. Uma segunda ferramenta, o run_script, executa código dentro de uma sandbox sem rede e sem filesystem. O agente computa. Ele não alcança.

O que isso significa na prática: a política que seu time de segurança escreve para operadores humanos pode agora divergir da política que você escreve para operadores agentes, e a AWS faz a aplicação na própria superfície da API. Você não está mais pedindo ao seu time de plataforma para construir um broker de permissões entre Claude e a sua conta. Você está comprando isso. A trilha do CloudTrail não precisa de uma camada de abstração agêntica enxertada depois do fato. A abstração mora dentro da credencial.

Isso é governança chegando onde o trabalho acontece. A API da cloud era o lugar onde os agentes queriam agir. A AWS tornou a própria API consciente de agente.

O que a Google lançou: identidade para agentes que ainda não tinham

Em 22 de abril, a Google Cloud anunciou o Fraud Defense, a próxima evolução do reCAPTCHA. O enquadramento importa. O reCAPTCHA já protege 50% das empresas da Fortune 100 e 14 milhões de domínios. O produto já estava em escala de infraestrutura. O que mudou foi o que ele faz agora.

O Fraud Defense estende a coleta de sinais do reCAPTCHA até virar uma superfície completa de identidade de agente. Ele integra Web Bot Auth e SPIFEE, os dois padrões emergentes para assinar criptograficamente o tráfego de agentes, e correlaciona esses sinais com o modelo comportamental de risco que já existia. O output deixa de ser “humano ou bot”. Passa a ser “qual agente, em nome de quem, com qual reputação, fazendo o quê”. Clientes de reCAPTCHA já existentes são incluídos automaticamente sem custo. A redução média de account takeovers na base é de 51%.

O movimento estratégico é a transição de challenge para identidade. Por quinze anos, o trabalho do reCAPTCHA foi manter automação fora. O trabalho do Fraud Defense é deixar entrar a automação certa, com proveniência. A distinção não é sutil. Um site que queria ser amigável a agentes precisava escolher entre se expor a abuso ou se expor a fricção. O Fraud Defense roteia o caminho do abuso por uma camada de identidade verificada em vez de uma porta de challenge.

Se a entrega da AWS é “a API da cloud fala agente”, a entrega da Google é “a web pública fala agente”. Dois lados diferentes do mesmo plano de controle.

O que a Datadog lançou: a camada de medição que faltava

No dia 6 de maio, a Datadog publicou Bits AI Eval Platform: Agents at Scale. O post é técnico e merece leitura completa. Três números se destacam.

Aumento de 30% na qualidade da identificação de causa raiz a partir de geração automática de rótulos. Redução de 95% no tempo de validação humana em uma única semana. E o achado contraintuitivo: quando injetaram ruído realístico no conjunto de avaliação, a taxa de aprovação caiu 11%, mas as avaliações resultantes passaram a prever o comportamento em produção de uma forma que as versões mais limpas não previam.

A plataforma reproduz traces de produção com resultados rotulados, deixa engenheiros iterarem sobre o desenho do agente contra esses traces e trata a suíte de avaliação como artefato de produto versionado. O que a Datadog fez foi liberar como produto a musculatura que times internos de plataforma vêm tentando construir há dois anos, na maioria das vezes sem sucesso. A maior parte das empresas não consegue gerar conjuntos de teste confiáveis para agentes porque a telemetria de produção não está estruturada para replay. A eval platform da Datadog converte a telemetria que ela já tem na base de teste que o cliente não consegue produzir sozinho.

O fornecedor que é dono de observabilidade também é dono de avaliação. Isso não é acidente arquitetural. Os sinais que diagnosticam agentes vivos são os mesmos que pontuam agentes em teste. A única dúvida era quem perceberia primeiro.

O padrão que aparece quando você lê os três juntos

Lidos como movimento de mercado único, os três anúncios deixam o desenho claro.

A AWS é dona da superfície de ação. O agente faz trabalho; a AWS audita e restringe.

A Google é dona da superfície de identidade. O agente faz uma requisição; a Google verifica quem está pedindo e em nome de quem.

A Datadog é dona da superfície de medição. O agente vai ao ar; a Datadog te diz se ele de fato faz o que você prometeu.

Isso não é um produto único. É uma stack. E é a primeira vez que essa stack pode ser comprada de líderes de categoria sem uma única linha de cola de integração escrita pelo seu time de plataforma. Há um ano, uma empresa que quisesse operar agentes com responsabilidade tinha que escolher entre escrever o broker em casa ou comprar um pacote single-vendor que a prendia à visão de governança de uma única cloud. A restrição era real e nós escrevemos sobre ela.

Esta semana afrouxou a restrição. Procurement passou a ter opções. Cada opção chega com primitivas de auditoria, identidade e avaliação que se interoperam por padrões (IAM, MCP, Web Bot Auth, SPIFEE) e não por boa vontade entre fornecedores.

A implicação para procurement

Se você roda um ciclo orçamentário de 2026 que inclui qualquer linha de agentes de IA em produção, o enquadramento da compra acabou de mudar.

O enquadramento antigo: escolha uma cloud, aceite a postura de governança dela, torça para o time de engenharia interno fechar os buracos. O novo enquadramento: monte três primitivas de três fornecedores, nenhum deles tentando ser dono da stack inteira, e valide se as primitivas interoperam. A AWS provê auditoria de ação. A Google provê correlação de identidade de agente. A Datadog (ou um equivalente em observabilidade) provê o harness de avaliação. O trabalho do seu time de plataforma deixa de ser inventar o plano de controle. Passa a ser conectar os componentes e operar.

Isso é mudança de verdade. Procurement sabe avaliar três fornecedores contra uma definição de categoria. Tem muito mais dificuldade para avaliar “build versus buy” quando o lado buy ainda não existe como categoria. O lado buy existe agora. A categoria é governança-como-produto, e nesta semana ela tem ao menos três fornecedores de componente com credibilidade.

O risco é o inverso do risco do ano passado. Ano passado, o perigo era que o plano de controle inteiro consolidasse em lock-in num único fornecedor. O perigo desta semana é o oposto: que compradores concluam que os componentes são intercambiáveis e fiquem com três primitivas que compartilham padrões no papel mas tropeçam umas nas outras na prática. Padrões não eliminam custo de integração. Tornam o custo entediante. Integração entediante ainda é integração.

O que fazer agora

Três ações concretas para os próximos trinta dias, em ordem de prioridade.

Primeira, audite seu inventário de agentes contra o modelo de IAM context key do AWS MCP Server. Cada agente que toca em APIs da AWS já deveria ter um principal separado. Se você ainda emite credenciais de service-account para agentes que ficam idênticas às dos seus humanos, a nova primitiva de auditoria não vai te salvar. O modelo de credencial é o pré-requisito.

Segunda, avalie o Fraud Defense como substituto, não como suplemento, de qualquer bot-gating caseiro que você escreveu nos últimos dezoito meses. O contrato existente de reCAPTCHA já te atualiza automaticamente. A decisão não é “vamos adotar isso”. É “vamos manter a porta caseira agora que o mesmo fornecedor oferece uma alternativa de identidade verificada”. Na maioria dos casos a resposta é não.

Terceira, comece a produzir traces de avaliação com replay a partir da sua telemetria de agente agora, mesmo que seu fornecedor de observabilidade ainda não tenha entregue um equivalente da Datadog. O padrão de eval platform vai se espalhar. O gargalo para adotar será se seus traces estão estruturados o suficiente para replay. É um projeto de plataforma de 2026 independentemente de qual fornecedor de observabilidade vencer.

Três fornecedores. Uma semana. A stack é real, os componentes são compráveis e a pergunta deixou de ser se governança chega como produto. É qual decisão de procurement você está tomando neste trimestre.

Fontes

AWS. “The AWS MCP Server is now generally available.” Maio de 2026.
Google Cloud. “Introducing Google Cloud Fraud Defense.” Abril de 2026.
Datadog. “Bits AI Eval Platform: Agents at Scale.” Maio de 2026.

A Victorino ajuda empresas a mapear decisões de procurement ao novo stack de governança-como-produto: contato@victorino.com.br | www.victorino.com.br