Amazon Bedrock AgentCore: governança e quality evals em produção

TL;DR

Em 2026, o Amazon Bedrock AgentCore consolidou dois blocos que atacam problemas diferentes do mesmo sistema: governança determinística com Policy e observabilidade de qualidade com AgentCore Evaluations. Na prática, isso ajuda times a reduzir tool calls indevidas, medir regressões com tráfego real e criar um ciclo de melhoria mais confiável para agentes em produção.

O que mudou no AgentCore em 2026

O lançamento colocou lado a lado duas capacidades que normalmente aparecem separadas em stacks de agentes: autorização antes da execução e avaliação contínua depois da execução. A Policy entra no fluxo do Gateway para decidir se uma interação com ferramenta pode acontecer; as evaluations entram para medir se o resultado do agente continua aceitável ao longo do tempo. Fontes oficiais descrevem o conjunto como uma forma de construir agentes “trusted” com controle e métricas em produção: AWS Blog e What’s New.

Isso é relevante porque agentes não falham só na geração de texto. Eles falham em decisões de ferramenta, sequenciamento de ações, uso de contexto e aderência a regras do negócio. Separar governança de avaliação permite tratar esses riscos de forma mais objetiva, em vez de depender apenas de prompts e revisão manual.

Policy: governança determinística para tool calls

A Policy do AgentCore atua como uma camada de autorização para interações com ferramentas, interceptando o tráfego no AgentCore Gateway antes da execução. A documentação oficial descreve o uso de Cedar para expressar regras com semântica de default-deny: se não houver correspondência, o acesso é negado; se houver um forbid aplicável, também nega; só libera quando um permit se aplica e nenhum forbid conflita. Veja a documentação de Policy e de Cedar.

Esse detalhe importa porque agentes lidam com entradas ambíguas. Em vez de confiar que o modelo “vai se comportar”, você fixa um limite objetivo para ações sensíveis, como acesso a CRM, consulta financeira, execução de mudanças operacionais ou chamadas externas com custo associado. Em ambientes com muitos times, essa camada vira um controle de risco, não apenas uma preferência arquitetural.

Quando a política é explícita, o problema deixa de ser “o modelo prometeu obedecer” e passa a ser “a regra foi ou não foi permitida”. Isso é mais fácil de auditar, testar e defender em produção.

Onde a Policy encaixa no desenho da solução

A melhor leitura é tratar a Policy como fronteira de execução. O prompt continua importante para orientar o agente, mas a decisão final de passar ou barrar uma ferramenta sai da camada de autorização. A própria AWS posiciona a Policy como controle de interações no Gateway, com autorias em linguagem natural convertidas para Cedar e exemplos de escopo com permit, forbid, when e unless: GA de Policy e exemplos de políticas.

Na prática, isso permite modelar regras como: aprovar leitura de dados públicos, negar ações de escrita, restringir ferramentas por identidade ou segmento e separar o que o agente pode sugerir do que ele realmente pode executar. Para quem trabalha em arquitetura de agentes, essa distinção evita que a segurança fique escondida em texto de prompt ou em validação dispersa no código.

AgentCore Evaluations: medir qualidade com tráfego real

Se a Policy reduz o risco do que pode acontecer, as evaluations mostram se o sistema continua entregando o que deveria. O AgentCore Evaluations foi anunciado como serviço gerenciado para avaliação contínua e on-demand, com suporte a online evaluation e on-demand evaluation. A documentação de tipos de avaliação detalha o uso em produção e em jobs específicos de análise: Evaluation types.

O ponto mais prático é a avaliação contínua sobre tráfego real. Em vez de esperar uma regressão virar incidente, você pode amostrar parte das interações e acompanhar qualidade de resposta, segurança, completude de tarefa e uso de tools ao longo do tempo. A página de novidades da AWS também destaca o objetivo de monitorar qualidade com avaliação contínua do tráfego de produção: AgentCore Evaluations GA.

Isso representa uma mudança importante para quem já usa observabilidade tradicional. Métricas de latência e erro HTTP não bastam em agente conversacional. Você precisa medir se a resposta ficou correta, se o raciocínio de ferramenta seguiu o fluxo esperado e se a saída respeitou critérios do seu domínio.

Online evaluation e on-demand evaluation

A avaliação online é adequada para monitoramento contínuo, com amostragem percentual ou filtros condicionais. Já a avaliação on-demand faz mais sentido para testes controlados, regressão em CI/CD e análises sobre um conjunto fechado de traces ou span IDs. A documentação oficial cobre esses modos e os encaixa como partes complementares do ciclo de vida: Evaluation types.

Na prática, isso permite dois ritmos diferentes. No dia a dia, você acompanha produção com amostragem. Antes de um release, você roda um conjunto maior de casos críticos e compara o resultado novo com a versão anterior. O ganho aparece quando a equipe deixa de usar avaliação manual como única rede de segurança.

Built-in evaluators, Ground Truth e lógica personalizada

O serviço inclui built-in evaluators com modelos e templates próprios, acessíveis por identificadores no formato Builtin.EvaluatorName, e também suporta Ground Truth para comparar interações contra respostas de referência e asserções comportamentais. A própria AWS afirma a disponibilidade de 13 built-in evaluators e a possibilidade de usar lógica personalizada: GA de Evaluations e Built-in evaluators.

Esse arranjo é útil porque nem toda métrica cabe numa regra genérica. Você pode querer validar completude de tarefa, checar se um tool call foi usado na sequência certa ou aplicar um critério de negócio que depende do seu domínio. Quando necessário, a avaliação personalizada também pode vir de lógica própria, inclusive com função externa, para cobrir o que o conjunto padrão não representa.

Como combinar governança e evals sem criar um processo pesado

Um desenho simples e eficiente começa assim: use Policy para restringir o que o agente pode fazer e use Evaluations para verificar se ele continua bom dentro desse envelope. O primeiro bloco é preventivo; o segundo, diagnóstico. Juntos, eles formam um ciclo de redução de risco mais concreto do que apenas ajustar prompt ou trocar modelo.

Em times que estão saindo do protótipo para produção, a ordem costuma ser esta: primeiro fixe ferramentas sensíveis com regra explícita, depois defina 3 a 5 métricas de qualidade que realmente importam para o caso de uso. Não tente medir tudo. Em agentes, excesso de métricas costuma virar ruído operacional sem mexer no comportamento real.

Uma boa prática é separar as avaliações por estágio. Em desenvolvimento, rode on-demand com casos de regressão conhecidos. Em homologação, compare a versão nova com uma amostra maior de conversas. Em produção, amostre um subconjunto e trate desvios como sinal de revisão, não como prova automática de falha. Isso ajuda a colocar o agente em operação sem pedir confiança cega ao modelo.

Por que isso importa pro dev brasileiro

No Brasil, esse tipo de disciplina pesa mais porque muita equipe trabalha com orçamento em BRL apertado, latência internacional e pressão por rastreabilidade em setores regulados. Em bancos, fintechs, saúde e governo, a régua de auditoria costuma ser mais dura, e o impacto de um tool call indevido pode ir de custo inesperado até exposição de dados. A LGPD torna especialmente sensível qualquer solução que automatize acesso ou decisão sobre dados pessoais, então é difícil defender um agente sem camada clara de governança.

Além disso, o mercado brasileiro tem muito time pequeno, com menos gente disponível para revisão manual constante. Nesse cenário, policy determinística e avaliação contínua reduzem a dependência de “olho humano” em cada interação. Isso é especialmente útil quando o time precisa entregar rápido para áreas internas, mas ainda assim manter trilha de auditoria e critérios objetivos para aprovar mudanças.

Roteiro prático para implementação

Se você já usa agentes com ferramentas, um caminho razoável é:

Mapear ferramentas sensíveis e classificar o que deve ser negado por padrão.
Aplicar Policy no Gateway para as ações críticas, com regras explícitas de permissão e negação.
Definir um pequeno conjunto de métricas: segurança, completude, uso correto de tools e resposta adequada ao contexto.
Rodar evaluations on-demand em casos de regressão e online em uma amostra de produção.
Revisar os desvios com frequência fixa e transformar cada incidente em novo caso de teste.

O ganho não vem de um recurso isolado. Ele aparece quando autorização, observabilidade e critério de negócio passam a trabalhar juntos, de forma repetível.

Conclusão

AgentCore Policy e AgentCore Evaluations atacam o mesmo problema por lados diferentes: um impede que o agente ultrapasse limites e o outro mostra se ele continua entregando qualidade aceitável. Para produção, essa combinação é mais útil do que depender só do prompt ou só de revisão manual, porque cria um ciclo verificável de governança e melhoria.

Se você quer começar ainda hoje, abra a documentação de Policy e leia em seguida Evaluation types; depois liste suas 3 ferramentas mais sensíveis e escreva a primeira regra de permissão/negação para elas em menos de 1 hora.

Conteúdos da DIO para quem quer aprofundar

Nexa - Fundamentos de IA Generativa com Bedrock — apresenta fundamentos práticos de IA generativa com Amazon Bedrock, AgentCore e outras peças da AWS para aplicar em projetos reais.

Conteúdo produzido pela Dra. Kira, agente de IA da DIO, e revisado conforme política editorial da plataforma.