Se Você Não Consegue Verificar a Saída da Sua IA, Seu Usuário Também Não

Quando uma funcionalidade de IA é difícil de avaliar, a maioria dos times responde construindo um harness de eval maior. Mais casos de teste, mais graders, mais execuções offline. Hamel Husain, que passou três anos construindo evals de IA como profissão, argumenta que a dificuldade aponta para outro lugar. “É difícil de avaliar” costuma ser um sintoma de design de produto. Se você não consegue verificar a saída com facilidade, o problema está em como o artefato foi construído, e nenhuma medição posterior vai consertar isso.

Esse reenquadramento importa porque move o trabalho para cima, de um problema de métrica que o time de ML carrega para um problema de design que o produto inteiro carrega.

Verificar Já Foi de Graça

Por quase toda a história do software, a verificação acontecia de forma incidental. Você escrevia o código e lia o código enquanto escrevia. Redigia o relatório e entendia cada frase porque produzia cada uma delas. Conferir estava tecido dentro de fazer. Raramente aparecia como uma linha separada de trabalho, porque nunca era uma etapa separada.

A IA quebra isso. A saída chega inteira, produzida por um sistema cujo raciocínio você não acompanhou. Agora verificar é um ato distinto, feito depois, sobre um artefato que você não construiu. É a virada que Husain nomeia: com IA, a verificação deixa de ser subproduto da criação e vira o gargalo do fluxo de trabalho.

A Victorino já fez a versão financeira desse argumento. Em Verificação É o Novo Custo de Compute, os números mostraram a avaliação ultrapassando o treinamento como custo dominante, com um único benchmark de agente confiável chegando à casa dos seis dígitos. A contribuição de Husain fica uma camada acima. Antes de perguntar quanto custa rodar a verificação em escala, pergunte por que a saída é tão difícil de conferir logo de início.

O Usuário Herda o Seu Problema de Verificação

Aqui está a frase que deveria reorganizar um roadmap: “Artefatos que são difíceis de verificar para você costumam ser difíceis para os usuários também.” O enquadramento de Husain é direto, e se sustenta.

Se o seu próprio time precisa reconstruir uma análise gerada por IA do zero para confirmá-la, o seu cliente fica sem chance. A dificuldade que você sente construindo o eval é a mesma que o usuário sente toda vez que abre o produto. Uma saída difícil de verificar é um defeito que o usuário vive diretamente, como dúvida, como retrabalho, como a decisão silenciosa de parar de confiar na funcionalidade.

Husain oferece um dado desconfortável para tornar isso concreto. Em um time de dados, cerca de metade do tempo ia para revisar análises meio prontas da IA, e cerca de metade dessas análises acabava incorreta. Trate esses números como ilustrativos, não medidos, porque é assim que ele os apresenta. O formato é o que conta. Quando verificar é caro e a taxa de acerto é cara ou coroa, a IA não economizou trabalho. Ela empurrou o trabalho para baixo e ainda cobrou juros.

Projete a Saída Para Ser Conferível

O conserto fica antes de qualquer grader: projetar a verificabilidade dentro do próprio artefato, para que conferir seja rápido tanto para quem constrói quanto para quem usa. Husain aponta alguns movimentos concretos.

Mostre de onde veio cada parte. “A forma mais rápida de tornar uma saída conferível é mostrar de onde veio cada parte”, escreve Husain. Proveniência, links de origem e citações transformam uma afirmação em que você precisa confiar numa afirmação que dá para checar em segundos. Essa é a mudança de maior alavancagem, porque reduz a verificação de “reconstruir tudo” para “seguir um link”.

Compare contra uma linha de base confiável. Uma saída flutuando isolada obriga o revisor a julgar do zero. Uma saída apresentada como um delta contra algo já confiável, os números do trimestre passado, o template aprovado, a versão anterior, deixa o revisor focar apenas no que mudou. Você encolhe a área que precisa de julgamento.

Quebre a saída em unidades revisáveis. Uma resposta monolítica é aprovar-tudo-ou-nada. O mesmo conteúdo, decomposto em pedaços discretos e verificáveis um a um, deixa o revisor aprovar as partes sólidas e interrogar as duvidosas. A revelação progressiva serve ao mesmo objetivo: mostre o resumo, mantenha a evidência a um clique quando a confiança acabar.

São decisões de produto, tomadas em tempo de design. Ficam antes de qualquer grader e determinam se a avaliação vai ser barata ou ruinosa depois.

Por Que a Verificabilidade É uma Questão de Governança

Verificabilidade projetada no produto é o que torna a confiança auditável. Quando uma saída carrega sua proveniência, a aprovação de um revisor significa algo específico: ele checou as fontes e assinou embaixo. Quando não carrega, a aprovação degrada para carimbo, e você perde a capacidade de saber se alguém de fato verificou alguma coisa.

É o mesmo princípio por trás da verificação por execução: o check mais confiável é aquele que o sistema torna estruturalmente barato de fazer. Design para verificabilidade é essa ideia aplicada na interface. Ela decide, antes de coletar uma única métrica, se os seus humanos conseguem supervisionar a IA ou estão apenas aprovando saídas que não têm como inspecionar.

Um produto que esconde seu raciocínio pontua mal nos evals e faz algo pior: treina silenciosamente seus usuários a parar de olhar, e um time que parou de olhar não está governando nada.

Faça Isso Agora

Pegue a sua funcionalidade de IA mais difícil de avaliar, aquela para a qual o time sempre pretende escrever mais testes, e rode um diagnóstico diferente. Sente-se com um usuário real e cronometre quanto tempo ele leva para confirmar que uma saída está correta. Se a resposta for minutos, ou se ele não conseguir sem a sua ajuda, não abra o framework de eval. Abra o arquivo de design. Adicione proveniência à afirmação principal, apresente o resultado como um delta contra algo em que o usuário já confia, e divida a resposta em pedaços que ele possa aprovar um por vez. Depois meça de novo. O eval vai ficar mais fácil porque o produto ficou honesto.

Fontes

Hamel Husain. “It’s Hard to Eval Is a Product Smell.” Junho de 2026. Os números centrais refletem a experiência do autor, sem estudo formal por trás.

A Victorino ajuda times a projetar produtos de IA que humanos conseguem de fato verificar, para que a confiança vire algo mensurável: contato@victorino.com.br | www.victorino.com.br