Como avaliar IA com julgamento humano sem virar opinião

Avaliação humana de inteligência artificial não deve ser uma votação sobre respostas bonitas. Ela funciona melhor quando a equipe escolhe amostras pelo risco da decisão, define critérios observáveis antes da revisão e separa preferência de estilo de falha operacional.

O julgamento humano em produtos com IA é útil quando deixa claro o que está sendo avaliado: qualidade da resposta, preferência de estilo ou necessidade de outra verificação.

Quando a avaliação humana vira opinião organizada demais

Uma equipe coloca uma funcionalidade com IA em teste interno. A resposta parece educada, bem escrita e convincente. Uma pessoa aprova porque “soou certa”. Outra reprova porque achou o tom arriscado. Uma terceira não sabe se o problema está na resposta, na expectativa do usuário ou no próprio formulário de avaliação.

Esse cenário não mostra que avaliação humana é inútil. Mostra que ela foi desenhada como opinião organizada demais.

A avaliação humana de IA precisa separar pelo menos três camadas. A primeira é gosto: tom, estilo, concisão, escolha de palavras. A segunda é adequação ao usuário: a resposta ajuda aquela pessoa naquela tarefa? A terceira é qualidade operacional: a IA cumpriu a tarefa, respeitou restrições, evitou inventar informação e não orientou uma ação inadequada?

Misturar essas camadas em uma única nota cria uma falsa precisão. A planilha fica limpa, mas a decisão continua confusa.

Essa distinção dialoga com uma prática mais ampla de qualidade. O DORA recomenda tratar testes ao longo do desenvolvimento, combinando automação e atividades manuais, como exploração e usabilidade, em vez de empurrar qualidade para uma etapa final. Em produtos com IA, a avaliação humana entra como uma dessas atividades manuais. Ela não substitui testes automatizados, pesquisa com usuários, revisão de segurança ou decisão de produção. Ela ajuda a enxergar casos em que critérios humanos são necessários.

Se a liderança não define o que será julgado, o avaliador tenta adivinhar. E, quando cada avaliador adivinha de um jeito, a divergência parece problema de pessoas. Muitas vezes, é problema de desenho.

Escolha amostras pelo risco da decisão, não pelo que é fácil revisar

Amostragem para avaliação de IA não deve começar pelos exemplos mais disponíveis. Deve começar pelas decisões que a equipe precisa tomar.

Se o produto usa IA para responder dúvidas sobre configuração de um software, por exemplo, uma amostra composta apenas por perguntas simples sobre senha, idioma e notificações pode mostrar fluidez, mas não revela se a funcionalidade aguenta situações ambíguas, restrições técnicas ou instruções incompletas.

Um conjunto útil de amostras costuma combinar quatro tipos de caso:

Casos comuns, que representam usos frequentes e ajudam a verificar consistência na experiência cotidiana.
Casos de alto impacto, nos quais uma resposta errada pode gerar retrabalho, bloqueio operacional ou perda de confiança.
Casos ambíguos, em que a intenção do usuário não está totalmente clara e a IA precisa pedir esclarecimento ou limitar a resposta.
Casos em que a resposta pode parecer convincente mesmo quando está errada, incompleta ou desalinhada com a política do produto.

O ponto não é cobrir tudo. Isso seria uma promessa falsa. O ponto é escolher amostras que informem uma decisão: liberar para mais usuários, ajustar instruções, restringir escopo, ampliar testes ou bloquear um comportamento.

A discussão sobre medição também exige cuidado. Na atualização de fevereiro de 2026, a METR considera seus novos dados um sinal pouco confiável do efeito atual da IA sobre produtividade, apontando dificuldades como seleção de participantes e tarefas e medição de tempo com agentes concorrentes. Essa fonte não autoriza concluir se uma funcionalidade específica gera valor para usuários ou diferenciação comercial. Mas ajuda a lembrar que medir IA exige atenção ao desenho da medição, não apenas ao resultado agregado.

O mesmo vale para avaliação humana. Uma amostra enviesada pode produzir confiança sem qualidade. Se a equipe revisa apenas casos fáceis, o produto parece melhor do que é. Se revisa apenas casos extremos, pode parecer pior do que será no uso cotidiano. A liderança precisa declarar qual decisão aquela amostra sustenta.

Para conectar essa prática à gestão do produto, vale tratar avaliação como parte de um sistema de maturidade, não como uma cerimônia isolada. Esse raciocínio conversa com a ideia de diagnosticar capacidades antes de escalar iniciativas, como discutido em Maturidade em IA: como diagnosticar o ponto de partida da organização.

Transforme gosto em campo separado, não em nota de qualidade

Gosto não é irrelevante. Ele pode influenciar a percepção da resposta. Mas gosto não deve decidir sozinho se uma resposta é correta, segura ou útil.

Uma resposta pode ser seca e ainda assim cumprir a tarefa com precisão. Outra pode ser elegante e falhar por omitir uma restrição. Uma terceira pode ser simpática, mas orientar o usuário a fazer algo fora do escopo do produto.

Por isso, o formulário de avaliação deve separar dimensões. Em vez de perguntar apenas “a resposta foi boa?”, é melhor perguntar:

A resposta cumpriu a intenção principal do usuário?
A resposta inventou informação ou afirmou algo sem base disponível?
A resposta omitiu uma restrição relevante?
A resposta orientou uma ação inadequada para aquele contexto?
O tom foi adequado para o tipo de interação?
A preferência de estilo afetou a utilidade ou foi apenas uma preferência do avaliador?

A última pergunta é mais poderosa do que parece. Ela permite registrar incômodo de estilo sem transformá-lo automaticamente em falha de qualidade.

Essa separação também reduz ruído político. Quando pessoas com mais senioridade influenciam a avaliação por gosto pessoal, o desenho do formulário precisa impedir que preferência vire critério implícito. Se o critério não está explícito, “eu não gostei” pode virar “isso não tem qualidade”. A consequência é perigosa: o produto passa a refletir preferências internas, não critérios de uso, risco e resultado.

Critérios de qualidade em IA precisam ter consequência operacional. Se o tom está ruim, a equipe pode ajustar instruções, exemplos ou diretrizes de resposta. Se a resposta inventa informação, o problema é de outra natureza. Pode exigir limitar fontes, alterar recuperação de contexto, mudar verificadores ou impedir que a IA responda quando não houver evidência suficiente.

Erro factual, omissão de restrição, tom inadequado e preferência de estilo não devem receber o mesmo rótulo.

Use critérios observáveis antes de pedir uma nota geral

A nota geral deve ser síntese, não evidência única.

Quando a avaliação começa por uma nota aberta, o avaliador comprime várias percepções em um número ou escala. O problema aparece depois: uma nota baixa veio de erro factual, de tom inadequado, de falta de completude, de medo do avaliador ou de preferência pessoal?

Critérios observáveis ajudam a reduzir essa ambiguidade. Eles não eliminam julgamento humano, mas tornam o julgamento discutível.

Um bom critério não precisa ser perfeito. Precisa ser aplicável. “Resposta confiável” é vago. “Não afirma uma configuração que não aparece na documentação disponível para aquele produto” é mais observável. “Boa experiência” é amplo. “Explica a próxima ação possível sem prometer que o problema foi resolvido” é mais útil.

Exemplo fictício: imagine um produto de suporte interno para equipes de operações de uma empresa de varejo. A IA responde perguntas sobre como abrir chamados, consultar status de pedidos e orientar procedimentos internos simples. A equipe decide avaliar respostas humanas antes de ampliar o uso.

Uma pergunta da amostra diz: “O pedido aparece como entregue, mas a loja diz que não recebeu. O que eu faço?”

Uma resposta elegante poderia dizer: “Não se preocupe, o pedido será regularizado. Abra uma solicitação e aguarde a confirmação.” Ela soa calma, mas pode falhar se prometer regularização sem evidência ou se omitir a necessidade de conferir dados do pedido.

Uma resposta menos elegante poderia dizer: “Verifique o status no sistema de pedidos, confirme o código da loja e abra um chamado com os dados de entrega. Se houver divergência, não confirme regularização antes da análise.” Ela é menos polida. Mas, dependendo da política do produto, pode ser operacionalmente melhor.

Nesse exemplo fictício, a avaliação deveria separar:

Correção: a resposta segue o procedimento disponível?
Completude: inclui as informações mínimas para a próxima ação?
Segurança operacional: evita prometer um resultado que ainda não foi verificado?
Utilidade: ajuda o usuário a agir sem criar dependência desnecessária?
Tom: é claro e adequado ao contexto?

Os efeitos dessa avaliação seriam hipóteses a medir, não resultados presumidos. A equipe poderia levantar a hipótese de que critérios separados reduzem divergências entre avaliadores ou tornam correções mais acionáveis. Mas precisaria acompanhar isso no próprio processo.

Esse tipo de desenho também se conecta a uma estratégia de inteligência artificial conectada ao negócio: a avaliação não existe para admirar a tecnologia, mas para decidir onde ela pode operar com responsabilidade.

Compare avaliadores para encontrar critérios ruins

Divergência entre avaliadores não é só um problema a corrigir. Pode ser uma fonte de aprendizado.

Se duas pessoas competentes discordam sobre o mesmo caso, há algumas explicações possíveis. Uma delas é que uma pessoa errou. Mas essa não deve ser a primeira hipótese. Talvez o critério esteja vago. Talvez a amostra seja ambígua. Talvez o produto ainda não tenha uma política clara para aquele tipo de situação.

A liderança deve tratar desacordo como sinal de calibração.

Calibrar não significa forçar todos a pensar igual. Significa alinhar o que conta como evidência. Em uma rodada de calibração, a equipe pode escolher alguns casos, pedir avaliações independentes e depois discutir apenas os pontos de divergência. A pergunta central não é “quem tem razão?”. É “qual regra permitiria decidir melhor da próxima vez?”.

Se a divergência aparece em preferência de tom, talvez baste separar esse campo. Se aparece em correção, talvez falte referência confiável. Se aparece em segurança, talvez a política de risco esteja incompleta. Se aparece em utilidade, talvez a equipe precise entender melhor a tarefa do usuário.

Há um limite importante: avaliação humana não garante qualidade de IA. Ela reduz cegueira sobre casos relevantes, desde que amostras, critérios e calibração sejam bem desenhados. Sem isso, ela apenas registra opiniões em escala.

Essa é a diferença prática entre registrar revisão humana e desenhar avaliação humana. O valor está em saber o que esses humanos julgam, com quais critérios, sobre quais casos e com qual consequência.

Separe resultado final da trajetória aparente da IA

Em produtos com IA, é comum a resposta parecer convincente porque a trajetória parece organizada. A IA explica o que fez, descreve passos e encerra com segurança. Mas a explicação não prova que o resultado aconteceu.

A Anthropic distingue a trajetória de execução de um agente do resultado efetivo no ambiente. Uma mensagem dizendo que a tarefa terminou não basta para comprovar o resultado. A avaliação usa entradas, critérios de sucesso e verificadores, e pode exigir várias tentativas.

Mesmo quando o produto não é um agente que executa ações, a distinção continua útil. O avaliador humano não deve aprovar apenas a narrativa da IA. Deve procurar evidência do resultado esperado.

No exemplo fictício do suporte interno, a IA pode afirmar: “O chamado foi classificado corretamente”. Se o produto apenas sugere uma classificação, essa frase já é problemática. Se o produto de fato registra algo em outro sistema, a avaliação precisa conferir o estado final, não apenas a mensagem.

Perguntas úteis para essa etapa:

A IA apenas declarou que concluiu algo ou há evidência verificável?
O estado do sistema corresponde ao que a resposta afirma?
A ação sugerida respeita as permissões e limites definidos para o produto?
O usuário recebeu uma orientação compatível com o que realmente pode fazer?

Essa separação evita um erro comum: confundir confiança linguística com qualidade operacional. Modelos de IA podem produzir explicações plausíveis. O produto precisa de critérios que olhem além da plausibilidade.

Em lançamentos de software, essa diferença entre disponibilizar e ativar também é relevante. O capítulo de Google SRE sobre lançamentos graduais trata da avaliação de uma mudança em uma parcela do tráfego antes de ampliar a exposição e distingue disponibilizar código de ativar funcionalidades, inclusive com configurações que separam essas decisões. Para funcionalidades com IA, avaliação humana pode informar essa ampliação, mas não deve ser confundida com aprovação automática para produção.

Decida o que acontece depois da avaliação

Uma avaliação humana que termina em planilha acumulada não melhora o produto. Ela precisa acionar decisões.

Antes de revisar casos, a equipe deve definir consequências possíveis. Por exemplo:

Liberar o comportamento quando os critérios críticos foram atendidos e as divergências são explicáveis.
Ampliar a amostra quando há sinal promissor, mas ainda insuficiente para decidir.
Ajustar instruções quando falhas se concentram em formato, tom, sequência de resposta ou restrições explícitas.
Revisar dados ou fontes quando a IA erra por falta de referência, referência conflitante ou contexto incompleto.
Restringir uso quando a funcionalidade funciona em casos simples, mas falha em situações ambíguas ou de maior impacto.
Bloquear um caso quando a falha cria risco operacional que a equipe ainda não sabe controlar.

A decisão deve ser proporcional ao tipo de falha. Uma preferência de estilo não deve bloquear o produto sozinha. Uma resposta agradável que inventa informação pode bloquear um fluxo. Uma divergência recorrente entre avaliadores pode indicar que o critério precisa ser reescrito antes de qualquer conclusão.

Os critérios abaixo ajudam a decidir o que fazer depois da avaliação.

Critérios de decisão para separar gosto e qualidade

Amostra: deve estar ligada a um uso, risco ou comportamento que a equipe precisa aceitar, reduzir ou bloquear. Se o caso foi escolhido apenas porque era fácil de revisar, ele deve entrar como exploração, não como evidência principal.
Dimensão julgada: cada item deve indicar se o julgamento é sobre correção, completude, segurança, utilidade, tom ou preferência.
Regra para distinguir estilo de falha: uma resposta menos elegante pode ser aceitável se cumpre a tarefa com segurança. Uma resposta agradável pode falhar se omite restrições, inventa fatos ou orienta uma ação inadequada.
Aplicação por mais de uma pessoa: se avaliadores competentes chegam a decisões opostas com frequência, o problema pode estar no critério, na política do produto ou na ambiguidade do caso.
Conferência do resultado: quando a IA afirma que concluiu algo, o avaliador deve procurar evidência do resultado esperado, não só a explicação da IA.
Consequência por tipo de falha: sem consequência, avaliação vira arquivo.

A decisão prática é montar a avaliação humana a partir de amostras representativas e critérios explícitos, para que a equipe consiga dizer: isto falhou por qualidade, isto é preferência de estilo e isto exige outro tipo de verificação.

Antes de ampliar uma funcionalidade com IA, a equipe precisa separar respostas que falham por qualidade, respostas que incomodam por estilo e casos que exigem outra verificação.

Se quiser discutir essa decisão no contexto da sua empresa, converse com a dooop.

Leituras para continuar

Fontes

PRÓXIMA DECISÃO

Conversar sobre a aplicação na empresa

Conversa sobre o contexto da empresa de software

Conteúdo de dooop. O cadastro permite relacionar esta pauta à jornada do leitor e acompanhar o interesse pelo tema.