Como registrar falhas de IA para evitar recorrência

Um registro de falha de IA pode nascer com uma frase curta demais: “o modelo errou” ou “o prompt estava ruim”. O problema é que esse tipo de anotação já entrega uma conclusão antes de preservar o fato. Para evitar recorrência, a equipe precisa separar três camadas: o evento observado, a causa possível e a ação que será checada depois.

Quando uma falha de IA vira aprendizado, e quando vira ruído

Uma falha de IA pode aparecer em lugares diferentes: uma resposta inadequada em um atendimento, uma classificação inconsistente em uma triagem interna, uma ação errada de um agente ou uma recomendação que contradiz uma política da empresa.

A reação inicial costuma ser rápida. Alguém troca o prompt. Outra pessoa pede para atualizar a base. O time abre uma tarefa com um título amplo. Em casos mais tensos, a conversa vira uma disputa sobre culpa: foi o modelo, o dado, a integração, o usuário, o avaliador ou o produto?

Essa discussão pode abrir tarefas e mudanças rápidas, mas nem sempre deixa evidência suficiente para evitar a mesma falha depois.

O registro de uma falha de IA precisa servir a uma pessoa que não estava na reunião, não viu a tela original e não lembra do contexto. Se essa pessoa não consegue reconstruir o ocorrido, comparar hipóteses e verificar a ação depois, o documento virou memória frágil. Ele pode acalmar a equipe por alguns dias, mas dificilmente reduz a chance de repetição.

A diferença entre aprendizado e ruído não está apenas na gravidade aparente da falha. Está na disciplina do registro.

Para temas mais amplos de adoção e governança, vale conectar esse cuidado à discussão sobre estratégia de inteligência artificial conectada ao negócio. Falhas de IA não são apenas defeitos técnicos. Elas revelam como a organização decide, testa, aceita risco e aprende.

Registre o evento antes de discutir a causa

O evento é a parte comprovável da falha de IA. Ele deve ser escrito como algo que outra pessoa consiga verificar sem depender da memória de quem relatou.

Um bom registro de evento inclui:

entrada recebida pela IA;
saída, recomendação ou ação produzida;
comportamento esperado;
contexto operacional em que ocorreu;
versão relevante do produto, configuração, base ou fluxo, quando disponível;
evidência preservada, como transcrição, captura, identificador de execução ou registro interno;
impacto observado ou risco percebido.

A ordem importa. Antes de perguntar “por que aconteceu?”, a equipe precisa conseguir responder “o que aconteceu?”.

Isso parece simples, mas é onde muitas análises começam a perder qualidade. Um registro como “a IA alucinou uma política de reembolso” já mistura evento e interpretação. Talvez tenha havido alucinação. Talvez o sistema tenha recuperado um documento antigo. Talvez o critério de aceite da funcionalidade não tenha previsto conflito entre versões. Talvez o usuário tenha formulado a pergunta de um modo que expôs uma lacuna de instrução.

O evento deveria ser escrito de modo mais verificável: “em uma simulação de atendimento, após a pergunta sobre prazo para pedir reembolso de viagem, o assistente respondeu que o prazo era de 30 dias; a política interna atual usada como referência indica 15 dias”.

Essa formulação não resolve o problema. Ela melhora a investigação.

O DORA recomenda que testes aconteçam ao longo do desenvolvimento, combinando automação com atividades manuais, como exploração e usabilidade. Também recomenda manter e revisar suítes de teste, em vez de tratar qualidade como etapa posterior ao desenvolvimento. Esse ponto é útil aqui porque uma falha bem registrada pode alimentar tanto testes automatizados quanto revisões humanas futuras.

Trate a causa como hipótese, não como conclusão

Depois do evento, vem a causa possível. A palavra “possível” não é detalhe. É uma proteção contra conclusões convenientes.

Em produtos com IA, causas diferentes podem produzir sintomas parecidos. Uma resposta errada pode vir de dado insuficiente, instrução ambígua, recuperação de contexto inadequada, limite do modelo, falha de integração, ação humana anterior, mudança de configuração ou critério de aceite incompleto.

Por isso, a causa deve ser registrada como hipótese testável:

hipótese principal: o que parece explicar melhor o evento;
hipóteses alternativas: outras explicações plausíveis;
evidência que sustenta a hipótese;
evidência que ainda falta;
condição que confirmaria ou descartaria a hipótese.

Essa estrutura muda a conversa. Em vez de perguntar “qual foi a causa raiz?” cedo demais, a equipe pergunta “que evidência separa uma hipótese da outra?”.

A expressão causa raiz pode ser útil em alguns incidentes, mas também pode criar uma falsa sensação de fechamento. Nem toda falha de IA tem uma causa única, estável e fácil de remover. Algumas aparecem na interação entre instrução, dados, contexto, interface, comportamento do usuário e limite do sistema.

O cuidado é não transformar a explicação mais plausível em diagnóstico definitivo.

A Anthropic distingue a trajetória de execução de um agente do resultado efetivo no ambiente. Uma mensagem dizendo que a tarefa terminou não basta para comprovar que o resultado foi alcançado. A mesma lógica vale para análise de falhas: uma narrativa coerente sobre o erro não basta para comprovar a causa.

Se a hipótese é “a base estava desatualizada”, a equipe precisa checar se a versão antiga estava de fato disponível para recuperação, se foi recuperada naquele caso, se havia documento mais novo concorrendo e se a instrução orientava o sistema a priorizar vigência. Sem isso, atualizar a base pode ser uma ação útil, mas ainda não confirma que aquela era a causa.

Transforme a correção em ação verificável

A terceira camada é a ação verificável. Ela responde a uma pergunta prática: depois da mudança, como a equipe saberá se o risco de recorrência diminuiu?

Ação corretiva vaga é uma das formas mais comuns de encerrar tarefas sem encerrar problemas. “Melhorar o prompt”, “revisar a base”, “monitorar de perto” e “reforçar o teste” podem ser intenções válidas, mas não bastam como registro de qualidade.

Uma ação verificável precisa dizer:

o que será alterado;
quem responde pela alteração;
quando ou em que condição a revisão será feita;
qual comportamento deve mudar;
qual verificador, caso de avaliação ou evidência será usado;
o que acontece se a falha reaparecer.

Em funcionalidades com IA, o verificador pode ser um caso de avaliação, uma revisão humana, um teste de regressão, uma comparação de respostas em contexto controlado ou uma checagem no ambiente em que a ação acontece. O formato depende do risco e da maturidade do produto.

O ponto central é que a correção não pode depender apenas de intenção.

A Anthropic descreve avaliações com entradas, critérios de sucesso e verificadores, podendo exigir várias tentativas. Essa ideia ajuda a diferenciar “o sistema respondeu melhor uma vez” de “temos uma forma definida de checar se o comportamento esperado foi atingido”.

Para equipes que ainda estão estruturando qualidade em produtos com IA, a discussão também se conecta ao diagnóstico de maturidade em IA. Maturidade, aqui, não exige modelo próprio nem uma arquitetura sofisticada. Exige capacidade de observar, registrar, decidir e revisar com consistência.

Teste se o registro permite reconstituir a falha

Exemplo fictício: uma empresa usa um assistente interno para responder dúvidas sobre políticas administrativas. Em uma simulação de atendimento, uma pessoa pergunta: “Qual é o prazo para pedir reembolso de viagem?”. O assistente responde que o prazo é de 30 dias. A política interna atual usada como referência diz que o prazo é de 15 dias.

Um registro ruim seria:

“O assistente deu uma resposta errada sobre reembolso porque a base estava desatualizada. Vamos atualizar a base e monitorar.”

Esse registro parece objetivo, mas mistura as três camadas. Ele descreve parcialmente o evento, crava uma causa sem evidência suficiente e propõe uma ação sem critério de verificação.

Uma versão melhor separa as camadas.

Evento:

“Em uma simulação de atendimento, o assistente informou que reembolsos de viagem poderiam ser solicitados em até 30 dias. O critério atual da política interna usada como referência é 15 dias. A resposta apareceu após a pergunta: ‘Qual é o prazo para pedir reembolso de viagem?’. A evidência disponível é a transcrição da simulação e o documento atual da política.”

Causa possível:

“Hipótese principal: o mecanismo de recuperação trouxe uma versão antiga da política. Hipótese alternativa: a instrução do assistente não priorizou documentos mais recentes quando havia conflito entre versões. Evidência necessária: identificar quais documentos foram recuperados naquela execução e se havia metadado de vigência disponível.”

Ação verificável:

“Revisar o conjunto de documentos usado na recuperação, remover versões obsoletas ou marcar vigência, e repetir um caso de avaliação com perguntas sobre prazos de reembolso. A ação só será considerada efetiva nesse caso se o assistente responder com 15 dias no caso avaliado e não usar políticas antigas quando houver documento vigente em conflito.”

Observe que o exemplo não afirma que a correção eliminaria falhas futuras. Ele cria uma forma de medir se aquela hipótese ganhou força e se a ação mudou o comportamento no caso relevante.

Esse é o objetivo da análise de falhas de IA: reduzir recorrência por investigação e verificação melhores, não prometer prevenção total.

Defina quando a falha exige contenção, correção ou apenas observação

Nem toda falha pede o mesmo nível de resposta. Algumas exigem contenção imediata. Outras pedem correção planejada. Outras podem ser apenas observadas, desde que registradas de modo suficiente para identificar repetição.

A decisão deve considerar critérios concretos:

impacto no usuário ou na operação;
possibilidade de repetição;
autonomia da IA para agir sem revisão humana;
reversibilidade da ação;
exposição externa;
sensibilidade do contexto;
existência de verificador confiável;
clareza sobre o comportamento esperado.

Se uma IA apenas sugere uma resposta interna de baixo impacto, a equipe pode registrar a falha, ajustar o caso de avaliação e revisar depois. Se um agente executa ações em sistemas, muda dados ou envia comunicações externas, a contenção pode vir antes da investigação completa.

Aqui é útil distinguir disponibilizar código de ativar funcionalidade. O capítulo de Google SRE sobre lançamentos graduais trata da avaliação de mudanças em uma parcela do tráfego antes de ampliar exposição e discute o uso de configurações para separar disponibilização e ativação. Em produtos com IA, essa separação pode ajudar a reduzir exposição enquanto a equipe investiga uma falha.

Documentar bem não substitui decisão operacional. Se o risco é relevante, a liderança precisa decidir se pausa, limita, reverte, reduz autonomia ou mantém a funcionalidade sob observação.

Sem mecanismos para interromper, verificar e aprender, a confiança fica apoiada em relato, não em controle operacional.

Revise a falha depois da correção, não apenas a tarefa

Uma tarefa fechada não prova que a falha deixou de se repetir. Ela prova apenas que alguém marcou uma atividade como concluída.

Depois da correção, a equipe deve voltar ao registro original e perguntar:

o evento foi reconstituído com evidência suficiente?
a hipótese principal foi confirmada, descartada ou segue incerta?
hipóteses alternativas continuam plausíveis?
o caso de avaliação foi repetido?
o comportamento esperado apareceu no verificador definido?
houve novas ocorrências semelhantes?
a documentação gerou mudança em critério de aceite, teste, instrução, base, interface ou decisão de autonomia?

Essa revisão evita um problema comum: transformar análise de falhas em burocracia. O valor não está em preencher campos. Está em melhorar a capacidade da organização de reconhecer padrões, testar hipóteses e ajustar o sistema com menos improviso.

Também vale separar falhas isoladas de sinais recorrentes. Uma ocorrência de baixo impacto pode não justificar uma investigação longa. Mas várias ocorrências parecidas, ainda que pequenas, podem indicar uma lacuna de critério, um verificador fraco ou uma decisão de produto mal delimitada.

O aprendizado operacional aparece quando a falha muda alguma coisa verificável no sistema de qualidade. Pode ser um novo caso de avaliação, uma instrução mais precisa, um limite de autonomia, uma regra de vigência de documentos, uma melhoria de interface ou uma decisão de contenção.

Registro de falha de IA em três camadas:

Evento: outra pessoa consegue reconstituir o que aconteceu sem depender da memória de quem relatou? O registro inclui entrada, saída ou ação, comportamento esperado, contexto, evidência e impacto observado?
Causa possível: a explicação está escrita como hipótese testável? Há hipótese principal, alternativas, evidência disponível, evidência ausente e condição de confirmação ou descarte?
Ação verificável: a mudança permite saber depois se o risco de recorrência diminuiu? Há responsável, momento de revisão, forma de checagem e decisão caso a falha reapareça?

Em cada registro de falha de IA, as três camadas precisam aparecer sem atalho: evento comprovável, causa possível e ação verificável. Sem isso, a organização pode até corrigir uma ocorrência. Mas aprende menos do que deveria.

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

Leituras para continuar

Fontes

Para continuar esta leitura

Como revisar o sistema de qualidade de uma equipe com 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.