AWS propõe framework de nove etapas para avaliar agentes de IA em produção

AWS publicou em 16 de outubro de 2026 um framework de nove etapas para avaliar agentes de IA em produção com Amazon Bedrock AgentCore. A ideia central é simples, mas frequentemente ignorada: disponibilidade, latência e taxa de erro não bastam para provar que um agente continua confiável. Um sistema pode responder rápido, sem falhas de infraestrutura, e ainda entregar um número inventado, usar a conta errada ou interpretar um período financeiro de forma incorreta.

O material descreve como a equipe de Sales, Marketing and Global Services (SMGS) da AWS estruturou avaliações para agentes que consultam dados de vendas e clientes. Embora os exemplos venham de um ambiente interno da empresa, o método é útil para qualquer organização que use agentes com ferramentas, RAG, dados corporativos ou múltiplos subagentes. O ponto mais importante para equipes brasileiras não é adotar um produto específico: é transformar qualidade em uma disciplina operacional mensurável antes de colocar decisões importantes nas mãos de um agente.

O problema: agentes falham de forma silenciosa

Software tradicional costuma falhar de maneira evidente: uma API retorna erro, um serviço cai ou um teste quebra. Agentes de IA introduzem um tipo diferente de incidente. Eles podem produzir uma resposta bem escrita, com aparência segura e sem qualquer erro técnico, mas incorreta no conteúdo. Esse padrão é especialmente perigoso quando a resposta influencia preços, receita, contratos, atendimento, risco ou decisões de gestão.

A AWS relata que, antes do lançamento do seu sistema, encontrou respostas como uma receita de US$ 410,08 apresentada como “US$ 410,08 milhões”, métricas trocadas, estimativas de receita recorrente inexistentes na base e cálculos próprios exibidos como se fossem dados de origem. O monitoramento convencional permanecia verde porque o sistema estava respondendo; ele simplesmente estava respondendo errado.

Esse risco aumenta quando o agente depende de dados que mudam sem um novo deploy. Atualizações de esquema, índices de busca, permissões, ferramentas externas, prompts e modelos podem alterar o resultado. A AWS cita um teste de pré-produção em que uma janela de desencontro entre atualização de dados, ferramenta e prompt reduziu a taxa de aprovação de 78% para 38%. A conclusão é que avaliação não pode ser uma etapa final de QA: ela precisa acompanhar todo o ciclo de vida do agente.

Os cinco eixos que devem ser avaliados

O framework organiza a operação em cinco dimensões simultâneas. Qualidade é a mais visível, mas não substitui segurança, custo ou capacidade de resposta a incidentes.

Na prática, isso evita uma decisão equivocada comum: trocar para um modelo que melhora a taxa de acerto em alguns testes, mas dobra a latência ou triplica o custo. Uma melhoria só é real se respeitar os limites definidos para o serviço inteiro.

O framework de nove etapas da AWS

1. Fundação: defina o que significa “bom”

A primeira etapa começa com o resultado de negócio, não com o modelo. Antes de medir “qualidade”, a equipe deve definir quem usa o agente, que decisão será tomada a partir da resposta e qual erro é inaceitável. A AWS recomenda converter esses objetivos em métricas e limites explícitos: regras de segurança, orçamento de latência, custo por consulta, critérios de alarme e tipos de falha.

No caso apresentado, a equipe criou uma taxonomia de seis erros: métrica trocada, período errado, entidade errada, alucinação sem fonte, símbolo ou unidade errados e cálculo não autorizado. Esse tipo de classificação é mais útil do que uma nota única porque aponta o que precisa ser corrigido. Para um agente brasileiro de atendimento, por exemplo, a taxonomia poderia incluir produto errado, condição comercial vencida, política citada fora de contexto e resposta sem evidência no documento oficial.

2. Experimento: compare versões com a mesma base

Toda alteração de prompt, modelo, ferramenta ou dado deve enfrentar o mesmo conjunto de testes, chamado de golden set. A AWS usa avaliações sob demanda para comparar candidatos em qualidade, latência, custo e consumo de contexto. A recomendação prática é não aceitar “parece melhor” como critério de promoção.

Um golden set maduro reúne três origens: perguntas reais anonimizadas, incidentes e regressões já observados, e casos sintéticos de borda. Ele deve ser versionado. Quando uma falha chega à produção, o caso que a revelou precisa entrar permanentemente no conjunto, para que o mesmo erro não volte em uma próxima mudança.

3. Merge (CI): bloqueie regressões antes da integração

Na integração contínua, a AWS executa um conjunto menor de cenários de alto risco — o sentinel set — em cada implantação de staging. O objetivo é manter a verificação rápida sem permitir que uma mudança passe sem avaliação. Um desvio de qualidade, segurança, latência ou custo além do limite bloqueia a mudança.

O detalhe importante é avaliar em três níveis: ferramenta, agente e sistema multiagente. Uma rota aparentemente correta pode depender de uma ferramenta de identificação de cliente que passou a resolver abreviações para a entidade errada. Se só o resultado final for testado, esse problema pode ficar invisível até atingir uma pergunta específica.

4. Gate (CD): aprove produção com critérios quantitativos

O sentinel set é necessário, mas não representa toda a variedade de perguntas de produção. Antes da liberação, a AWS executa o conjunto completo em um ambiente controlado. Para separar erro de raciocínio de instabilidade externa, a equipe congela respostas corretas de ferramentas e as usa como mock. Assim, dois candidatos respondem ao mesmo cenário e qualquer diferença pode ser atribuída ao comportamento do agente, não a uma API lenta ou a dados mudando durante o teste.

O gate não aprova apenas pela média. A AWS descreve três condições: o candidato não pode regredir contra sua execução anterior, deve superar a versão em produção e não pode deixar uma porcentagem definida de perguntas abaixo do limite individual. Esse desenho impede que uma média melhor esconda uma cauda maior de respostas ruins.

5. Canary: procure falhas após a publicação

Nem toda degradação vem de uma alteração de código. Dados, dependências e comportamento do tráfego também mudam. Por isso, a etapa de canário roda em produção com casos sintéticos e tráfego observado, em ciclos regulares. A AWS relata ter adotado janelas de 30 minutos: 15 minutos geravam alertas demais; 60 minutos demoravam demais para revelar uma tendência.

Uma janela isolada não deve acordar a equipe. O exemplo da AWS exige três janelas consecutivas abaixo do limite antes de acionar o plantão, enquanto uma execução diária do conjunto completo confirma o retrato consolidado. É um equilíbrio importante: alertas sem contexto tornam-se ruído; alertas lentos deixam o usuário descobrir o problema primeiro.

6. Adversário: trate segurança como camada permanente

Agentes conectados a documentos e ferramentas precisam ser testados contra uso indevido, especialmente prompt injection, jailbreak, vazamento de instruções e acesso fora de escopo. A AWS aplica guardrails na entrada e na saída de cada interação. A entrada avalia a solicitação e possíveis instruções maliciosas; a saída verifica se dados sensíveis ou uma resposta fora de política seriam expostos.

Para equipes no Brasil, isso é particularmente relevante em fluxos com dados pessoais, financeiros ou trabalhistas. Uma política de acesso não pode existir apenas no prompt: permissões devem ser verificadas pela ferramenta ou pela camada de identidade, e os testes adversariais precisam provar que o agente não contorna esse limite.

7. Drift: aprenda com o tráfego real

Conjuntos sintéticos não cobrem toda a linguagem do usuário. A AWS amostra 10% do tráfego ao vivo para avaliação online e compara os resultados com a linha de base. No caso relatado, usuários passaram a consultar clientes por códigos de ações, apelidos e abreviações; a taxa de identificação caiu de 98% para 81% e depois 80% em três janelas. O sinal levou à ampliação do golden set e à normalização de formatos na ferramenta de desambiguação.

Esse é um padrão reutilizável: perguntas com baixa pontuação não devem ser descartadas como exceção. Elas são insumos para novos testes, ajustes de recuperação, mudanças de ferramentas ou revisão de roteamento entre subagentes.

8. Pulse: transforme sinais em diagnóstico acionável

Quando um agente usa vários subagentes, ferramentas e caminhos de recuperação, “a qualidade caiu” não é um diagnóstico. A AWS combina telemetria de execução, avaliações e armazenamento histórico para permitir que o operador vá de um alarme ao traço que mostra chamadas, ordem, entradas, saídas, latência, tokens e custo.

O princípio é separar painéis por necessidade: plantão precisa de evidência para resolver um incidente; produto precisa de tendências por versão; liderança precisa de um resumo de saúde. Sem esse encadeamento, uma métrica de qualidade vira apenas uma apresentação semanal, não um mecanismo de melhoria.

9. Feedback loop: converta incidentes em prevenção

A última etapa fecha o ciclo. Regressões reais viram novos testes permanentes; grupos de traços com baixa qualidade orientam ajustes de prompt, ferramenta, recuperação ou roteamento; candidatos podem passar por teste A/B com uma parcela do tráfego antes do lançamento completo. A finalidade não é automatizar mudanças sem supervisão, mas reduzir o tempo entre detectar um padrão e validar uma correção.

Como aplicar o método sem copiar a infraestrutura da AWS

O Amazon Bedrock AgentCore é a implementação usada no caso da AWS, mas o processo é independente de fornecedor. Uma equipe pequena pode começar com uma planilha versionada de perguntas críticas, registros estruturados de entrada e saída, um teste automatizado no pipeline e uma revisão humana semanal das respostas de baixa confiança. A escala deve acompanhar o risco do agente.

1. Liste as decisões que o agente pode influenciar. Comece por operações de maior impacto: preços, contratos, suporte, compliance ou dados pessoais.
2. Defina cinco a dez falhas inaceitáveis. Descreva cada uma com um exemplo observável e uma métrica simples.
3. Monte um golden set inicial. Use perguntas reais aprovadas, casos de borda e incidentes anteriores; mantenha a resposta esperada ou critérios de julgamento.
4. Crie um gate pequeno no CI. Rode os casos mais críticos a cada mudança de prompt, modelo, ferramenta ou base de conhecimento.
5. Meça produção sem registrar dados sensíveis indevidamente. Amostre, anonimize quando necessário e avalie tendências, não só exceções.
6. Formalize o caminho do alerta à correção. Todo alarme precisa ter dono, limite, evidência disponível e regra clara para escalar.

Limitações e cuidados

O framework não elimina erros. Avaliadores LLM-as-judge também podem falhar, uma base dourada pode envelhecer e métricas mal definidas podem incentivar otimização para o teste em vez de para o usuário. A própria AWS combina verificações determinísticas, avaliadores personalizados, modelos julgadores e bibliotecas de terceiros justamente porque nenhuma abordagem cobre todos os tipos de erro.

Também é preciso distinguir os resultados específicos da AWS de uma garantia geral. Os percentuais e os tempos apresentados no estudo pertencem ao sistema interno descrito pela empresa; não devem ser tratados como expectativa automática para qualquer agente que adote Bedrock AgentCore ou outra plataforma.

Análise do NoticIA

O valor mais duradouro do anúncio não está no nome de uma ferramenta da AWS, mas na mudança de unidade de trabalho: agentes não devem ser aprovados como aplicativos estáticos. Eles precisam ser tratados como sistemas vivos, em que dado, modelo, prompt, permissões e ferramentas podem modificar a qualidade sem que um único servidor caia.

No mercado brasileiro, muitas implantações ainda medem sucesso por “o chatbot respondeu” ou por redução bruta de tickets. Isso é insuficiente para agentes que consultam ERP, CRM, documentos internos ou bases de clientes. O próximo passo de maturidade é estabelecer contratos de qualidade por tarefa, registrar evidências e tornar cada incidente uma regressão testável. Quem fizer isso antes poderá expandir automação com mais segurança; quem não fizer tende a descobrir falhas de confiança pela reclamação do usuário ou por uma decisão já tomada.

Resumo prático

• Agentes podem degradar sem aumentar latência ou taxa de erro.
• Avaliação deve cobrir segurança, qualidade, desempenho, custo e operação.
• Use golden sets versionados e promova falhas reais para testes permanentes.
• Bloqueie regressões no CI, valide em CD e monitore drift após o lançamento.
• Não dependa de uma nota única: classifique os tipos de erro para conseguir corrigi-los.