Product managers devem escrever evals de AI, não só requisitos

Um documento de requisitos de produto descreve o que um feature deve fazer. Um eval set prova se realmente faz. Para software determinístico, a lacuna entre intenção e verificação é estreita — unit tests, integration tests e critérios de aceitação a fecham. Para produtos de AI, a lacuna é um abismo. O output é probabilístico. Uma mudança de prompt pode melhorar uma dimensão e degradar outra. Um upgrade de modelo pode alterar tom, precisão e taxas de alucinação simultaneamente sem que nenhuma mudança de código dispare um test failure. O único mecanismo que fecha essa lacuna é um eval set estruturado — e a pessoa que entende o que "bom" significa para o usuário é o product manager, não o engenheiro.

O prompt é temporário. O eval é permanente. Prompts são reescritos, modelos são trocados, pipelines de retrieval são reestruturados. O eval set sobrevive a todas essas mudanças porque codifica o que o produto deve fazer, não como faz. Um PM que escreve um parágrafo em um spec e nunca vê a rubric de scoring entregou a decisão de produto mais consequente — a definição de qualidade — a quem editou por último um arquivo YAML no pipeline de avaliação.

A qualidade de produto em AI não pode depender de percepções

A qualidade de produto tradicional tem sinais observáveis: o botão funciona, a página carrega em menos de 200ms, os dados salvam corretamente. A qualidade de produto em AI é invisível até ser medida. Um resumo gerado por AI pode omitir um detalhe crítico. Uma recomendação pode ser plausível mas incorreta. Uma decisão de routing pode escalar para um humano quando o sistema poderia resolver — ou pior, resolver quando a escalação era necessária.

Times que lançam features de AI sem evals estruturados dependem do que o campo chama "vibe checks": um humano lê um punhado de outputs, decide que parecem bons, e aprova a mudança. Isso funciona quando o produto tem dez usuários. Colapsa em escala porque percepções não capturam regressões, não se generalizam para o long tail de inputs, e não produzem evidência para decisões de rollback.

A consequência operacional: um upgrade de modelo é lançado, o tom se degrada em 15% das respostas de suporte, e ninguém percebe até o NPS cair três semanas depois. A essa altura, o dano está feito, o modelo anterior está deprecado, e o time não tem um regression set para prevenir que a falha recorra. Um eval estruturado teria detectado a degradação antes do deploy avaliando tom como uma dimensão independente contra um dataset de baseline.

Requisitos se tornam exemplos em produtos de AI

Um requisito tradicional diz: "O resumo deve capturar todos os action items da reunião." Para software determinístico, isso se traduz diretamente em critérios de aceitação. Para software de AI, não se traduz em nada acionável — porque "capturar todos os action items" não tem definição computável até que alguém forneça exemplos de reuniões, os action items que contêm, e os critérios para avaliar completude.

Evals de produto de AI são requisitos expressos como exemplos avaliados:

• Input: uma transcrição de uma ligação de suporte de 30 minutos.
• Comportamento esperado: o resumo inclui o problema declarado pelo cliente, a resolução oferecida e quaisquer compromissos de acompanhamento.
• Critérios de scoring: accuracy (declarou o problema corretamente?), completude (incluiu todos os compromissos?), tom (lê-se como profissional e neutro?), e comportamento de falha (o que faz quando a transcrição é ambígua?).

Cada critério se torna um scorer separado. Agrupar "qualidade" em uma dimensão torna regressões invisíveis — uma melhoria de tom pode mascarar uma degradação de accuracy quando são mediados em um único número. O PM define as dimensões. Engenharia automatiza a medição.

O workflow prático: um PM revisa cinco cenários reais de usuários da semana passada, anota como "bom" se parece para cada um, define os critérios de scoring em linguagem simples, e entrega à engenharia como o contrato de eval. Isso não é trabalho extra em cima dos requisitos — é o requisito, expresso na única forma contra a qual o sistema de AI pode ser avaliado.

PMs são donos da definição de bom

A rubric de scoring é o verdadeiro product spec para um feature de AI. Codifica o que importa, quanto importa, e onde estão os limites entre aceitável e inaceitável. O PM é a única pessoa no time com o contexto cross-funcional para tomar essas decisões: conhece a linguagem do usuário, as restrições de negócio, os edge cases que geram tickets de suporte, e os modos de falha que erodem confiança.

Como a ownership do PM sobre evals de AI se manifesta na prática:

• Escrever os critérios da rubric — não o código de automação, mas a definição em linguagem simples do que significa um score de 5 versus um score de 1 para cada dimensão.
• Fornecer anchor examples — inputs reais de produção pareados com outputs que o PM avaliou como excelentes, aceitáveis e falhos. Esses anchors calibram o judge automatizado.
• Revisar o agreement do judge — comparação semanal de scores automatizados contra uma amostra de outputs avaliados pelo PM. Se o judge e o PM discordam em mais de 15% dos casos, a rubric é vaga demais ou o judge derivou.
• Manter o eval como contrato vivo — quando a direção do produto muda, o eval muda primeiro. Novos modos de falha de logs de produção se tornam novos regression examples.

Engenharia é dona da infraestrutura: os CI gates que bloqueiam deploys quando scores caem, o pipeline de sampling em produção, a orquestração de LLM-as-judge, e os dashboards de observabilidade. Mas engenharia não pode definir o que "bom" significa para o usuário. Isso é trabalho de produto.

Engenharia é dona da automação, instrumentação e gates de deploy

A divisão de responsabilidade é limpa. O PM define o que medir. Engenharia constrói o sistema que mede continuamente, em escala, e com precisão suficiente para bloquear regressões antes de chegarem à produção.

O stack de engenharia para evals de produto de AI inclui:

• Checks determinísticos como primeira camada — validação de JSON schema, limites de comprimento, detecção de recusa, filtros de conteúdo proibido. São binários, rápidos, e capturam falhas nas quais nenhum LLM judge deveria gastar inferência.
• LLM-as-judge para qualidade matizada — um avaliador automatizado que pontua cada output contra a rubric do PM. O judge roda em cada CI build contra um dataset versionado e em uma amostra de tráfego de produção para detectar drift.
• Human review como calibração — uma amostra semanal de 50 production traces pontuados pelo PM ou um domain expert, comparados contra o judge automatizado. Cohen's Kappa acima de 0.6 indica alinhamento aceitável; abaixo desse limiar, a rubric precisa de revisão.
• CI gating — um deploy falha se qualquer dimensão da rubric cai mais de 2 pontos do baseline trailing no regression set. O limiar é per-route e per-rubric, então uma mudança de prompt no agente de suporte não dispara uma re-avaliação completa do assistente de vendas.
• Observabilidade em produção — as mesmas rubrics que rodam no CI rodam sobre tráfego live amostrado para detectar falhas que o dataset offline não representa. Alertar quando uma dimensão sustenta uma queda sobre uma janela configurável.

O contrato de eval — a tupla de (judge_model_id, rubric_version, prompt_template_hash) — é fixado e versionado. Mudar qualquer elemento é um ato deliberado que requer review do PM, não um efeito colateral de um upgrade de modelo do vendor.

O que torna útil um eval de produto de AI?

A diferença entre um eval útil e um exercício de checkbox é especificidade. Evals úteis capturam regressões reais. Evals inúteis aprovam tudo e embalam o time em falsa confiança.

Como PMs devem criar eval examples a partir de uso real?

Começar de falhas em produção, não de cenários abstratos. Extrair os últimos 30 dias de reclamações de usuários, escalações de suporte e feedback negativo. Cada reclamação recorrente se torna um critério: "respostas soam robóticas" se traduz em um eval de tom; "datas erradas no resumo" se torna um eval de accuracy factual; "não respondeu a segunda pergunta do cliente" se torna um eval de completude. Cinco exemplos de produção bem escolhidos com outputs avaliados pelo PM valem mais que cinquenta test cases sintéticos que nunca representam a distribuição real.

Quantas dimensões uma rubric de eval deve ter?

Pontuar uma dimensão por avaliador. Três a cinco critérios ortogonais cobrem a maioria dos features de AI: accuracy, completude, tom, segurança e task completion. A tentação é adicionar mais — resista. Cada dimensão adicional requer seus próprios anchor examples, seu próprio ciclo de calibração e seu próprio baseline tracking. Começar com três dimensões onde o time tem exemplos fortes avaliados pelo PM, depois adicionar dimensões apenas quando uma falha em produção revelar um gap que os critérios existentes não detectam.

Quando evals devem bloquear um deployment?

Gatear por regressão, não por score absoluto. Uma mudança de prompt que baixa faithfulness em 3 pontos no regression set — mesmo que o score absoluto ainda esteja acima de 0.7 — representa uma degradação que o time deve investigar antes de shippear. Limiares absolutos são úteis como pisos (não deployar se accuracy cai abaixo de 0.6), mas a regressão relativa do baseline trailing detecta drift lento que pisos absolutos não captam. A lógica de gating vive no CI e usa os limiares definidos pelo PM por dimensão.

Um ponto de vista oposto

Um argumento comum sustenta que evals são testing — e testing pertence à engenharia. PMs definem o que construir; engenheiros definem como verificar que funciona. Essa separação de responsabilidades serviu bem ao software por décadas, e estender a responsabilidade do PM para infraestrutura de avaliação arrisca confusão de papéis, iteração mais lenta, e qualidade de rubric que sofre por ownership não técnico.

Esse argumento se aplica a software determinístico onde o spec descreve sem ambiguidade o comportamento esperado. Se quebra para produtos de AI porque o spec é o eval. O spec tradicional diz "o botão salva o registro"; não há ambiguidade na verificação. O spec de AI diz "o resumo captura todos os action items" — e sem exemplos avaliados mostrando o que "captura" significa no boundary, nenhuma quantidade de infraestrutura de engenharia pode determinar se o sistema funciona. O PM não está testando o sistema. O PM está definindo o contrato de qualidade do sistema na única forma que produz verdade computável. Engenharia automatiza esse contrato. O playbook operacional para agentes de AI em produção depende desse contrato existir antes do deployment, não após a primeira reclamação de usuário.

O que vale a pena lembrar

• Para produtos de AI, o eval set é o requisito de produto que não se degrada — continua rodando após o lançamento e detecta regressões que specs em prosa não conseguem.
• PMs são donos da rubric: a definição em linguagem simples do que significa um score de 5 versus 1 para cada dimensão de qualidade.
• Pontuar uma dimensão por avaliador. Agrupar qualidade em um único número esconde se uma regressão vem de accuracy, tom ou completude.
• Começar de falhas em produção, não cenários sintéticos. Cinco exemplos reais com outputs avaliados pelo PM superam cinquenta test cases abstratos.
• Fixar o contrato de eval — (judge_model_id, rubric_version, prompt_template_hash) — e requerer review do PM para qualquer mudança.
• Gatear deploys por regressão do baseline trailing, não apenas por pisos de score absoluto.

Conclusão

O trabalho de um product manager de AI absorveu uma nova responsabilidade central: definir qualidade em uma forma contra a qual o sistema pode se avaliar. Isso não é uma tarefa de testing delegada ao QA. É o ato de especificar o que o produto deve fazer — expresso não como parágrafos que acumulam poeira em um wiki, mas como exemplos avaliados que rodam em cada build, cada deploy e cada amostra de produção. O PM que nunca abriu a rubric de eval não está liderando o produto. Está torcendo para que o produto funcione. E em AI, a torcida é o mecanismo pelo qual regressões chegam aos usuários sem serem detectadas.