Ideia principal

Uma funcionalidade determinística se testa por comparação com um resultado esperado: o resultado está conforme ou não está. Uma resposta produzida por um modelo não oferece essa pegada. Duas formulações corretas não têm o mesmo valor para o usuário, uma resposta falsa pode ser perfeitamente plausível, e a experiência da falha — o que o produto faz quando não sabe — vira parte do produto no mesmo nível que o sucesso.

Avaliar esse tipo de saída trata, portanto, de questões que nenhum conjunto de testes de conformidade cobre: a robustez diante de casos tortos, a coerência com a intenção de produto, a confiança que o usuário pode razoavelmente depositar e a margem de erro que ele está disposto a aceitar no trabalho dele.

É por isso que reduzir essa avaliação a um controle de qualidade clássico a esvazia: a pergunta não é só "a saída está certa?", mas "essa saída é aceitável, aqui, para este uso?" — uma pergunta de produto, não de verificação.

Por que isso importa

Isso diz a quem cabe a avaliação: ela não pode ser inteiramente delegada a uma função de controle no fim da cadeia, já que exige decidir sobre a intenção e sobre o que o usuário tolera.

E torna testável o que muitos times desistem de medir: confiança e aceitabilidade se trabalham com casos de negócio, cenários de falha e critérios escritos, não com uma impressão geral de qualidade.

Nuances e limites

A aceitabilidade não isenta da conformidade: nas regras verificáveis — um cálculo, um direito de acesso, um formato —, a exigência continua binária e o argumento probabilístico não deve servir de desculpa.

E o limiar de aceitabilidade não pertence ao time que produz: ele se constata junto a quem usa, e varia conforme a área, o que está em jogo e a reversibilidade daquilo que a saída dispara.

Questões em aberto

• Como fixar por escrito um limiar de aceitabilidade, quando o que está em jogo é a confiança de um usuário e não uma taxa de erro observável?