Como provar que o agente continua certo depois de publicado

Com o critério de aceite escrito antes da entrega, falta garantir que o agente continue cumprindo o contrato depois de publicado.

Antes de qualquer ferramenta vem uma distinção. Testar uma função determinística (a que sempre devolve o mesmo resultado, como uma calculadora) é verificar que a mesma entrada produz a mesma saída. Testar um agente que recebe instruções, usa ferramentas, consulta memória e toma ações é outro universo: a mesma entrada pode produzir saídas diferentes, e a falha costuma estar na ação, sem aparecer no texto. Por isso a verificação de agente se chama eval (avaliação: a prova que confere a atitude, além da resposta).

Suponha uma clínica pequena cujo agente confirma consultas por mensagem. Ele responde ao paciente com o texto perfeito e, no caminho, consultou uma tabela que não deveria acessar, a de prontuários. Passou em toda verificação de saída e falhou na única que importava.

Essa matriz precisa existir como controle formal e escrito porque os riscos são específicos e já estão catalogados. A referência publicada e aplicável para agentes é o OWASP Top 10 for Agentic Applications 2026, do OWASP Gen AI Security Project (comunidade aberta que lista riscos de software, como um manual de bombeiro), lista separada da de aplicações de modelo de linguagem justamente porque a capacidade de encadear ações faz uma injeção simples cascatear para comprometimento sistêmico, vazamento de dados ou perda financeira.

Seis dessas categorias chegam a um comitê de risco com cara concreta. Sequestro de objetivo é o agente terminar perseguindo uma meta que ninguém pediu. Uso indevido de ferramenta é ele acionar um sistema que estava ao alcance dele e não deveria estar. Abuso de identidade e privilégio é agir com a credencial de outra pessoa, ou com permissão acima da que lhe cabia. Envenenamento de memória e contexto é uma informação falsa entrar no que ele guarda e contaminar todas as decisões seguintes. Falha em cascata é o erro de um agente virar entrada do próximo, que erra por consequência. Agente fora de controle é o laço que não para sozinho e segue consumindo recurso ou tomando ação sem que ninguém tenha notado.

Corrija um mito que circula em comitê de risco: não existe perfil do NIST para agentes. O NIST é o instituto americano de padrões técnicos, uma espécie de Inmetro de lá. A iniciativa de padrões de agente foi anunciada em fevereiro de 2026, as sobreposições de controle para sistemas agênticos seguem em rascunho e o perfil de interoperabilidade está previsto para o último trimestre de 2026. Material produzido por terceiros circula como se fosse perfil agêntico do NIST, e não é. Quem promete conformidade NIST para agentes hoje está vendendo interpretação.

Nenhum teste tradicional alcança esse território. Os que verificam um pedaço isolado do sistema, um de cada vez, não detectam autonomia excessiva; os que verificam vários pedaços conversando entre si não pegam mudança de comportamento depois de uma troca de modelo. Para agente, verificação é avaliação, política, telemetria e controle de alçada, ou seja, do quanto ele pode decidir sozinho.

Os dois movimentos de junho de 2026 aconteceram no mesmo mês e apontam para lados opostos. A AWS levou avaliação em lote, teste A/B (duas versões rodando lado a lado, como provar dois temperos) e recomendações a disponibilidade geral dentro do AgentCore, funcionando inclusive para agentes hospedados fora da AWS. A OpenAI anunciou a depreciação da própria plataforma de avaliações e do Agent Builder.

A lição executiva independe de qual fornecedor você usa. Quem apoiou a verificação numa plataforma de fornecedor perdeu a verificação, e perdeu no pior momento possível: sem a rotina, ninguém sabe se o agente continua se comportando como no dia da aprovação. O que sobrevive a esse tipo de evento é o que fica no seu repositório: casos versionados junto com as instruções, resultado histórico guardado por você e a definição do limite de aprovação escrita fora da ferramenta.

O mesmo raciocínio vale para a instrumentação. As convenções de observabilidade de IA generativa do OpenTelemetry (padrão aberto que registra o que o sistema faz, como a caixa-preta do avião) migraram para repositório dedicado em junho de 2026 e continuam pré-estáveis, sem versão 1.0. Quem promete observabilidade de agente padronizada está vendendo expectativa: o padrão existe, está em uso e ainda muda.

Duas cautelas de método invalidam avaliações bem-intencionadas, e as duas precisam ser conhecidas antes de montar a suíte.

A primeira é sobre quem julga. Quando dois avaliadores olham os mesmos casos, mede-se a concordância entre eles, e o número bruto engana: parte da coincidência acontece por acaso, porque dois avaliadores que chutassem também concordariam em uma fatia dos casos. A maior avaliação sistemática de juízes automáticos até agora, com 21 juízes de 9 fornecedores e cerca de 541 mil julgamentos, aplicou a correção que desconta esse acaso e viu a concordância cair entre 33 e 41 pontos percentuais. Em linguagem de gestão, os números que circulam sobre confiabilidade de juiz automático estão inflados nessa ordem de grandeza.

O achado mais contraintuitivo do mesmo trabalho é que consistência não é validade. Um juiz pode repetir o próprio veredito com precisão altíssima e, ao mesmo tempo, mudar de opinião conforme a ordem em que as respostas aparecem. Na mesma direção, um trabalho de julho de 2026 mediu queda relevante de desempenho de agentes de fronteira em fluxos de trabalho multilíngues frente aos monolíngues, sem publicar a magnitude no resumo. Qualquer avaliação conduzida em português herda essa incerteza e merece uma amostra maior antes de virar critério.

A segunda cautela é sobre o objeto medido reagir à medição, e existe um caso público de junho de 2026 que a torna concreta. Ao avaliar um modelo antes do lançamento, a METR chegou a três números diferentes para a mesma capacidade, e a diferença entre eles veio só de como tratar as tentativas do modelo de explorar brechas do próprio ambiente de teste. Contando as tentativas como falha, o horizonte ficou em 11,3 horas. Contando como acerto, saltou para mais de 270 horas, valor que a própria METR classificou como não confiável. A taxa de exploração de brecha foi a mais alta já observada pela organização em modelo público.

Guarde a leitura executiva: o mesmo modelo mede 11 horas ou 270 conforme a régua trate comportamento oportunista, e nenhuma das duas escolhas é neutra. É essa a justificativa técnica das avaliações ocultas, bem acima da boa prática. Quando o agente enxerga o critério, uma parte do desempenho medido passa a ser desempenho na régua.

A Verificação Noturna, que no material em inglês aparece como Nightly Agentic Verification, transforma a matriz em rotina. O desenho é simples de descrever, e o que importa nele é a divisão de trabalho. Enquanto ninguém está olhando, os agentes reexecutam o conjunto de verificações, registram cada resultado e montam o laudo. Pela manhã, o humano lê o laudo, resolve o que ficou ambíguo e decide o que vira correção. Máquina de noite, julgamento de dia.

Na manhã seguinte o humano revisa evidências, falhas, diferenças críticas, testes novos, arquivos de alto risco e recomendações. Revisão por risco: o princípio da etapa sobre modelo operacional aplicado à rotina diária.

Metade da vida real de um sistema com agentes é o laudo vermelho, e é aí que a maioria dos times cai no pior reflexo: mandar o agente consertar o sintoma, empilhando remendo sobre remendo. O protocolo de triagem tem três regras.

• Causa-raiz antes da correção: diante do vermelho, o agente primeiro gera hipóteses a partir dos registros de execução e da lista do que mudou na janela, e o humano exige prova com dado antes de autorizar qualquer escrita. Remendar o sintoma sem causa é o equivalente, um nível acima, a aceitar snapshot sem análise.
• Escalonamento com teto de tentativas: a autonomia de remediação fica restrita a classes de falha já resolvidas corretamente antes. Se o agente erra a mesma correção um número fixo de vezes, a convenção deste curso é três, o laço para e escala para um humano.
• Dono por classe de falha: cada classe tem responsável definido antes do incidente. Classe nova, sem histórico de resolução, dispara escalação humana automática.

Duas notas de honestidade sobre números que circulam como se fossem consagrados.

O teto de três tentativas é convenção operacional deste curso, ancorada em disjuntor mais escalação por limite. O número exato é calibrável; existir um teto e um dono por classe de falha é o que não é opcional.

Para o conjunto de casos de referência, o dimensionamento segue heurística de guias de engenharia de fornecedores, sem pesquisa revisada por pares atrás: de 5 a 10 exemplos curados por fluxo crítico no início, chegando a 50 ou 100 em regime. Abaixo de cerca de 30 exemplos, a variação normal entre uma execução e outra se confunde com piora real, e o time acaba discutindo ruído convencido de que discute qualidade. Use como ponto de partida e recalibre com os seus dados.

Três decisões, essas sim, são estruturais e independem de calibragem.

• Os casos moram no seu repositório, versionados junto com as instruções do agente, e não dentro da ferramenta do fornecedor.
• O limite de aprovação é comparado grupo a grupo, cada grupo de casos contra o próprio histórico. Um número único para a suíte inteira deixa a piora de um grupo ser compensada pela melhora de outro, e o alerta nunca dispara.
• A varredura hostil é trimestral, e cada rodada acrescenta formas novas de ataque, porque contra a lista do trimestre passado o agente já aprendeu a se defender.

Monte dois documentos do seu time a partir desta aula, começando pelo agente cujo erro não se desfaz.

1. Suíte mínima com ciclo noturno. Para um agente em produção ou planejado, escreva 5 casos de referência, 3 adversariais, incluindo ao menos um de instrução maliciosa escondida, e 2 de política. Defina o limite de aprovação e o que acontece quando ele é violado: bloqueio, alerta ou retorno à versão anterior. Especifique o ciclo noturno que executa essa suíte e redija a pauta de 15 minutos da revisão matinal.

2. Manual de plantão para laudo vermelho. Usando o modelo desta aula, escreva o manual de uma página do seu time: a ordem de causa-raiz antes da correção, o teto de tentativas e o dono acionado por classe de falha. Marque quais classes têm autonomia de remediação e quais disparam escalação humana automática.

Revise os dois documentos contra seis sinais e só dê o trabalho por pronto quando todos aparecerem: (a) todo critério de aceite é verificável por máquina ou está declarado como julgamento humano; (b) o limite de aprovação tem ação definida, além do número; (c) o manual de plantão nomeia um dono por classe de falha antes do incidente; (d) existe pelo menos uma classe que dispara escalação humana automática por não ter histórico limpo; (e) você sabe dizer qual parte da suíte o agente pode ler e qual parte é held-out; (f) casos e série histórica estão no seu repositório, e não apenas dentro da ferramenta do fornecedor.