A demo foi perfeita. O agente respondeu tudo, o comitê aplaudiu, o orçamento foi aprovado. Seis meses depois, o piloto está congelado: respostas inconsistentes, alguns erros constrangedores na frente de um cliente, e ninguém sabe dizer se a versão de hoje é melhor ou pior que a do mês passado. O modelo não falhou. Falhou algo mais básico: ninguém estava medindo.
O número que dá título a este artigo é o que usamos nas nossas próprias apresentações: cerca de 73% dos projetos de IA nunca chegam à produção. E depois de vários anos construindo agentes para empresas mexicanas, na SISCON o padrão é claro: quase nunca o projeto morre por falta de tecnologia. Morre por falta de evidência. Sem uma forma sistemática de medir qualidade, cada mudança é uma aposta, cada erro é uma crise e cada reunião de acompanhamento é uma discussão de opiniões.
A demo não é o produto
Toda demo é construída sobre casos felizes: as dez perguntas que a equipe já sabe que funcionam bem. Produção é outra coisa — é a distribuição completa do que os seus usuários reais perguntam, com erros de ortografia, contexto incompleto, casos-limite e má-fé ocasional. Um sistema de IA que parece brilhante em vinte casos pode ter 60% de precisão em mil casos reais, e ninguém saberá até o erro caro aparecer.
Os sistemas tradicionais de software têm uma rede de segurança que damos como certa: os testes. Ninguém coloca um sistema de faturamento no ar sem testes automatizados. Mas com a IA, por alguma razão, as empresas aceitam implantar sistemas probabilísticos — que por definição erram às vezes — sem nenhuma bateria de testes equivalente. É exatamente o contrário do que deveria ser: quanto menos determinístico é um sistema, mais ele precisa de medição sistemática.
O que significa "medir" um sistema de IA
Medir não é "testamos um pouco e parece bom". A disciplina — que Chip Huyen sistematiza no livro AI Engineering (O'Reilly, 2025), a referência atual da área — se apoia em três peças:
- Golden sets. Um conjunto curado de casos reais com a resposta correta esperada, validado pela sua equipe de negócio — não pelo fornecedor. Cem casos bem escolhidos valem mais que mil inventados. É a sua régua: fixa, versionada e compartilhada.
- Juízes automáticos (LLM-as-judge). Um modelo avaliador, calibrado contra critério humano, que pontua cada resposta do sistema: está correta? está fundamentada nos documentos? respeitou o formato e o tom? Isso permite avaliar centenas de casos em minutos, não em semanas de revisão manual.
- Testes de regressão. Cada mudança — um prompt ajustado, um modelo atualizado, um documento novo na base de conhecimento — roda contra o golden set completo antes de chegar à produção. Se a qualidade cair abaixo do limite acordado, a mudança não passa. Igual a um pipeline de CI/CD, mas para comportamento.
O custo de não medir é silencioso (até não ser)
O traiçoeiro de operar IA sem evals é que as regressões não avisam. Você muda uma linha do prompt para corrigir um caso e, sem saber, quebra outros doze. Seu fornecedor atualiza o modelo por trás da API — algo que acontece várias vezes por ano — e o comportamento do seu sistema muda de um dia para o outro sem que ninguém tenha tocado em nada. Um agente que vinha respondendo bem há três meses começa a inventar números em um caso-limite que nunca esteve nos testes manuais.
Sem medição, cada um desses eventos é descoberto em produção, diante de um usuário ou de um cliente. E aí o custo já não é técnico: é de confiança. Um único erro visível diante do comitê diretivo pode congelar um programa inteiro de IA — não porque o sistema seja ruim, mas porque ninguém consegue demonstrar com dados que ele é bom.
Avaliar não é um projeto: é uma disciplina
O erro comum é tratar a avaliação como uma entrega única: "fizemos o benchmark inicial, está pronto". Os evals valiosos são os que vivem no seu pipeline: rodam a cada mudança, rodam de madrugada contra o tráfego do dia e alimentam um painel onde negócio e tecnologia veem a mesma verdade. É assim que se responde em segundos a pergunta que mata pilotos: "está melhorando ou piorando?"
Essa mesma bateria é também o que permite tomar decisões maiores com evidência e não com marketing: vale a pena trocar de modelo? a versão open source alcança a qualidade da API comercial por uma fração do custo? um fine-tuning melhoraria o suficiente para se justificar? Sem evals, essas perguntas são respondidas por intuição. Com evals, são respondidas com números dos seus casos e dos seus dados.
Por onde começar esta semana
- Junte 50–100 casos reais da sua operação (chamados, e-mails, consultas) com a resposta que você considera correta. Esse é o seu primeiro golden set.
- Rode o seu sistema atual contra eles e anote o resultado. Esse número — o que você hoje não tem — é a sua linha de base.
- Defina o limite de implantação: nenhuma mudança vai para produção se o resultado cair abaixo de X%. Escreva e comunique.
- Automatize a execução no seu pipeline com ferramentas como Langfuse ou promptfoo, para que medir não dependa de alguém lembrar.
- Revise as falhas toda semana e transforme os novos erros reais em casos do golden set. O conjunto cresce com a sua operação.
Este é exatamente o tipo de trabalho que formalizamos no nosso serviço de Avaliação e Auditoria de IA: construir a bateria com os seus casos, calibrar juízes automáticos contra o seu critério e deixá-la rodando no seu pipeline — como parte do harness que torna um agente confiável. Porque a conclusão de anos vendo pilotos morrerem é simples: a IA que não se mede não se pode defender. E a que não se pode defender não sobrevive ao comitê.