Como testar exceções raras em aplicações de IA

Um teste pode passar na maioria das simulações e ainda esconder um risco que ninguém aceitaria em produção. Em casos extremos em aplicações de inteligência artificial, a frequência estimada costuma chegar tarde demais. Primeiro vem a pergunta sobre dano, visibilidade e reversão.

O trabalho começa separando cenários de baixo incômodo de exceções raras capazes de acionar consequências sensíveis, atravessar fluxos ou ficar invisíveis até ser tarde.

Por que frequência não deve ser o primeiro filtro

Equipes de produto e engenharia costumam tomar uma decisão compreensível: se um cenário parece raro, ele fica para depois. Em sistemas tradicionais, essa escolha já pode ser arriscada. Em aplicações com IA, ela fica ainda mais delicada porque o comportamento observado em um conjunto pequeno de testes pode não representar a variedade real de contextos, permissões, dados e instruções que aparecerão no uso.

O problema não é a raridade em si. Um erro raro, visível e fácil de desfazer pode ser monitorado. Um erro raro que aciona uma consequência sensível, altera um dado compartilhado ou passa despercebido precisa de outro tratamento.

A frequência observada ajuda depois. Ela não deve abrir a triagem.

Comece por quatro perguntas:

Qual é o pior dano plausível se a exceção acontecer?
A ação pode ser desfeita sem custo relevante?
A falha aparece no momento em que ocorre ou pode parecer uma resposta correta?
A exceção afeta uma pessoa isolada ou pode se propagar pelo sistema?

Essa lógica evita dois erros comuns. O primeiro é inflar a suíte de testes com variações quase iguais, só porque são fáceis de automatizar. O segundo é deixar de fora um caso pouco frequente, mas capaz de quebrar confiança, gerar retrabalho caro ou exigir intervenção manual complexa.

O DORA recomenda tratar testes ao longo do desenvolvimento, combinando automação com atividades manuais, como exploração e usabilidade, e mantendo as suítes sob revisão. Essa recomendação é útil aqui porque exceções raras não cabem bem em uma visão de qualidade como barreira final. Elas precisam entrar na conversa de desenho, implementação, avaliação e lançamento.

Classifique exceções raras por dano, reversão e visibilidade

Uma exceção rara deve ser classificada antes de virar teste. Sem essa triagem, a equipe mistura cenários de baixo impacto com riscos que deveriam bloquear uma ativação.

Use uma matriz simples, sem transformar tudo em pontuação artificial:

Dano possível: baixo, moderado ou alto para usuário, operação, reputação ou continuidade do processo.
Reversão: simples, trabalhosa ou impraticável dentro do fluxo normal.
Visibilidade: evidente para o usuário, detectável por sistema ou silenciosa.
Exposição: limitada a um contexto, repetível em vários fluxos ou capaz de afetar dados compartilhados.
Julgamento humano: existe revisão antes da consequência ou a IA pode conduzir a ação sozinha?

A combinação desses fatores define o tratamento. Um erro de texto em uma recomendação interna, com revisão humana antes de qualquer ação, pode ficar em avaliação manual e monitoramento. Uma ação automática que altera permissões, dispara comunicação externa ou modifica cadastro sem revisão pede critério mais rígido.

Quando alguém diz “isso é raro”, a liderança deveria responder: raro com qual dano, qual reversão e qual visibilidade?

A resposta define desenho operacional: onde bloquear, onde revisar, onde automatizar e onde observar.

Transforme exceções em casos de teste verificáveis

Descrições vagas não viram bons testes. “O agente pode se confundir” é uma preocupação legítima, mas ainda não é um caso testável.

Para transformar a exceção em teste, defina:

Entrada: o que o usuário pede e quais dados a IA recebe.
Estado inicial: permissões, registros, configurações e contexto disponíveis.
Ação esperada: o que a aplicação pode fazer.
Resultado proibido: o que não pode acontecer mesmo que a resposta pareça plausível.
Verificador: como a equipe confirma o resultado efetivo no ambiente.

Esse último item é decisivo em aplicações com agentes. Um agente é um sistema que pode planejar passos e executar ações em ferramentas ou ambientes, não apenas responder texto. A Anthropic 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 que o resultado correto aconteceu.

Não teste apenas a fala da IA. Teste o estado que ficou depois.

Se o agente diz “solicitação preparada”, o verificador deve confirmar se ela foi preparada no lugar certo, com os campos corretos, sem envio indevido e respeitando as permissões. Se a IA diz “não alterei nada”, o verificador deve confirmar que nenhum registro foi alterado. O caso extremo fica mais caro de testar, mas também fica mais honesto.

Essa disciplina se conecta a decisões maiores de adoção de IA. Em uma estratégia de inteligência artificial conectada ao negócio, uma demonstração convincente não basta. A equipe precisa especificar o que pode acontecer, verificar o que aconteceu e decidir quando interromper.

Use cobertura por famílias de risco, não por lista infinita de cenários

O objetivo não é criar uma lista interminável de exceções. Isso torna a suíte lenta, repetitiva e difícil de manter. A alternativa é organizar cobertura por famílias de risco.

Uma forma prática de agrupar exceções raras na análise de desenho é separar famílias como:

Permissão incompleta: o usuário pode ver parte dos dados, mas não pode executar todas as ações associadas.
Ambiguidade de instrução: o pedido permite mais de uma interpretação operacional.
Dado ausente ou desatualizado: a IA tem informação insuficiente, mas pode responder com confiança aparente.
Ação difícil de reverter: a consequência exige correção manual, comunicação posterior ou reconstrução de estado.
Conflito de instruções: política do produto, comando do usuário e contexto do sistema apontam para caminhos diferentes.
Dependência externa: uma ferramenta, base ou integração responde de forma incompleta, lenta ou inconsistente.
Limite de responsabilidade do produto: a IA se aproxima de uma decisão que deveria continuar com uma pessoa ou com outro fluxo de autorização.

A cobertura boa não testa todas as combinações. Ela seleciona representantes de cada família e explicita por que eles importam.

Por exemplo: em vez de escrever muitos testes para frases diferentes de um mesmo pedido ambíguo, a equipe pode manter poucos casos que cubram o mesmo risco estrutural: a IA não deve executar ação quando a intenção não estiver resolvida, quando o usuário não tiver permissão suficiente ou quando o dado de base estiver incompleto.

Esse tipo de organização também ajuda a revisar a maturidade do sistema. Um diagnóstico de maturidade em IA não precisa exigir modelo próprio nem infraestrutura sofisticada desde o primeiro dia. Mas precisa mostrar se a organização sabe onde a IA pode errar, quem decide o limite e como o sistema aprende com falhas sem normalizá-las.

Exemplo fictício: assistente que sugere ações de operação interna

Considere um exemplo fictício: uma empresa usa um assistente de IA para apoiar uma equipe de operações internas. O assistente pode resumir dados de solicitações, sugerir próximos passos e preparar uma minuta de ação para revisão. Ele não deve alterar cadastros, enviar mensagens externas nem aprovar mudanças sem confirmação de uma pessoa autorizada.

Três exceções raras aparecem na triagem.

A primeira é usuário com acesso parcial. A pessoa pode consultar o status de uma solicitação, mas não pode ver anexos sensíveis nem alterar responsáveis. O caso testável seria: usuário com permissão parcial pede “regularize este chamado e atualize o responsável”. A ação esperada é explicar o limite e preparar, no máximo, uma solicitação de encaminhamento. O resultado proibido é alterar o responsável ou revelar dados restritos. O verificador precisa consultar o estado do registro e os logs de acesso da aplicação, quando disponíveis.

A segunda exceção é instrução ambígua. O usuário escreve “faça o ajuste padrão neste cadastro”. O problema é que “ajuste padrão” pode significar coisas diferentes conforme o tipo de solicitação. A ação esperada é pedir esclarecimento ou apresentar opções sem executar. O resultado proibido é escolher uma interpretação e aplicar a mudança. O verificador confirma que nenhum campo foi alterado e que a resposta pediu desambiguação.

A terceira exceção é dado desatualizado. O assistente recebe um resumo antigo e uma base mais recente está indisponível naquele momento. A ação esperada é informar a limitação e impedir a preparação de uma ação conclusiva. O resultado proibido é apresentar uma recomendação como se os dados estivessem completos. O verificador observa a origem dos dados usada, o estado da dependência externa e se a resposta sinalizou incerteza operacional.

Nenhum desses cenários exige presumir frequência. Eles exigem avaliar dano, reversão e visibilidade. Se uma alteração indevida puder ser desfeita rapidamente antes de afetar outro fluxo, talvez o tratamento seja teste automatizado e monitoramento. Se a alteração puder se propagar, o caso deve bloquear execução automática ou exigir revisão humana antes de ativação ampla.

Decida o tratamento: automatizar, revisar manualmente, lançar gradualmente ou bloquear

Depois de classificar a exceção e transformá-la em caso verificável, vem a decisão de tratamento. Nem todo caso raro deve virar teste automatizado. Nem todo caso raro justifica bloqueio. A decisão precisa combinar risco e capacidade de controle.

Antes de decidir o tratamento, responda:

Se a exceção acontecer uma única vez, o dano é aceitável? Se envolver exposição indevida, alteração difícil de reverter, decisão sensível para o fluxo ou quebra relevante de confiança, trate como alta gravidade mesmo sem evidência de frequência.
A ação pode ser desfeita sem custo relevante? Se a recuperação depender de intervenção manual complexa, contato com usuário ou reconstrução de dados, aumente a prioridade do teste.
A falha é visível no momento em que ocorre? Se a IA puder parecer correta enquanto executa a ação errada, o caso precisa de verificador de resultado, não apenas avaliação da resposta textual.
O erro afeta uma pessoa isolada ou pode se propagar? Se puder alterar dados compartilhados, acionar integrações, gerar comunicação externa ou influenciar decisões posteriores, classifique como risco sistêmico.
Existe critério de sucesso observável? O caso só está pronto para teste quando houver entrada definida, estado inicial, ação esperada, resultado proibido e forma de verificação.
A equipe consegue detectar o problema em produção limitada? Se houver sinal confiável, reversão simples e exposição controlada, considere lançamento gradual. Se não houver detecção clara, produção limitada não substitui teste.
O cenário raro representa uma família de risco maior? Quando vários casos têm a mesma causa, como permissão ambígua ou dado ausente, priorize um conjunto representativo em vez de acumular exemplos quase iguais.

A regra operacional pode ser simples: alta gravidade com baixa reversão deve bloquear ativação ou exigir revisão humana; alta gravidade com boa detecção pode combinar testes verificáveis e exposição gradual; baixa gravidade com boa reversão pode ser monitorada sem expandir a suíte de forma artificial.

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 exposição. Também distingue disponibilizar código de ativar funcionalidades, usando configurações para separar essas decisões. Para IA, essa separação é valiosa: colocar código em produção não precisa significar permitir que a funcionalidade tome todas as ações para todos os usuários.

Como manter a suíte viva depois do primeiro mapeamento

O primeiro mapeamento não encerra o trabalho. Exceções raras mudam quando muda o modelo, o prompt, a política de permissão, a base de dados, a ferramenta conectada ou o próprio fluxo do produto.

A suíte precisa ser revisada em momentos concretos:

Depois de uma falha relevante ou quase falha.
Depois de mudança de modelo, provedor ou configuração.
Depois de alterar permissões, papéis de usuário ou escopo de ação.
Depois de incluir uma nova dependência externa.
Depois de mudar o ponto em que uma pessoa revisa ou autoriza a consequência.

Essa manutenção evita que a suíte vire arquivo histórico. Um caso extremo que já foi crítico pode perder importância se o fluxo ganhou confirmação humana. Outro pode se tornar bloqueador se a funcionalidade passou de recomendação para execução.

Também vale separar exploração manual de teste automatizado. Exploração manual é útil quando a equipe ainda está descobrindo como a IA falha. Teste automatizado é melhor quando já existe hipótese testável, entrada definida, critério de sucesso e verificador. Misturar as duas coisas cria falsa segurança: parece que a equipe testou muito, mas talvez só tenha acumulado exemplos sem critério.

A liderança precisa assumir esse aceite de risco junto com engenharia. Um roadmap de IA que só lista funcionalidades perde uma parte do risco. O roadmap precisa reservar espaço para limites de ação, revisão humana, avaliação, lançamento gradual e manutenção da suíte.

Casos extremos em aplicações de IA pedem triagem antes de estimativa. O raro é aceitável quando o impacto é baixo, detectável e recuperável. Quando o impacto é alto, silencioso ou difícil de desfazer, a frequência presumida não deve servir como desculpa para seguir em frente.

Classifique cada exceção rara por dano, reversão, visibilidade e exposição antes de discutir prioridade. Se o cenário for grave e pouco recuperável, bloqueie a ativação ou mantenha revisão humana. Se for verificável e controlável, automatize o teste e considere exposição gradual. Se ainda não houver critério observável, trate como exploração, não como garantia de qualidade.

A pergunta útil para a próxima revisão é simples: qual exceção rara você está deixando para depois apenas porque ainda não conseguiu estimar a frequência?

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

Leituras para continuar

Fontes

Para continuar esta leitura

Como interpretar uma nota de avaliação de IA

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.