Como avaliar uma aplicação de IA com critérios claros

Uma avaliação de aplicações de inteligência artificial começa quando você define quais situações representam o trabalho real, o risco aceitável e a decisão que a aplicação precisa apoiar. A nota média do modelo pode ajudar depois, mas não substitui uma decisão avaliativa clara: qual falha é tolerável, qual exige mitigação e qual bloqueia o avanço. Antes de comparar prompts, modelos, agentes ou versões, a equipe precisa dizer o que conta como resultado aceitável, falha recuperável e falha bloqueante em cada tipo de uso.

O que exatamente será avaliado na aplicação de IA

A primeira decisão é delimitar a unidade de avaliação. Parece simples, mas é aqui que muita discussão sobre qualidade em aplicações de IA fica confusa.

Você pode estar avaliando uma resposta textual, uma recomendação, uma classificação, uma ação executada em outro sistema ou um fluxo completo que combina interface, modelo, regras de negócio e revisão humana. Cada uma dessas unidades pede critérios diferentes.

Avaliar o modelo não é o mesmo que avaliar a experiência do usuário. Avaliar a experiência não é o mesmo que avaliar o resultado operacional. Uma aplicação pode gerar uma resposta clara e ainda assim tomar uma decisão inadequada. Também pode usar um modelo competente dentro de um fluxo mal desenhado, com contexto insuficiente, confirmação ausente ou política ambígua.

Por isso, a pergunta inicial deve ser concreta: o que precisa funcionar para que esta aplicação seja considerada segura o suficiente para avançar?

Em uma funcionalidade de atendimento, por exemplo, a unidade de avaliação pode ser o resumo produzido pela IA. Em uma aplicação que sugere ações, a unidade pode ser a recomendação e a justificativa. Em um agente de IA, isto é, um sistema que planeja e executa passos em ferramentas ou ambientes, a unidade pode ser o fluxo inteiro: entrada recebida, passos relevantes, resultado no ambiente e verificação final.

Essa separação evita uma armadilha comum: transformar tudo em uma nota única. A nota pode ser útil para acompanhar tendência, mas não deve esconder a natureza da falha. Uma resposta incompleta, uma resposta inventada e uma ação indevida não pertencem ao mesmo tipo de problema.

Para uma visão mais ampla sobre qualidade de software com IA, vale conectar esta avaliação ao guia de referência do cluster: Qualidade de software com IA: testes, avaliação e responsabilidade. Aqui, o foco é mais estreito: criar uma avaliação aplicável para uma funcionalidade ou aplicação específica.

Como escolher casos representativos sem tentar cobrir tudo

Uma boa avaliação não tenta antecipar todos os usos possíveis. Ela escolhe deliberadamente um conjunto pequeno de casos que representa frequência, impacto, risco, ambiguidade e exceções relevantes.

O objetivo não é provar que a aplicação nunca falhará. É reunir evidências para decidir liberação, mitigação, revisão humana ou bloqueio.

Um conjunto inicial de casos de avaliação de IA pode combinar:

Casos comuns, que representam o uso esperado e frequente da aplicação.
Casos difíceis, nos quais a entrada é incompleta, ambígua ou contraditória.
Casos de alto impacto, nos quais uma resposta errada gera retrabalho relevante, frustração do usuário ou exposição operacional.
Casos de recusa, escalonamento ou confirmação, nos quais a aplicação não deve responder sozinha.
Exceções conhecidas, que não aparecem sempre, mas mudam a decisão quando acontecem.

Exemplo fictício: uma aplicação de IA ajuda um time de atendimento a resumir solicitações de reembolso. Um caso comum avalia se a IA identifica valor, data e motivo do pedido. Um caso ambíguo avalia se ela pede confirmação quando o comprovante está ilegível. Um caso bloqueante avalia se ela evita aprovar automaticamente um reembolso fora da política.

O critério não é “resumo bom”. O critério é: contém os três campos obrigatórios, sinaliza incerteza quando falta evidência e não executa aprovação sem autorização.

Esse exemplo é fictício, mas a lógica é aplicável: cada caso precisa existir por um motivo. Se ninguém consegue explicar por que um caso entrou na avaliação, provavelmente ele está ali por hábito, ansiedade ou gosto pessoal.

Um bom teste para escolher casos é perguntar:

Este caso representa uma situação real de uso?
Ele é comum, crítico, ambíguo, raro com alto impacto ou uma exceção conhecida?
Há alguma decisão de produto, engenharia ou operação associada ao resultado?
A falha neste caso mudaria a liberação da funcionalidade?

Se a resposta for “não” para tudo, talvez o caso não deva estar na primeira versão da avaliação.

Como escrever critérios de sucesso que uma equipe consiga aplicar

Critérios de sucesso em IA precisam ser observáveis. “Boa resposta”, “parece correto” e “tom adequado” podem ser percepções úteis em uma conversa, mas são fracos como critérios de avaliação.

Um critério aplicável diz o que precisa estar presente, o que não pode acontecer e como alguém ou algum verificador identificará o resultado aceitável.

No exemplo fictício do reembolso, os critérios poderiam ser escritos assim:

Completude: a resposta identifica valor, data e motivo quando esses dados estão disponíveis na solicitação.
Correção: a resposta não inventa dados ausentes nem altera valores informados pelo usuário.
Aderência à política: a aplicação não aprova automaticamente pedidos fora das condições definidas.
Clareza: a resposta separa informação extraída, incerteza e próxima ação sugerida.
Confirmação humana: quando o comprovante está ilegível, a aplicação pede confirmação em vez de concluir o caso.
Ausência de ação indevida: a aplicação não executa uma aprovação sem autorização explícita.

Esses critérios permitem que produto, engenharia, qualidade e operação discutam a mesma coisa. A conversa deixa de ser “eu gostei” ou “eu não confio” e passa a ser “neste caso, o critério de confirmação falhou”.

A recomendação do DORA sobre automação de testes ajuda a situar essa prática dentro do desenvolvimento: testes devem acompanhar o trabalho, combinando automação e atividades manuais, como exploração e usabilidade, e as suítes precisam ser mantidas e revisadas. Em aplicações com IA, isso significa que a avaliação não deve ser tratada como uma etapa isolada depois que o produto já está pronto.

Automação pode repetir verificações. Julgamento humano continua necessário quando o critério envolve ambiguidade, sensibilidade de contexto ou política ainda mal definida.

Como os critérios alcançam trajetória, resposta e resultado

Em aplicações com IA, principalmente em agentes, a equipe precisa separar três coisas: a trajetória, a resposta final e o resultado efetivo.

A trajetória é o caminho percorrido: quais informações foram usadas, quais ferramentas foram chamadas, quais decisões intermediárias ocorreram. A resposta final é o que a IA comunica ao usuário ou ao sistema. O resultado é o que de fato mudou no ambiente.

Essa distinção importa porque uma mensagem dizendo que a tarefa terminou não prova que a tarefa foi concluída.

A Anthropic, em um texto sobre avaliações de agentes, distingue a trajetória de execução do agente do resultado efetivo no ambiente. Também descreve avaliações com entradas, critérios de sucesso e verificadores, podendo exigir várias tentativas.

Em uma aplicação que apenas resume texto, talvez a trajetória seja menos relevante. Já em um agente que consulta dados, preenche campos ou aciona ferramentas, ela pode revelar erros que a resposta final esconde.

Imagine, ainda no exemplo fictício do atendimento, que a IA responda: “Solicitação registrada com sucesso”. Essa frase não comprova que o registro foi criado no sistema correto, com os campos certos e sem aprovar o reembolso indevidamente. A avaliação precisa verificar o estado final, não apenas a mensagem.

Um desenho simples de avaliação para esse tipo de caso inclui:

Entrada: solicitação original, anexos disponíveis e contexto permitido.
Comportamento relevante: dados consultados, confirmação solicitada, ação executada ou evitada.
Resultado no ambiente: registro criado, campos preenchidos, status mantido ou alterado.
Verificador: regra, inspeção humana ou checagem automatizada que confirma se o resultado atende ao critério.

Essa é uma diferença prática entre testar uma resposta e avaliar uma funcionalidade com IA. Quando há ação, o critério precisa alcançar a consequência da ação.

Como pontuar a avaliação sem esconder risco

Pontuar ajuda a comparar versões, mas pontuar mal cria uma sensação falsa de controle. O problema não é usar nota. O problema é deixar a média esconder casos críticos.

Uma matriz simples pode funcionar melhor do que uma escala sofisticada:

Aprovado: atende aos critérios do caso sem ressalvas relevantes.
Aprovado com ressalva: atende ao objetivo principal, mas exige ajuste de clareza, formato ou experiência.
Falha recuperável: erra de modo corrigível por revisão humana, repetição, confirmação ou melhoria de instrução.
Falha bloqueante: gera risco relevante ao usuário, ao negócio, à operação ou à conformidade interna definida pela organização.

O ponto central é separar severidade de frequência. Uma falha rara pode impedir a produção se for bloqueante. Da mesma forma, várias falhas pequenas podem indicar baixa qualidade percebida, mesmo que nenhuma delas seja isoladamente grave.

Na prática, cada caso da avaliação deve carregar uma decisão associada. Se o caso comum falhar, talvez a equipe corrija instrução, contexto ou interface. Se o caso ambíguo falhar, talvez exija confirmação humana. Se o caso bloqueante falhar, talvez a funcionalidade não deva ter autonomia naquele ponto.

Essa abordagem também ajuda a evitar comparações apressadas entre alternativas. Um modelo pode ter desempenho melhor em fluência e pior em recusa. Outro pode ser menos elegante, mas mais conservador em casos de risco. Sem critérios por caso, a equipe tende a escolher pela demonstração mais convincente.

A avaliação de aplicações de IA precisa tornar a decisão auditável, não premiar a resposta mais sedutora.

Essa avaliação se soma às outras verificações de qualidade. Testar código gerado por IA, revisar dependências ou calibrar avaliações com especialistas são problemas próprios. Para a decisão específica de aceite de produto, a pergunta é outra: quais casos impedem avanço se falharem?

Como usar a avaliação antes de ampliar exposição

A avaliação offline, feita com casos controlados, não encerra a decisão. Ela cria evidência para decidir se a funcionalidade pode ser ativada para um grupo limitado, observada e depois ampliada.

Aqui vale uma distinção técnica e gerencial: disponibilizar código não é o mesmo que ativar uma funcionalidade. O capítulo do Google SRE sobre lançamentos graduais trata da avaliação de mudanças em uma parcela do tráfego antes de ampliar a exposição e discute o uso de configurações para separar disponibilização de código e ativação de funcionalidades.

Para aplicações com IA, essa separação é útil porque reduz a confusão entre entrega técnica e exposição operacional. A equipe pode entregar a base técnica sem liberar autonomia ampla. Pode ativar para um grupo limitado. Pode manter revisão humana em certos casos. Pode interromper a ampliação quando um caso bloqueante aparece.

A avaliação, nesse ponto, deixa de ser um documento e vira uma régua de liberação.

Antes de ampliar exposição, a equipe deveria conseguir responder:

Quais casos foram avaliados e por que foram escolhidos?
Quais critérios definiram sucesso, ressalva, falha recuperável e falha bloqueante?
Quais falhas foram aceitas conscientemente e com qual mitigação?
Quais tipos de caso ainda exigem revisão humana?
O que será monitorado quando a funcionalidade for ativada para mais usuários?
Qual resultado interrompe a ampliação?

Essas perguntas não eliminam incerteza. Elas tornam a incerteza administrável.

Há limites claros. A avaliação proposta aqui não prova que a aplicação será correta em todos os usos futuros. Casos representativos precisam ser revisados quando o produto, os usuários, as políticas ou o modelo mudam. Automação ajuda a repetir verificações, mas não substitui julgamento humano em critérios ambíguos. E uma nota agregada pode esconder falhas graves.

Também vale separar este tema de medição ampla de produtividade. A METR, em atualização de fevereiro de 2026, considera seus novos dados um sinal pouco confiável do efeito atual da IA sobre produtividade e aponta dificuldades de medir tempo com agentes concorrentes. Para este artigo, a lição é mais limitada: explicitar a unidade medida antes de interpretar qualquer resultado.

Roteiro de decisão para casos e critérios

Antes de comparar modelos, prompts, agentes ou versões da aplicação, registre as decisões abaixo.

O caso representa uma situação real de uso? Descreva quem faz a solicitação, qual é o objetivo, quais dados estão disponíveis e qual decisão depende da resposta.
O caso tem um motivo claro para estar na avaliação? Classifique como comum, crítico, ambíguo, raro com alto impacto, exceção conhecida ou situação em que a IA deve recusar, escalar ou pedir confirmação.
O sucesso é verificável? Escreva o que precisa estar correto, o que não pode acontecer e como alguém ou algum verificador identificará o resultado aceitável.
A falha tem severidade definida? Separe falhas cosméticas, falhas de utilidade, falhas que exigem retrabalho e falhas bloqueantes por risco ao usuário, ao negócio ou às regras internas da organização.
O critério evita gosto pessoal? Troque “resposta boa” por sinais observáveis, como “inclui as três informações obrigatórias”, “não inventa dados ausentes” ou “pede confirmação antes de executar a ação”.
O caso permite comparação entre versões? Mantenha entrada, contexto, expectativa e critério estáveis o suficiente para comparar prompt, modelo, ferramenta ou versão da aplicação.
Há uma decisão associada ao resultado? Defina antes da execução o que acontece se o caso falhar: corrigir instrução, ajustar produto, limitar autonomia, exigir revisão humana ou impedir ampliação de uso.

Construir uma avaliação de aplicações de IA é escolher quais casos representam o uso real, quais critérios tornam o sucesso verificável e quais falhas impedem a ampliação. A partir daí, a equipe não decide pela média mais confortável. Decide pelo erro que ainda consegue administrar e pelo erro que exige conter a aplicaçã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.