Critérios de aceite para funcionalidades de IA

Critérios de aceite para inteligência artificial são a forma de decidir, antes da liberação, o que uma funcionalidade precisa demonstrar para ser considerada pronta. Eles transformam três coisas em verificação: o que conta como sucesso, o que conta como falha e quais limites não podem ser ultrapassados mesmo quando a experiência parece boa.

Sem isso, o aceite da funcionalidade vira discussão de impressões no produto: a resposta parece útil, o fluxo parece aceitável, a demonstração parece convincente.

O aceite de IA começa pela decisão que a funcionalidade pode tomar

Uma funcionalidade de IA raramente entrega apenas “uma resposta”. Ela sugere, classifica, prioriza, redige, recomenda, preenche campos, aciona fluxos ou prepara uma decisão para alguém. O critério de aceite precisa começar por essa ação concreta.

A pergunta inicial não é “a IA é boa?”. É: que decisão, sugestão ou ação esta funcionalidade está autorizada a produzir dentro do produto?

Essa formulação tira a avaliação do abstrato. A equipe deixa de discutir inteligência em geral e passa a verificar o comportamento específico que afeta o usuário no fluxo. Um texto bem escrito pode estar errado. Uma classificação plausível pode mover um item para o lugar indevido. Uma recomendação útil na maioria dos casos pode ser inaceitável se passar do limite de autonomia definido.

Por isso, o aceite de funcionalidades com IA deve descrever a unidade de responsabilidade. Por exemplo:

A IA apenas sugere uma resposta?
Ela preenche campos que uma pessoa revisa?
Ela executa uma ação no sistema?
Ela pode recusar uma solicitação?
Ela deve pedir mais informação quando houver incerteza?

Essa definição também conecta qualidade de software com decisão de negócio. Se a organização ainda está estruturando sua adoção, vale relacionar esse nível de aceite com escolhas mais amplas de prioridade, risco e capacidade, como em uma estratégia de inteligência artificial conectada ao negócio ou em um roadmap de IA. O critério de aceite não substitui essas decisões. Ele impede que elas desapareçam na implementação.

Descreva sucesso como resultado observável, não como resposta convincente

O sucesso de uma funcionalidade de IA precisa ser verificável no fluxo em que ela opera. “Responder bem”, “ser útil” ou “parecer correta” são avaliações iniciais, não critérios de aceite suficientes.

Um bom critério descreve três componentes:

Entrada: quais dados, solicitações ou contextos estão dentro do escopo.
Comportamento esperado: o que a funcionalidade deve produzir ou fazer.
Evidência mínima: como a equipe comprova que o resultado foi alcançado.

A Anthropic, ao discutir avaliações de agentes, distingue a trajetória de execução do agente do resultado efetivo no ambiente. Uma mensagem dizendo que a tarefa terminou não basta para comprovar o resultado, e a avaliação usa entradas, critérios de sucesso e verificadores Anthropic. Mesmo quando a funcionalidade não é um agente autônomo, a separação é útil: não aceite a narrativa da IA como prova do resultado.

Compare dois critérios:

Fraco: a IA deve gerar uma resposta adequada para o usuário.
Melhor: para solicitações classificadas como dúvidas de uso do produto, a IA deve responder usando apenas a base fornecida, citar a seção de referência interna exibida ao revisor e indicar quando não houver informação suficiente.

O segundo critério ainda pode exigir refinamento técnico, mas já permite verificar comportamento. Ele define domínio, fonte, evidência e reação diante da lacuna. O primeiro depende de julgamento solto e tende a produzir discussões intermináveis na revisão.

Quando o conteúdo exige interpretação humana, o critério pode incluir revisão manual. Isso não é fracasso da automação. O DORA recomenda testes ao longo do desenvolvimento, combinando automação e atividades manuais, como exploração e usabilidade, e também recomenda manter e revisar as suítes de teste em vez de tratar qualidade como etapa posterior DORA. Neste guia, essa combinação é o ponto de partida: critérios automatizados quando possível, revisão humana quando o julgamento sobre contexto, suficiência ou uso ainda for necessário.

Transforme falhas previsíveis em critérios bloqueantes

Aceite não é apenas provar que algo funciona. É decidir quais falhas impedem a liberação.

Em funcionalidades de IA, médias e exemplos positivos podem esconder riscos relevantes. Uma equipe pode observar várias respostas úteis e ainda assim precisar bloquear a funcionalidade se ela executar uma ação não autorizada, inventar uma informação crítica, omitir incerteza em um caso sensível ou produzir uma saída em formato incompatível com o sistema.

Critérios negativos devem ser escritos antes da pressão pela entrega. Alguns tipos comuns de falha bloqueante:

Resposta sem base nas informações disponíveis.
Instrução que contraria regra de negócio definida.
Ação executada sem confirmação quando confirmação era obrigatória.
Omissão de incerteza quando os dados são incompletos.
Tratamento de exceção como se fosse caso rotineiro.
Saída fora do formato exigido para continuidade do fluxo.
Alteração indevida de dado em sistema conectado.

A formulação prática é: “a presença desta falha reprova o aceite até correção, restrição de escopo ou mudança explícita de desenho”.

Essa frase muda a conversa. Em vez de perguntar se a funcionalidade “foi bem o suficiente”, a equipe pergunta se apareceu alguma falha que a organização já decidiu não aceitar. Confiança não nasce do entusiasmo com os acertos. Nasce da capacidade de nomear os erros que não podem passar.

Também é aqui que liderança, produto, engenharia e qualidade precisam estar na mesma sala. Engenharia pode automatizar parte dos verificadores. Produto pode definir valor e contexto de uso. Qualidade pode explicitar casos de borda e regressões. Liderança precisa decidir quais riscos são incompatíveis com a exposição ao usuário. Se a organização ainda não sabe fazer essa conversa, o problema não é só técnico. É um sinal de maturidade a desenvolver, como discutido em maturidade em IA.

Defina limites de atuação antes de medir desempenho

Uma funcionalidade pode ter bom desempenho em casos comuns e ainda assim ser inaceitável. Isso acontece quando ela ultrapassa o nível de autonomia permitido.

Limite de autonomia é a fronteira entre sugerir, preparar, executar, aprovar, recusar ou interromper uma ação. Para critérios de aceite, essa fronteira precisa ser escrita de forma operacional.

Em vez de “a IA ajuda o usuário a resolver solicitações”, prefira algo como:

A IA pode sugerir uma categoria.
A IA pode preencher uma justificativa preliminar.
A IA não pode aprovar a solicitação.
A IA deve encaminhar para revisão humana quando o comprovante estiver ilegível, incompleto ou contraditório.

Esse tipo de limite reduz ambiguidades. Ele também evita que uma boa experiência de demonstração seja confundida com autorização para operar em escala.

A autonomia não precisa ser a mesma para todas as ações. Uma funcionalidade pode preencher um campo de baixo risco, apenas sugerir texto em outro ponto e bloquear qualquer execução em casos fora do domínio. A decisão madura não é sempre restringir. É calibrar a autonomia conforme impacto, reversibilidade, evidência disponível e capacidade de monitoramento.

Modelos de terceiros podem fazer parte de produtos maduros. O ponto não é possuir o modelo, mas desenhar o comportamento permitido, os verificadores de resultado e as condições de interrupção. A maturidade aparece menos na escolha do fornecedor e mais na clareza sobre o que o sistema pode fazer quando está certo, incerto ou errado.

Use verificadores diferentes para conteúdo, processo e ambiente

Um critério de aceite para IA pode falhar por motivos diferentes. A resposta pode estar errada. O caminho usado para chegar à resposta pode violar uma regra. O efeito no ambiente pode não ter acontecido.

Por isso, vale separar três verificadores:

Verificador de conteúdo: avalia se a saída está correta, suficiente, fundamentada ou no formato esperado.
Verificador de processo: avalia se a funcionalidade respeitou etapas, fontes, permissões e limites de autonomia.
Verificador de ambiente: avalia se o efeito esperado ocorreu no sistema, no registro, no fluxo ou na interface.

Essa separação é especialmente útil quando a funcionalidade chama ferramentas, consulta bases, escreve em sistemas ou prepara ações para pessoas. A IA pode dizer que atualizou uma informação, mas o ambiente pode não refletir isso. Pode produzir a resposta certa usando uma fonte proibida. Pode seguir o processo correto e ainda assim gerar uma saída insuficiente.

Nem todo verificador precisa ser automatizado. Alguns podem ser regras determinísticas, como checar formato, presença de campos ou ausência de ação proibida. Outros podem envolver revisão humana, principalmente quando há usabilidade, interpretação contextual ou julgamento sobre suficiência. O critério de aceite deve dizer qual evidência será aceita, não apenas quem ficou com uma boa impressão.

Aqui está uma verificação útil para a equipe: se duas pessoas revisarem a mesma saída, elas conseguem usar o critério para chegar a uma decisão parecida? Se a resposta for não, talvez o critério ainda esteja descrevendo preferência, não aceite.

Inclua aceite gradual quando a exposição ao usuário aumentar risco

Aceitar uma funcionalidade em ambiente controlado não significa ativá-la para todos os usuários, fluxos e volumes. Em IA, essa distinção é relevante porque mudanças de contexto podem alterar o comportamento percebido e o risco operacional.

O capítulo do 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. Também distingue disponibilizar código de ativar funcionalidades e discute configurações para separar essas decisões Google SRE. A aplicação para aceite de IA é direta: liberar código, ativar a funcionalidade e ampliar uso não precisam ser a mesma decisão.

Critérios de aceite podem prever condições de ampliação e interrupção. Por exemplo:

A funcionalidade começa ativa apenas em um conjunto limitado de contextos.
A ampliação depende da ausência de falhas bloqueantes definidas previamente.
Reclamações qualificadas, degradação de fluxo ou aumento de intervenção manual podem exigir pausa.
Certos tipos de entrada continuam fora do escopo mesmo após a primeira liberação.

A função do aceite gradual é tornar a ampliação uma decisão observável. A equipe define antes quais sinais permitem avançar, pausar ou reduzir exposição, em vez de descobrir esses limites apenas no uso amplo.

Também ajuda a evitar uma armadilha: tratar o lançamento como ponto final. Em funcionalidades de IA, o aceite inicial deve abrir um ciclo de acompanhamento. Se o contexto muda, a base muda, o modelo muda ou o comportamento dos usuários muda, os critérios precisam ser revisitados.

Matriz de aceite para funcionalidades de IA

A proposta deste guia é usar a matriz abaixo antes da construção, na revisão de qualidade e na decisão de liberação. Ela não substitui uma avaliação técnica completa, jurídica, regulatória, de segurança da informação ou de governança quando o contexto exigir, mas ajuda a tornar sucesso, falha e limites verificáveis.

Entrada coberta

Pergunta: quais entradas a funcionalidade deve aceitar e quais entradas devem ser recusadas ou encaminhadas para outro fluxo?

Evidência esperada: lista de tipos de entrada com exemplos válidos, inválidos e ambíguos.

Regra de aceite: a funcionalidade só passa se tratar corretamente os tipos de entrada definidos e recusar ou escalar os casos fora do escopo.

Resultado verificável

Pergunta: como a equipe saberá que a saída produziu o resultado esperado, e não apenas uma resposta bem escrita?

Evidência esperada: critério de comparação, regra de negócio, verificador automatizado ou revisão humana previamente definida.

Regra de aceite: a funcionalidade só passa se a evidência confirmar o resultado esperado no ambiente ou no fluxo definido.

Falha bloqueante

Pergunta: quais erros impedem a liberação mesmo que a média dos testes pareça boa?

Evidência esperada: lista de falhas que bloqueiam aceite, como ação sem autorização, resposta com instrução perigosa, omissão de incerteza quando ela precisa ser declarada ou alteração indevida de dado.

Regra de aceite: a presença de qualquer falha bloqueante reprova o aceite até correção ou mudança de escopo.

Limite de autonomia

Pergunta: a IA pode sugerir, preencher, executar, aprovar ou apenas preparar uma ação para revisão?

Evidência esperada: matriz simples de ações permitidas, ações proibidas e ações que exigem confirmação humana.

Regra de aceite: a funcionalidade só passa se permanecer dentro do nível de autonomia definido para cada ação.

Comportamento diante da incerteza

Pergunta: o que a funcionalidade deve fazer quando não tiver evidência suficiente para responder ou agir?

Evidência esperada: casos de teste com dados incompletos, contraditórios ou fora do domínio previsto.

Regra de aceite: a funcionalidade só passa se declarar limitação, pedir informação adicional, encaminhar para revisão ou interromper a ação conforme o caso.

Condição de ampliação ou interrupção

Pergunta: quais sinais autorizam ampliar a exposição e quais sinais exigem pausar, reverter ou restringir o uso?

Evidência esperada: critérios de acompanhamento definidos antes da ativação, incluindo falhas críticas, reclamações qualificadas, degradação de fluxo ou aumento de intervenção manual.

Regra de aceite: a funcionalidade só avança se os sinais definidos permanecerem dentro do limite aceito. Caso contrário, a exposição deve ser interrompida ou reduzida.

Exemplo fictício: aceite de uma sugestão de reembolso

Exemplo fictício: uma funcionalidade de IA sugere respostas para solicitações de reembolso em um sistema interno.

Um critério fraco seria: “a IA deve responder corretamente à maioria dos pedidos de reembolso”. Ele não diz o que é correto, qual risco bloqueia a liberação, qual evidência será usada nem quem decide quando houver incerteza.

Um critério melhor seria: para despesas abaixo de um limite definido pela organização e com comprovante legível, a IA pode sugerir a categoria e uma justificativa. A aprovação final continua com uma pessoa. O aceite exige que a sugestão use apenas dados presentes no comprovante e nas regras internas fornecidas ao sistema. Se o comprovante estiver ilegível, se houver contradição entre dados ou se a despesa estiver fora das categorias previstas, a IA deve declarar limitação e encaminhar para revisão.

Esse critério permite verificar entrada, resultado, autonomia, falha bloqueante e comportamento diante da incerteza. Ele não promete eliminar erros. Ele cria uma base mais honesta para decidir se a funcionalidade pode entrar em uso controlado, precisa de ajuste ou deve ter o escopo reduzido.

Uma funcionalidade de IA só deveria avançar para implementação ou liberação quando a equipe conseguir escrever, antes, entrada, comportamento esperado, evidência mínima, falhas bloqueantes, limites de autonomia e condição de interrupção. Se isso ainda não cabe no papel, o produto ainda não tem critério de aceite suficiente para exposição ao usuário.

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.