Como testar falhas em produtos com IA

Uma funcionalidade com inteligência artificial pode acertar nos casos esperados e ainda falhar de um jeito perigoso quando encontra uma exceção. Testar cenários de falha de IA é decidir antes da produção o que o produto faz quando uma ferramenta externa cai, uma resposta fica incompleta ou uma ação não é confirmada.

O teste começa quando o time define gatilho, comportamento esperado, evidência verificável, recuperação e limite de exposição.

Por que acerto médio não libera exceções perigosas

Em produtos com inteligência artificial, a pergunta “funciona?” costuma esconder perguntas melhores. Funciona quando a entrada é ambígua? Funciona quando a API externa não responde? Funciona quando o agente diz que executou uma ação, mas o ambiente não mudou? Funciona quando o produto precisa admitir incerteza sem abandonar o usuário?

A média de acerto ajuda a entender desempenho geral, mas não aprova sozinha o comportamento em falha. Uma funcionalidade pode parecer madura em uma demonstração e ainda não ter resposta desenhada para o momento em que perde uma condição necessária para operar.

Esse é o ponto que muda a conversa de qualidade. Cenários de falha de IA não são uma coleção tardia de exceções técnicas. Eles fazem parte do desenho do produto, porque definem limites de autonomia, linguagem para o usuário, responsabilidades de operação e critérios de interrupção.

A decisão de liderança é menos glamorosa do que escolher o modelo e mais determinante para a confiança: quando o sistema não puder confiar no próprio resultado, ele deve bloquear, pedir confirmação, reduzir autonomia, encaminhar para revisão, tentar novamente ou voltar para um fluxo convencional?

Essa decisão também evita uma armadilha comum: tratar qualquer resposta fluente como sinal de conclusão. Em agentes de IA, especialmente aqueles que executam ações em ferramentas, a qualidade não está apenas no texto gerado. Está no efeito real produzido no ambiente.

Mapeie falhas por gatilho, efeito e responsabilidade

Um bom teste de exceção começa separando três coisas que costumam aparecer misturadas: o gatilho da falha, o efeito indesejado e quem assume o próximo passo.

O gatilho é a condição que provoca o problema. Pode ser uma entrada ambígua, uma dependência indisponível, uma resposta inconsistente, uma ação não confirmada, um limiar de confiança baixo ou um conflito com regra de negócio. O efeito é o dano que o produto deve evitar. A responsabilidade define se a próxima ação cabe ao sistema, ao usuário, ao suporte, à operação ou a uma fila de revisão.

Essa classificação troca uma discussão genérica sobre “erro de IA” por uma decisão sobre gatilho, dano e responsável. Em vez de “testar erro de IA”, o time passa a discutir casos mais concretos:

Entrada ambígua: o usuário pede algo que pode ter mais de uma interpretação. O risco é o sistema escolher sozinho um caminho que deveria ser confirmado.
Dependência indisponível: uma ferramenta externa, base de dados ou serviço de autorização não responde. O risco é o produto afirmar que concluiu algo que não conseguiu executar.
Resposta inconsistente: a IA apresenta informações incompatíveis dentro do mesmo fluxo. O risco é o usuário agir sobre uma orientação contraditória.
Ação não confirmada: um agente inicia uma tarefa, mas não recebe confirmação do ambiente. O risco é registrar sucesso sem evidência.
Confiança baixa: o produto identifica que não tem segurança suficiente para seguir. O risco é mascarar incerteza com linguagem confiante.
Conflito com regra de negócio: a IA propõe uma ação permitida linguisticamente, mas inválida para o produto. O risco é contornar uma regra que deveria limitar a automação.

O mapeamento não precisa tentar prever todas as exceções possíveis. Ele deve cobrir as falhas relevantes para o dano que o produto pode causar e para o custo de recuperação. Em um assistente interno de baixa criticidade, uma nova tentativa pode bastar. Em uma funcionalidade que altera dados operacionais, confirmar uma ação inexistente pode ser o erro central a evitar.

Essa diferença também vale para uma estratégia mais ampla de adoção. Um produto maduro pode usar modelos de terceiros e ainda assim ter bons limites, verificadores e recuperação. Maturidade não exige modelo próprio. Exige clareza sobre o que o produto está autorizado a fazer e como reage quando perde evidência.

Defina o comportamento seguro antes de escrever o teste

O teste não deve nascer de uma exceção técnica isolada. Deve nascer de uma decisão de produto.

Antes de escrever o caso de teste, o time precisa declarar qual comportamento é seguro para aquela falha. Bloquear pode ser correto quando o risco de seguir é alto. Pedir confirmação pode ser suficiente quando a incerteza está na intenção do usuário. Reduzir autonomia faz sentido quando o sistema ainda pode ajudar, mas não deve executar. Escalar para revisão humana é melhor quando a exceção é rara, ambígua ou de alto impacto.

A automação de testes não elimina atividades manuais de qualidade. O DORA recomenda testes ao longo do desenvolvimento, combinando automação com práticas manuais como exploração e usabilidade, além de revisar e manter as suítes de teste em vez de tratar qualidade como etapa posterior ao desenvolvimento DORA. Em produtos com IA, essa recomendação ganha uma leitura prática: o comportamento de falha precisa ser explorado, discutido e depois transformado em verificação repetível quando fizer sentido.

Alguns comportamentos seguros possíveis:

Bloquear a ação quando falta evidência mínima.
Pedir confirmação quando a intenção do usuário é ambígua.
Reduzir autonomia, mantendo recomendação, mas removendo execução automática.
Oferecer alternativa, como um fluxo convencional sem IA.
Registrar evidência da falha e do estado preservado.
Encaminhar para revisão humana com contexto suficiente.
Reverter ou restaurar o estado quando uma tentativa deixa o fluxo incompleto.

A parte difícil é escolher. “Tratar erro” é genérico demais. “Se a ferramenta de agendamento não confirmar a criação do evento, o assistente não deve dizer que a alteração foi agendada, deve preservar os dados coletados e oferecer nova tentativa ou encaminhamento” já é uma decisão testável.

Essa formulação separa erro técnico de experiência de recuperação. O usuário não precisa receber uma pilha de detalhes internos. Ele precisa entender o que não aconteceu, o que foi preservado e qual caminho seguro pode seguir.

Teste a recuperação, não apenas a detecção da falha

Agentes de IA exigem uma atenção específica: uma trajetória de execução não é a mesma coisa que resultado efetivo. A Anthropic distingue a trajetória do agente do efeito produzido no ambiente e observa que uma mensagem dizendo que a tarefa terminou não basta para comprovar o resultado Anthropic.

Isso muda o desenho dos testes. Se um agente diz “concluí”, o verificador não deve aprovar o caso apenas pela frase. Ele precisa observar o ambiente: o item foi criado? A permissão foi preservada? A transação perigosa não foi executada? O estado anterior foi restaurado? O registro mostra falha quando deveria mostrar falha?

A avaliação passa a ter entradas, critérios de sucesso e verificadores. Em alguns casos, pode exigir várias tentativas, como também descreve a Anthropic ao tratar avaliações de agentes. Mas o ponto central para produto e qualidade é outro: o critério precisa validar o efeito observável, não a autodeclaração da IA.

Isso vale inclusive quando o produto não é um agente completo. Uma funcionalidade que apenas recomenda, classifica ou resume também pode precisar verificar resultado real. Se a IA recomenda uma ação bloqueada por regra de negócio, o teste deve confirmar que a regra prevalece. Se a resposta fica inconsistente, o teste deve verificar se o produto sinaliza a limitação em vez de encadear uma próxima ação como se nada tivesse acontecido.

Há aqui uma frase que deveria estar em muitas revisões de produto: confiança não é o sistema parecer seguro, é o produto ter uma forma verificável de se comportar quando não sabe.

Use um checklist de recuperação para cenários de falha de IA

O checklist abaixo é uma proposta aplicada para transformar exceções em casos de teste. Ele não substitui uma avaliação completa de qualidade de IA, nem cobre revisão de código, critérios de aceite, regressão ou avaliação humana em profundidade. A utilidade está em forçar uma pergunta operacional para cada falha relevante.

Checklist para testar recuperação em cenários de falha de IA

Gatilho reproduzível: qual condição dispara a falha de forma observável? O caso passa quando o time consegue provocar a falha com uma entrada, configuração, indisponibilidade simulada ou estado conhecido.
Efeito indesejado: qual dano o produto deve evitar? O caso passa quando descreve o risco concreto, como confirmar uma ação não realizada, expor informação indevida, tomar uma decisão sem evidência ou prender o usuário em um fluxo sem saída.
Comportamento esperado: o produto deve bloquear, pedir confirmação, reduzir autonomia, tentar novamente ou escalar? O caso passa quando há resposta definida antes do teste, com linguagem, ação e responsável pelo próximo passo.
Evidência verificável: como o time sabe que o resultado real ocorreu? O caso passa quando a validação observa o estado do ambiente, o registro da ação, a ausência da ação perigosa ou a restauração do fluxo, e não apenas a resposta textual da IA.
Recuperação do usuário: o usuário consegue continuar com segurança? O caso passa quando o produto preserva contexto suficiente, explica a limitação de forma acionável e oferece caminho seguro, como nova tentativa, revisão humana ou fluxo alternativo.
Limite de exposição: até onde a funcionalidade pode operar enquanto a falha é monitorada? O caso passa quando existe critério para limitar, pausar ou ampliar a exposição, em vez de tratar a liberação como decisão binária.
Dono da decisão: quem decide mudar o comportamento quando o teste revela uma falha relevante? O caso passa quando produto, engenharia, qualidade ou operação sabem qual decisão lhes cabe e qual evidência precisam considerar.

Esse checklist ajuda a evitar dois extremos. O primeiro é acreditar que toda exceção será resolvida por mais automação. O segundo é desistir de automatizar qualquer recuperação porque a IA é probabilística. Entre os dois, existe uma disciplina mais útil: automatizar o que pode ser verificado, limitar o que não pode e desenhar a intervenção humana quando ela é a escolha mais segura.

Para equipes que estão organizando a adoção de IA além de uma funcionalidade isolada, esse tipo de critério conversa com decisões de maturidade e governança. Vale conectar a discussão a uma visão mais ampla de maturidade em IA e de estratégia de inteligência artificial conectada ao negócio, porque a qualidade da recuperação depende de responsabilidades, não apenas de prompts melhores.

Exemplo fictício: assistente que agenda uma alteração operacional

Imagine um exemplo fictício: uma empresa usa um assistente interno para ajudar equipes a agendar alterações operacionais. O usuário descreve a mudança, o assistente coleta informações, sugere uma janela e tenta criar um evento em uma ferramenta de calendário. Depois de gerar a recomendação, a ferramenta de calendário falha.

O teste feliz verificaria se, em condições normais, o evento é criado. O teste de falha precisa verificar outra coisa: o produto não pode confirmar uma ação inexistente.

Aplicando o checklist, o gatilho reproduzível pode ser a indisponibilidade simulada da ferramenta de calendário no momento da criação do evento. O efeito indesejado é claro: o usuário acreditar que a alteração foi agendada quando nada foi registrado. O comportamento esperado é informar a falha, preservar os dados já coletados, oferecer nova tentativa ou encaminhamento e não marcar a tarefa como concluída.

A evidência verificável não é a mensagem do assistente. É a ausência do evento no calendário, combinada com um registro interno de tentativa não concluída e com a preservação do estado do fluxo. A recuperação do usuário precisa ser observável: ele deve conseguir revisar os dados, tentar novamente ou seguir para um canal definido sem recomeçar do zero.

Os efeitos esperados desse desenho são hipóteses a medir, não resultados ocorridos. O time pode observar se os usuários entendem a falha, se conseguem continuar e se a operação identifica tentativas pendentes. Mas nada disso deve ser presumido antes de testar.

Esse exemplo também mostra por que o vocabulário importa. “Erro ao integrar com calendário” é uma descrição técnica. “Não confirmar agendamento sem confirmação externa” é um critério de produto. O segundo orienta melhor a interface, o teste, o registro e a decisão de liberação.

Libere a recuperação em exposição controlada

Mesmo quando os testes de falha passam em ambiente controlado, a exposição em produção merece cuidado. O capítulo de canarying do Google SRE 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 pelo uso de configurações quando a arquitetura permite Google SRE.

Essa distinção ajuda a separar publicação, ativação e ampliação de uma funcionalidade com IA. Publicar código não precisa significar ativar autonomia para todos. Ativar recomendação não precisa significar ativar execução. Ativar execução não precisa significar remover limites de exposição.

Para cenários de falha, a liberação gradual deve observar a recuperação, não apenas o sucesso. O produto informa a falha sem induzir o usuário ao erro? O caminho alternativo aparece quando deveria? A ação perigosa permanece bloqueada? O registro permite entender o que aconteceu? Existe critério para pausar ou ampliar a funcionalidade?

A medição de produtividade ou tempo, por si só, não resolve essa decisão. 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 como seleção de participantes e tarefas e medição de tempo com agentes concorrentes METR. Aqui, a ressalva permitida é metodológica: medir sistemas com IA exige cuidado sobre o que exatamente está sendo observado.

No caso de recuperação, observe o comportamento específico da falha. Se a ferramenta externa cai, o sistema recupera com segurança? Se o agente não confirma a ação, o produto impede a falsa conclusão? Se a confiança baixa, o fluxo reduz autonomia? Essas perguntas são mais úteis do que uma média agregada que mistura casos fáceis, difíceis e exceções raras.

Há limites. Nem toda exceção deve virar automação. Em falhas raras, ambíguas ou de alto impacto, interromper o fluxo e encaminhar para julgamento humano pode ser a melhor decisão de desenho. Julgamento humano não deve aparecer como remendo tardio, mas como parte explícita do sistema de qualidade.

Preparar exceções e comportamento de recuperação significa decidir, para cada falha relevante, quando interromper a automação, como conduzir o usuário por um caminho seguro e qual evidência confirma que a recuperação aconteceu. A exposição só deve crescer quando a recuperação também tiver critério, não apenas quando a IA acerta os casos esperados.

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.