AWS Bedrock Agents: governança e avaliação no runtime

TL;DR

A AWS ampliou o Amazon Bedrock AgentCore com dois blocos que mudam a conversa sobre agentes em produção: Policy, para impor regras em tempo real antes de uma tool rodar, e Evaluations, para medir qualidade com dados de comportamento real. Na prática, isso tira a governança do plano só declarativo e coloca parte dela no runtime, onde os riscos aparecem de verdade.

Para times que querem operar agentes com mais previsibilidade, a novidade importa menos por “ter mais uma feature” e mais por aproximar controle, observabilidade e critérios de qualidade do ciclo vivo do agente. Em ambientes com requisitos de auditoria, isso ajuda a ligar engenharia de IA à operação de software, não só ao prompt.

O que mudou no Amazon Bedrock AgentCore

A AWS apresentou o Amazon Bedrock AgentCore com quality evaluations e policy controls como uma camada para “trusted AI agents”. O ponto central é que a plataforma passa a combinar enforcement e measurement no fluxo do agente, em vez de depender apenas de regras no aplicativo.

Há dois movimentos aqui. O primeiro é o de Policy, descrito pela AWS como um mecanismo que intercepta tool calls antes da execução. O segundo é o de Evaluations, que monitora qualidade a partir de comportamento real, incluindo avaliadores nativos e customizados.

Policy no runtime: bloquear antes de executar

Na visão da AWS, a Policy atua no caminho da chamada de ferramenta, o que muda o tipo de governança possível. Não é só “espero que o agente siga instruções”; é “essa ação pode ou não pode acontecer agora”, com base em sinais do contexto e regras definidas na camada do gateway.

Esse detalhe é importante porque tool calling é um dos pontos mais sensíveis de qualquer agente. Se o agente consegue abrir um ticket, consultar dados, chamar uma API interna ou acionar automação externa, o erro deixa de ser só textual e vira ação concreta. A documentação do produto deixa claro que o objetivo é permitir controle fino sobre o que roda no runtime, com base em políticas do agente.

Para quem já trabalha com segurança em APIs, a analogia útil é pensar em uma combinação de autorização e interceptação. A diferença é que, aqui, o “cliente” é um agente que decide próximos passos dinamicamente, o que torna a governança mais difícil de deixar só no código de aplicação.

Evaluations online: medir comportamento real, não só benchmark

O outro eixo é a avaliação contínua. A AWS fala em built-in evaluators para dimensões como correctness e helpfulness, além de custom evaluators para regras de negócio. Isso aproxima a operação de agentes de um modelo de qualidade contínua, e não de uma bateria única de testes antes do deploy.

A documentação de get online evaluation e update online evaluation mostra que a configuração de avaliação pode ser consultada e atualizada ao longo do tempo. Em outras palavras, dá para ajustar avaliadores, fontes de dados e regras conforme o agente evolui.

Isso é especialmente relevante em produtos com comportamento mutável. Um agente que hoje atende perguntas simples pode amanhã ganhar novas tools, outro contexto de autorização ou novos padrões de resposta. Sem avaliação online, o time só descobre a degradação quando o usuário reclama.

CRUD de configuração: governança vira operação

A API CreateOnlineEvaluationConfig reforça que a avaliação não é uma ideia abstrata; ela vira configuração operacional. O mesmo vale para a leitura de estado da avaliação via endpoint de consulta.

Esse desenho é bom para times que precisam auditar mudanças. Quando um novo avaliador entra, ou quando uma fonte de dados muda, isso deixa de ser uma alteração informal “no prompt” e passa a ser uma configuração rastreável. Em ambientes com incidentes e revisão posterior, essa diferença conta muito.

Por que isso importa para agentes em produção

O grande problema de agentes não é só resposta errada. É o conjunto de falhas que mistura decisão, contexto, tool use e impacto operacional. Governança no runtime tenta fechar justamente esse intervalo entre intenção e execução.

Na prática, isso reduz a dependência de controles espalhados. Em vez de tentar enfiar segurança, observabilidade e qualidade dentro do mesmo prompt, o time pode separar responsabilidades: o agente decide, a policy valida, e o evaluation mede. Esse desenho tende a ser mais legível para plataformas e para times de segurança.

O conteúdo oficial da AWS também posiciona o AgentCore como uma camada para “deploying and operating effective agents securely” na overview do produto. Esse wording é importante porque mostra que a empresa está tratando agentes como workload operacional, não como demo de laboratório.

O que muda no dia a dia do time

Para engenharia, a consequência mais prática é sair de controles frágeis e entrar em políticas testáveis. Um agente que chama ferramentas com frequência precisa de limites claros: quais ações podem ser executadas, em que contexto e com que nível de confiança.

Para produto, o ganho é conseguir observar qualidade ao longo do uso real. Isso ajuda a distinguir erro pontual de degradação estrutural. Se o avaliador custom começa a marcar queda numa regra de negócio específica, o time sabe onde mexer.

Para segurança, o valor está no ponto de interceptação. Bloquear tool calls antes da execução evita que a correção dependa só de revisão posterior ou detecção passiva. Em workloads com dados sensíveis, isso muda bastante a postura operacional.

Exemplo de leitura arquitetural

Uma forma simples de interpretar essa atualização é pensar em três camadas. A primeira define o que o agente pode tentar fazer. A segunda decide se a ação passa. A terceira mede se o resultado ficou dentro do esperado.

Esse arranjo conversa bem com ambientes já acostumados a controles de acesso, pipelines de observabilidade e métricas de qualidade. O diferencial é trazer esses conceitos para o ciclo do agente, em vez de tratá-lo como uma caixa-preta acima da plataforma.

Num sistema que manipula pedidos, por exemplo, a policy pode impedir a ferramenta de cancelamento quando o perfil não permite a ação. Em paralelo, um evaluator custom pode verificar se a resposta final segue um formato exigido pelo negócio. O ganho está na combinação desses controles, não em qualquer um isoladamente.

Analogias úteis: avaliação contínua é mais próxima de SRE do que de benchmark

Benchmark isolado mede uma fotografia. Avaliação online se parece mais com monitoramento operacional. O agente está em uso, os contextos mudam e a qualidade precisa ser observada ao longo do tempo.

Isso é coerente com a forma como sistemas distribuídos são operados há anos. Não basta testar uma vez e assumir estabilidade. Quando o fluxo é dinâmico e há integrações externas, o valor está em feedback rápido e em regras de intervenção no caminho crítico.

Para quem vem de engenharia backend, o paralelo com circuit breaker, policy enforcement e métricas de SLO ajuda a enxergar a novidade sem exagero retórico. A diferença é que, agora, a decisão não é sobre um request HTTP comum, e sim sobre o próximo passo de um agente.

Por que importa pro dev brasileiro

O contexto brasileiro torna essa atualização particularmente relevante por um motivo bem concreto: LGPD. Quando um agente acessa dados pessoais, histórico de atendimento ou informações transacionais, o risco não é só técnico; é regulatório. Uma policy no runtime ajuda a reduzir exposição de ações indevidas antes que elas aconteçam.

Outro ponto é custo e latência. Muitos times no Brasil operam com orçamento mais apertado e com dependência forte de regiões como us-east-1 por preço e ecossistema. Isso aumenta o impacto de retrabalho, incidente e chamada desnecessária de tool, porque cada ação errada vira custo real em dólar e tempo de resposta percebido pelo usuário.

Há também um traço bem brasileiro de formação em software: muita gente chega a IA por bootcamp, mudança de carreira ou atuação em produto e suporte, não por um laboratório de pesquisa. Nesse cenário, uma camada de governança mais explícita ajuda o time a transformar uma solução experimental em algo operável, sem depender de heróis no plantão.

Se você trabalha com banco, varejo, saúde ou govtech no Brasil, esse tipo de recurso conversa diretamente com auditoria e rastreabilidade. Em setores regulados, poder dizer “a tool foi bloqueada antes de executar” vale mais do que explicar depois por que o agente tomou uma rota indevida.

Como ler a novidade sem cair no hype

É tentador tratar qualquer anúncio de agente como se resolvesse governança por completo, mas não é o caso. Policy e evaluations ajudam, porém continuam exigindo desenho de acesso, logging, versionamento de regras e validação de dados.

Também vale notar que avaliadores automáticos não substituem revisão humana em requisitos críticos. Eles reduzem o volume de falhas óbvias e ajudam a monitorar tendência, mas não eliminam a necessidade de critérios de negócio bem definidos.

Em resumo: a atualização é valiosa porque aproxima a operação de agentes do que times de plataforma já fazem com outros sistemas críticos. Isso atende melhor a produção do que confiar apenas em prompt engineering.

Conclusão

O movimento da AWS com AgentCore aponta para uma maturidade importante: agentes precisam de controle no runtime e medição contínua, não só de boas intenções no prompt. Para times que querem colocar IA em fluxo real, a combinação de policy enforcement e online evaluations cria uma base mais sólida para operar com segurança e acompanhar qualidade ao longo do tempo.

Se o seu time já usa AWS, o próximo passo mais útil é revisar onde um agente poderia executar ações sensíveis sem bloqueio explícito, e depois mapear quais sinais de qualidade ainda não estão sendo monitorados. Em até 1 hora, abra a documentação oficial de update online evaluation e alinhe um rascunho de policy para uma tool crítica do seu fluxo atual.

Conteúdos da DIO para quem quer aprofundar

• Nexa - Fundamentos de IA Generativa com Bedrock — trilha curta e prática para aplicar recursos da AWS, incluindo Amazon Bedrock, em soluções reais e projetos guiados.
• Aceleração Microsoft AI Agents — evento prático para entender desenvolvimento com agentes e ferramentas de IA em cenários aplicados.
• CI&T - Backend com Java & AWS — trilha para quem quer consolidar backend com AWS, APIs e deploy em nuvem com foco em aplicações escaláveis.

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