Nove em cada dez vezes que um agente de IA é colocado em produção hoje, ninguém sabe se ele funciona. O time testou algumas vezes, achou que estava bom, aprovou o deploy, e a partir daí só descobre que algo quebrou quando um cliente reclama.

Esse é o anti-padrão dominante da automação com IA em 2026. Na DevCon 5 de abril, a Palantir apresentou a contracurva: Eval-Driven Development. A ordem é invertida. Primeiro se escreve o teste, depois se confia na saída.

A prática parece trivial. A implementação não é. Sem Ontologia Operacional estruturada, não existe ground truth para testar. Sem ground truth, eval-driven vira teatro.

O anti-padrão que todo mundo pratica: confiar no "sentiu bom"

A demo de referência da DevCon 5 começa com um cenário comum: uma fábrica onde um safety officer lê centenas de incidentes por semana, cruza com regulamento OSHA, decide severidade, dispara ação corretiva. Operação tediosa, humana, lenta.

Primeiro instinto do time técnico: automatizar com LLM. Passa o incidente num prompt, pede categorização, severidade e ação recomendada. O primeiro resultado parece excelente. Aprovação. Produção.

Três semanas depois, o time descobre que a IA prescrevia ações erradas em 90% dos casos. Não porque o modelo era ruim. Porque ninguém testou com os casos certos antes.

Esse é o caso real que a Palantir apresentou na keynote. A lição não é sobre o erro de 90%. É sobre o método que deixou o erro passar.

O que Eval-Driven Development realmente é

EDD é um ciclo em cinco passos, onde o teste vem antes da confiança:

  1. Gerar a lógica primária (primeiro rascunho do agente, prompt, regras, tools).
  2. Gerar a suite de testes representativos (10 a 50 casos que cobrem cenários típicos, raros e adversariais).
  3. Rodar o teste, medir accuracy (quantos casos passam, em qual métrica objetiva).
  4. Debugar com base nas falhas (não no feeling, nos casos específicos que falharam).
  5. Iterar até o teste passar (refinar prompt, adicionar regras, ajustar lógica, rodar de novo).

A mudança de mentalidade é essa: o agente não vai para produção porque parece estar funcionando. Vai porque passou numa bateria de testes que mede o que importa.

Na demo da Palantir, o primeiro rascunho do agente falhou em 9 de 10 casos. Na segunda iteração, com prompt refinado a partir do debug objetivo dos erros, passou em 9 de 10. O time jamais teria percebido isso por eyeballing. A suite de testes foi o que capturou.

Por que Ontologia Operacional é pré-requisito

EDD parece uma prática de engenharia. É. Mas sem dados estruturados, regras tipadas e ações rastreáveis, nem começa.

Pense no teste: você precisa de casos históricos com entrada e saída esperada. Se seus dados operacionais estão espalhados em planilhas, prints de WhatsApp e memória do gerente, você não tem o conjunto de treino. Vai inventar casos que não refletem o problema real.

Precisa também de métricas objetivas. "A saída está boa?" não mede nada. "A ação corretiva sugerida bate com a que o especialista humano tomou em 80% dos casos reais?" mede. Métrica objetiva só existe quando as ações são verbos tipados, não frases soltas.

Por fim, precisa de um feedback loop que alimenta o próximo ciclo. Quando o agente erra em produção, o erro precisa virar caso novo na suite. Isso só acontece se feedback for objeto estruturado linkado ao incidente original, não string em chat.

Todos os três itens, dados estruturados, regras tipadas e feedback rastreável, são exatamente os componentes da tríade D+L+A que forma a Ontologia Operacional. Ontologia Operacional é o pré-requisito para que Eval-Driven Development funcione, e sem ela a automação com IA continua sendo teatro de prototipo.

Como aplicar na sua empresa sem contratar a Palantir

O princípio é acessível. O que separa quem aplica de quem não aplica é rigor operacional, não ferramenta cara.

Passo 1. Dataset de ground truth. Antes de escrever qualquer automação, reúna 30 a 50 casos históricos reais do processo que você quer automatizar. Entrada completa, saída que o humano deu, justificativa breve quando houver. Esse é seu gabarito.

Passo 2. Métrica objetiva única. Escolha uma métrica que você consegue calcular automaticamente. Acerto da categoria, ação correta escolhida, valor extraído correto. Tem que ser binário ou numérico, não subjetivo.

Passo 3. Primeiro rascunho e rodada zero. Construa o agente mais simples possível. Rode contra os 30 casos. Meça. Espera-se que falhe feio, é isso mesmo.

Passo 4. Debug nas falhas específicas. Para cada caso que falhou, leia o que o agente fez, por que errou, e ajuste. Pode ser prompt, regra explícita, tool faltando, contexto não fornecido. A falha é o melhor professor.

Passo 5. Re-rodar até passar. Repita até atingir o limiar que seu caso de negócio tolera. Triagem médica pede 99,9%. Prospecção comercial, 80% já ajuda. Depilação a laser, 95%.

Esse ciclo é o que separa o agente que entrega valor do agente que só parece inteligente. O próprio framework que usamos na FSTech para desenvolver opera nessa ordem, e é o mesmo princípio que a Palantir acabou de nomear formalmente.

O meta-padrão: agentes construindo agentes

A parte mais provocativa da DevCon 5 foi um segundo agente apresentado na mesma demo. O time percebeu que o feedback dos operadores em produção era ruim demais para ser útil. Comentários como "isso está errado" sem contexto não ensinam nada ao agente principal.

A solução foi construir um segundo agente, menor, que intercepta feedback ruim e pergunta clarificações ao usuário antes de registrar. "Por que está errado? Qual seria a saída correta? O que faltou?" Treina o humano a dar feedback útil, enquanto enriquece o dataset que alimenta o agente principal.

O efeito composto é o que a Palantir chamou de agents building agents building agents. Não é autonomia caótica. É recursão controlada, onde cada nível tem uma função específica. E todo o ciclo é orquestrado pela ontologia, que serve como substrato compartilhado entre humanos e agentes.

O que isso muda para quem contrata IA

Se você vai contratar automação com IA em 2026, faça duas perguntas ao fornecedor antes de fechar:

  1. Qual a suite de testes automatizada que roda contra esse agente, e qual a accuracy atual dela? Se a resposta for silêncio, respiração ou "testamos manualmente", é sinal de que o prototipo vai virar problema operacional seu.
  2. Como o feedback de produção é estruturado e realimenta o ciclo? Se a resposta envolve log puro, chat de suporte ou planilha manual, o agente não vai melhorar com o tempo. Vai degradar.

Quem tem essas duas respostas prontas está operando em modo Eval-Driven. Quem não tem está vendendo prototipo caro como produto.

Fechamento

A Palantir nomeou Eval-Driven Development como paradigma central do AIFDE. Não inventou. Formalizou o que já fazia e forçou o mercado a olhar.

A lição para quem opera fora da Palantir é mais simples do que parece. Sem Ontologia Operacional, IA vira teatro de prototipo. Com OO e EDD, vira agente que opera, aprende e compõe valor real.

Colocar IA em produção sem eval é colocar IA em produção sem segurança. O custo aparece depois, em silêncio, e cobra mais do que teria custado testar antes.