ASSERT quer transformar intenção em teste e atacar um ponto fraco real dos agentes
O mercado de agentes já aprendeu a fazer demonstrações convincentes. O que ainda não aprendeu, de forma madura, é provar que esses sistemas se comportam como deveriam fora do cenário ideal. Foi nesse ponto que a Microsoft decidiu mexer ao lançar o ASSERT em 3 de junho de 2026. O projeto, open source, promete converter especificações em linguagem natural em suites de avaliação executáveis para modelos, aplicações e agentes.
O que aconteceu
A sigla ASSERT significa Adaptive Spec-driven Scoring for Evaluation and Regression Testing. Na prática, a Microsoft está propondo um pipeline em quatro etapas: transformar uma intenção ampla em especificação mais explícita, converter isso em uma taxonomia de comportamentos permitidos e proibidos, gerar casos de teste estratificados e, por fim, executar e pontuar cada rastro do sistema avaliado. A ferramenta registra não só a resposta final, mas também chamadas de ferramenta, contexto recuperado e ações intermediárias.
O anúncio é importante porque mira um problema que times reais conhecem bem. Requisitos de comportamento costumam estar espalhados em PRDs, políticas internas, system prompts, notas de revisão e checklists. O salto difícil é transformar esse material em avaliação viva, auditável e atualizável. Sem isso, times acabam recorrendo a métricas genéricas como relevância, groundedness ou toxicidade, que ajudam, mas quase nunca capturam limites específicos de produto.
A técnica por trás
O insight do ASSERT é tratar a especificação de comportamento como insumo de primeira classe, não pano de fundo. Em vez de gerar alguns prompts e medir acerto superficial, o sistema tenta decompor o que significa um bom comportamento naquele contexto. Se o agente é de viagem, por exemplo, ele não deve inventar passagens, violar orçamento, obedecer injeção vinda de uma ferramenta ou fazer estereótipos sobre o usuário. São regras diferentes, com rastros diferentes, que exigem casos distintos.
Tecnicamente, isso melhora cobertura. A própria Microsoft relata estudos internos em que o ASSERT cobriu mais espaço de comportamento, gerou mais casos úteis para inspeção e separou melhor sistemas fortes e fracos do que baselines de geração mais direta. O ganho mais interessante, porém, não é só estatístico. É epistemológico. Ao amarrar cada falha a uma regra, uma racionalidade e um trecho do rastro, a equipe consegue discutir política de produto sem cair em abstrações vagas.
Isso é especialmente relevante para agentes, porque o erro muitas vezes não está na frase final. Ele está no caminho: a ferramenta errada chamada cedo demais, a recuperação de contexto inadequada, a aceitação de uma instrução maliciosa ou uma decisão fora do orçamento. Um sistema que só lê a saída final pode aprovar um comportamento que já estava comprometido várias etapas antes.
Por que isso importa
No momento em que agentes começam a executar tarefas com ferramentas, memória e múltiplos turnos, avaliação deixa de ser luxo acadêmico. Vira pré-requisito operacional. Um agente de suporte pode conceder reembolso fora da política. Um agente de pesquisa pode citar material restrito. Um agente corporativo pode seguir instruções ocultas em documento recuperado. Em todos esses casos, avaliar "qualidade de resposta" é insuficiente.
O ASSERT tenta reduzir exatamente essa lacuna entre intenção escrita e verificação contínua. Para equipes de produto, isso pode significar ciclos mais rápidos de regressão e revisão. Para governança, pode significar evidência mais concreta do que realmente foi testado. Para engenharia, abre a possibilidade de integrar avaliação ao processo de release com artefatos inspecionáveis, não apenas um número agregado.
O futuro que isso antecipa
Se a abordagem pegar, o mercado de agentes deve se tornar menos obcecado por benchmarks universais e mais focado em comportamento contextual. Isso é saudável. Um agente financeiro, um agente educacional e um agente clínico não falham do mesmo jeito, nem devem ser julgados pelos mesmos critérios. O futuro plausível é uma camada de evals muito mais parecida com testes de software e revisão de política do que com ranking público único.
Também há um efeito cultural importante. Equipes serão pressionadas a explicitar melhor suas próprias intenções. "Seja seguro" ou "não seja tendencioso" não bastam quando é preciso gerar casos, traços e critérios executáveis. O ASSERT força um tipo de maturidade: escrever política de comportamento de forma operacional, não apenas aspiracional.
O que observar
Ainda assim, a ferramenta não resolve tudo. A própria Microsoft reconhece limitações. Especificações vagas geram cenários vagos. Juízes baseados em LLM podem variar em severidade. Casos sintéticos não substituem produção, telemetria e revisão humana. Isso é importante porque existe um risco de falsa confiança: achar que uma suite automática bem organizada equivale a conformidade total.
O ponto, então, não é tratar o ASSERT como selo mágico. É enxergá-lo como infraestrutura de aprendizagem para equipes que querem iterar com menos cegueira. Se funcionar como prometido, ele pode marcar uma virada útil no ecossistema: sair do discurso genérico sobre "responsible AI" e entrar num regime em que políticas, traces e regressões finalmente começam a conversar.
Fontes
- https://commandline.microsoft.com/assert-written-intent-executable-evals/
- https://github.com/responsibleai/ASSERT
