Post-mortem de incidente com agente de IA: guia

Encerrar o incidente não encerra o risco

Um agente atualiza a conta errada no CRM. A equipe percebe, bloqueia novas escritas, corrige o registro e restabelece o serviço. O incidente parece resolvido.

Duas semanas depois, outra atualização incorreta acontece pelo mesmo caminho. O nome do cliente era parecido, a validação de identidade continuava permissiva e o alerta dependia de alguém notar a consequência.

A primeira resposta corrigiu o caso. Faltou corrigir o sistema que tornou o caso possível.

O post-mortem de um incidente com agente de IA é a revisão estruturada feita depois da estabilização. Ele reconstrói o evento, separa causas de sintomas, examina as barreiras que falharam e transforma o aprendizado em mudanças verificáveis.

Esse trabalho protege a capacidade operacional. Sem ele, a empresa acumula correções pontuais, controles decorativos e uma confiança que não corresponde ao risco real.

Quando fazer um post-mortem

Nem toda saída ruim exige uma investigação formal. A profundidade deve acompanhar consequência, alcance e valor do aprendizado.

Conduza um post-mortem quando houver:

impacto em cliente, dinheiro, dado, contrato ou reputação;
falha de um controle considerado confiável;
ação externa sem autorização ou confirmação;
repetição, propagação ou potencial de atingir muitos casos;
interrupção relevante do processo;
mistura de identidade, cliente ou escopo;
quase incidente que revelou uma passagem perigosa;
dificuldade para reconstruir o que o agente fez;
recorrência de uma classe de erro já conhecida;
retomada autorizada com riscos ainda pendentes.

Erros comuns e reversíveis podem seguir para a rotina de qualidade. Incidentes relevantes e quase incidentes com alto potencial merecem uma revisão que envolva processo, tecnologia e governança.

O plano de resposta a incidentes de IA organiza detecção, contenção, correção e retomada. O post-mortem começa quando o serviço está estável o suficiente para investigar sem disputar atenção com a resposta imediata.

Defina o objetivo antes da reunião

A revisão existe para reduzir a probabilidade ou o impacto de recorrência. Ela não deve servir para encontrar uma narrativa elegante, defender uma equipe ou localizar um culpado conveniente.

O objetivo pode ser expresso em quatro perguntas:

O que ocorreu e qual foi o impacto confirmado?
Que combinação de condições permitiu o evento?
Quais barreiras deveriam ter impedido, detectado ou limitado a consequência?
Que mudanças serão feitas, por quem e com qual evidência de conclusão?

Essas perguntas evitam que a conversa fique presa ao texto produzido pelo modelo. Um incidente com agente costuma atravessar identidade, dados, fontes, instruções, ferramentas, permissões, filas, aprovação e monitoramento. A causa raramente cabe em “a IA errou”.

Preserve fatos antes que a operação siga adiante

Sistemas mudam rápido depois de uma falha. Prompts são editados, credenciais são revogadas, filas são limpas e registros recebem correção manual. Se a evidência não for preservada, a versão investigada desaparece.

Reúna, com acesso controlado:

horário do primeiro evento e da detecção;
unidade de trabalho afetada;
entrada e origem autorizada;
versão do agente, modelo, instruções e workflow;
fontes consultadas e suas versões;
ferramentas chamadas e argumentos validados;
identidade técnica e permissões vigentes;
eventos de fila, tentativas e timeouts;
saídas estruturadas e validações;
aprovações humanas;
efeitos confirmados nos sistemas de destino;
alertas emitidos ou ausentes;
mudanças feitas durante contenção e recuperação;
comunicação para públicos afetados.

Use referências e identificadores quando o conteúdo completo estiver no sistema oficial. O tracing de agentes de IA permite conectar eventos da mesma unidade sem transformar a ferramenta de observabilidade em um repositório paralelo de dados sensíveis.

Construa uma linha do tempo verificável

A linha do tempo reduz interpretações prematuras. Registre eventos observáveis em sequência, com horário, fonte e responsável pela ação.

Uma estrutura prática inclui:

| Momento | Evento | Evidência | Estado conhecido | Decisão | |---|---|---|---|---| | entrada | unidade recebida | ID do evento | cliente ainda não validado | iniciar identificação | | execução | histórico recuperado | trace da consulta | duas contas semelhantes | agente escolheu uma conta | | consequência | CRM atualizado | ID da gravação | registro incorreto | caso marcado como concluído | | detecção | vendedor reportou divergência | chamado interno | alcance desconhecido | bloquear escrita | | contenção | ferramenta revogada | log de política | novas ações interrompidas | investigar lote | | recuperação | registros corrigidos | relatório de reconciliação | impacto tratado | retomar em modo assistido |

Não preencha lacunas com uma explicação plausível. Marque o que permanece desconhecido e defina como confirmar. Uma cronologia honesta com lacunas é mais útil do que uma história perfeita sustentada por suposições.

Separe impacto confirmado de impacto potencial

O post-mortem deve declarar o que realmente aconteceu.

Meça, quando aplicável:

pessoas, clientes ou registros afetados;
período de exposição;
ações executadas;
valores, prazos ou compromissos envolvidos;
trabalho interrompido;
horas de contenção e correção;
backlog criado;
retrabalho interno;
comunicações necessárias;
obrigações contratuais ou regulatórias avaliadas.

Depois, registre o impacto potencial que foi contido. Um agente tentou usar uma ferramenta financeira, mas a política bloqueou a ação. Não houve movimentação, porém a tentativa revela uma condição relevante.

Manter as duas categorias separadas melhora a priorização. Impacto confirmado orienta reparação. Potencial contido orienta fortalecimento das barreiras que impediram consequência maior.

Investigue em camadas

Uma boa análise procura causas contribuintes ao longo do sistema.

Processo

A unidade de trabalho estava definida?
A fonte da verdade era conhecida?
A exceção possuía dono?
A política cobria aquele caso?
O prazo pressionou alguém a contornar um controle?

Dados e contexto

A identidade estava confirmada?
Havia fontes conflitantes ou vencidas?
O contexto recuperado pertencia ao cliente e à versão corretos?
Informações obrigatórias estavam ausentes?

Comportamento do agente

A instrução delimitava opções e bloqueios?
A saída usada pela próxima etapa era estruturada?
O agente escalou sinais de incerteza?
A seleção de ferramenta respeitou a política?

Ferramentas e permissões

A credencial possuía escopo excessivo?
A ferramenta validava objeto, ação e alçada?
Existia confirmação do efeito no destino?
O controle podia ser contornado por outra rota?

Execução e resiliência

Retentativas distinguiram falha de estado incerto?
Idempotência impediu duplicidade?
Concorrência foi tratada?
Filas preservaram prioridade e identidade?

Supervisão e operação

A aprovação recebeu contexto suficiente?
Alertas chegaram a alguém com autoridade?
Havia capacidade para revisar a fila?
A equipe sabia como interromper a ação afetada?

Mudança e teste

Algum componente mudou antes do incidente?
A versão passou por regressão representativa?
O caso existia no conjunto de testes?
A implantação foi gradual e observada?

A investigação termina melhor quando identifica uma cadeia de condições, em vez de uma única causa abstrata.

Analise as barreiras que deveriam ter funcionado

Para cada etapa perigosa, liste as barreiras previstas e o que ocorreu.

| Barreira | Função esperada | Resultado | Motivo da falha | |---|---|---|---| | validação de identidade | impedir consulta na conta errada | não bloqueou | regra aceitou correspondência parcial | | saída estruturada | exigir ID confirmado | passou com campo ambíguo | esquema validava formato, mas não autoridade | | aprovação humana | conferir conta antes da escrita | aprovou sem perceber | pacote omitiu divergência entre fontes | | monitoramento | detectar alteração incompatível | alertou tarde | limiar observava falha técnica, não mudança de identidade | | limite de volume | conter propagação | funcionou | teto diário restringiu alcance |

Esse quadro mostra controles que falharam e controles que reduziram o dano. Preservar o que funcionou evita uma reação desordenada que redesenha tudo e perde mecanismos úteis.

O guia de guardrails para agentes de IA ajuda a distribuir barreiras entre entrada, contexto, ferramenta, confirmação e saída.

Evite explicações rasas

Algumas conclusões encerram a conversa cedo demais.

“O modelo alucinou”

A frase pode descrever o comportamento textual. Ainda falta explicar por que uma saída não verificada ganhou permissão para produzir consequência.

“O prompt estava ruim”

Uma instrução pode contribuir, mas controles importantes não deveriam depender apenas de obediência textual.

“Foi erro humano”

Pergunte que informação a pessoa recebeu, qual prazo enfrentou, que autoridade possuía e por que o processo permitia uma aprovação sem evidência suficiente.

“Foi um caso raro”

Raridade não reduz automaticamente o risco. Avalie consequência e capacidade de repetição.

“Já corrigimos”

Uma edição feita durante a contenção precisa virar versão, teste, aprovação e evidência. Mudança emergencial sem registro pode abrir outra falha.

Transforme achados em ações verificáveis

Ação útil altera uma condição observada e possui dono, prazo e critério de aceite.

Fraco:

melhorar o prompt;
revisar os logs;
treinar a equipe;
monitorar com atenção;
reforçar a segurança.

Operacional:

exigir correspondência exata entre tenant_id do evento, da fonte e da ferramenta antes de recuperar histórico;
bloquear escrita quando duas fontes oficiais divergem sobre a identidade;
incluir o caso do incidente e cinco variações no conjunto de regressão;
mostrar conta, ID, fonte e divergência no pedido de aprovação;
limitar a ferramenta ao conjunto de campos autorizado;
criar alerta para mudança de cliente entre spans do mesmo trace;
testar o kill switch e registrar tempo até confirmação de parada.

Para cada ação, registre:

achado relacionado;
risco reduzido;
responsável;
prazo;
dependências;
ambiente de validação;
evidência esperada;
resultado do teste;
data de revisão.

A tarefa só termina quando o controle foi implementado e testado. Criar um ticket transfere responsabilidade. Não prova redução do risco.

Priorize pela capacidade de prevenir e conter

Um post-mortem pode produzir dezenas de ideias. A lista inteira não merece a mesma urgência.

Priorize ações que:

interrompem recorrência imediata;
reduzem alcance de uma nova falha;
melhoram detecção antes da consequência;
tornam o estado e a identidade verificáveis;
corrigem a causa na origem;
aumentam qualidade da resposta futura;
removem dependência de memória ou improviso.

Considere impacto, frequência provável, facilidade de exploração, alcance, reversibilidade e tempo para aplicar o controle. Uma mudança pequena na validação da ferramenta pode oferecer proteção superior a uma longa reescrita de documentação.

Atualize a arquitetura operacional

O aprendizado precisa voltar aos artefatos que governam a execução.

Revise conforme o caso:

inventário do agente;
matriz de autonomia;
política de permissões;
contrato de dados;
fonte da verdade;
conjunto de testes;
instruções e skills;
catálogo de ferramentas;
alertas e painéis;
runbook de incidente;
plano de contingência;
critérios de mudança e retomada;
treinamento do dono do processo.

Se o post-mortem vive somente em uma pasta, a organização aprende no documento e repete na operação.

O controle de mudanças em agentes de IA deve governar a versão corretiva. Até uma correção urgente precisa ser reproduzível, comparada e acompanhada depois da publicação.

Verifique eficácia depois da correção

A ausência de novo incidente por alguns dias pode significar melhoria ou apenas falta de exposição ao cenário.

Verifique a correção com:

reprodução controlada do caso original;
variações de identidade, formato e ordem dos eventos;
teste de falha da barreira nova;
regressão dos casos que funcionavam antes;
execução em modo sombra;
implantação limitada;
amostragem reforçada;
monitoramento da classe afetada;
exercício do mecanismo de interrupção;
revisão do backlog de ações.

Defina a janela e o volume necessários para fechar cada ação. Controles de eventos raros também precisam de simulação periódica.

Estrutura recomendada para o documento

Um post-mortem executivo pode seguir esta ordem:

resumo do evento;
status atual;
impacto confirmado e potencial;
linha do tempo;
detecção e contenção;
causas contribuintes;
análise das barreiras;
controles que funcionaram;
fatores que ampliaram o impacto;
ações corretivas priorizadas;
responsáveis, prazos e evidências;
riscos residuais;
critérios de verificação;
aprendizados aplicáveis a outros agentes.

O documento deve ser compreensível pelo dono do processo e tecnicamente útil para quem implementará as mudanças. Detalhes sensíveis permanecem em anexos com acesso restrito.

Checklist do post-mortem

[ ] O serviço está estabilizado para permitir investigação?
[ ] Evidências foram preservadas antes de novas mudanças?
[ ] A linha do tempo separa fato, hipótese e lacuna?
[ ] Impacto confirmado e potencial estão distintos?
[ ] Processo, dados, agente, ferramentas e operação foram examinados?
[ ] Barreiras previstas foram avaliadas individualmente?
[ ] Controles que funcionaram também foram registrados?
[ ] A análise evitou culpar apenas modelo ou pessoa?
[ ] Cada ação possui dono, prazo e evidência de aceite?
[ ] Casos do incidente entraram na regressão?
[ ] A versão corretiva passou pelo controle de mudanças?
[ ] Riscos residuais estão explícitos?
[ ] A eficácia será verificada depois da implantação?
[ ] Aprendizados relevantes foram aplicados a sistemas semelhantes?

Aprendizado operacional precisa chegar ao sistema

Um incidente expõe a arquitetura real. Ele mostra quais fontes governam a decisão, quais permissões produzem consequência, onde a supervisão perde contexto e quanto tempo a empresa leva para perceber um desvio.

O post-mortem transforma essa exposição em melhoria. A linha do tempo organiza fatos. A análise encontra condições e barreiras. As ações alteram controles. A verificação confirma se o risco realmente diminuiu.

A maturidade aparece quando o aprendizado deixa o relatório e chega às versões, políticas, ferramentas, testes e rotinas que conduzem o trabalho. Corrigir o caso restaura o presente. Corrigir o sistema protege a próxima execução.