Plano de resposta a incidentes de agentes de IA: severidade e rollback

Um plano de resposta a incidentes de agentes de IA é um runbook curto e escrito que define o que conta como falha, qual é a gravidade dela, quem age primeiro e como conter e reverter o dano. Para um agente de negócio que envia uma mensagem errada ou executa uma ação errada, o plano deve definir quatro níveis de severidade, atribuir donos antes que algo quebre e listar os passos de rollback na ordem em que precisam ser executados. As seções abaixo trazem uma versão de trabalho que você pode adaptar esta semana.

Principais pontos

• Escreva o runbook antes do primeiro incidente, enquanto ninguém está sob pressão para improvisar.
• Classifique as falhas pelo impacto no cliente e pela possibilidade de reversão, não pelo grau de sofisticação da causa técnica.
• Nomeie um responsável pelo incidente e um aprovador separado para correções enviadas para fora, para que ninguém espere por uma decisão que não tem dono.
• Contenha primeiro, pausando o canal de saída ou removendo a permissão de escrita, e só depois investigue.
• Ensaie o rollback com casos de teste e restaure a autonomia do agente somente após uma revisão documentada.

O que conta como incidente de agente

Um incidente de agente é qualquer evento em que um agente de IA produz um efeito que a empresa não pretendia e não pode ignorar. As formas mais comuns são uma mensagem errada enviada a cliente, fornecedor ou funcionário, uma alteração errada em um sistema do negócio, como pedido, agendamento, campo de preço ou reembolso, e uma chamada de ferramenta que alcança dados ou ações fora dos limites de aprovação do agente. O OWASP Top 10 para aplicações com LLM agrupa o último caso sob excesso de autonomia, o que é um rótulo útil, pois aponta para as permissões como raiz da maior parte dos incidentes graves.

Quase-incidentes também fazem parte do mesmo processo. Se um revisor pega um rascunho antes de ele sair da caixa de envio, ou se uma etapa de aprovação bloqueia uma ação, registre o caso. Esses eventos custam pouco para tratar e mostram quais verificações estão funcionando. Eles também viram casos de teste no futuro.

Quatro níveis de severidade

A severidade deve descrever o que aconteceu com pessoas e com dinheiro, não o esforço necessário para corrigir. Quatro níveis bastam para a maioria das operações pequenas e médias:

• Severidade 1: uma parte externa foi prejudicada ou uma ação irreversível foi executada. Exemplos incluem um pagamento enviado, dados pessoais expostos, um compromisso jurídico ou de segurança assumido ou um aviso regulatório enviado. O responsável pelo incidente contém o agente imediatamente e informa um líder sênior na mesma hora.
• Severidade 2: uma mensagem ou ação errada chegou a um ou mais clientes ou fornecedores e ainda pode ser corrigida. Exemplos incluem uma janela de entrega errada, um preço errado informado ou um agendamento alterado sem consentimento. A contenção acontece na mesma sessão de trabalho, e as correções são aprovadas antes de sair.
• Severidade 3: um erro interno ou uma única mensagem externa com efeito pequeno, percebida pela equipe depois que aconteceu. Exemplos incluem um status errado em um registro interno ou uma resposta com nome de produto grafado errado que o cliente não usou. Corrija no mesmo dia e registre a causa.
• Severidade 4: um quase-incidente barrado por uma verificação, um revisor ou uma etapa de aprovação. Registre, anexe a entrada e a saída e inclua o caso no conjunto de avaliação.

Quando o nível não estiver claro, escolha o mais alto. Você pode rebaixar depois, com uma justificativa escrita, mas um incidente subclassificado no início costuma receber menos atenção do que merece.

Defina os donos antes do primeiro incidente

Um runbook de incidentes costuma falhar na primeira decisão, quando alguém pergunta quem pode pausar o agente. Escreva a resposta com antecedência. Uma equipe pequena pode acumular papéis em uma mesma pessoa, mas cada papel ainda precisa de um titular nomeado e de um substituto.

• Responsável pelo incidente: o líder de operações que decide sobre contenção, mudanças de severidade e comunicação interna. Essa pessoa tem autoridade para pausar o agente sem aprovação adicional.
• Dono do agente: o líder de negócio do processo que o agente apoia. Essa pessoa julga se uma saída estava errada e qual deveria ter sido o resultado correto.
• Operador técnico: quem mantém as ferramentas, as credenciais e as integrações do agente. Essa pessoa executa o rollback e confirma que as permissões foram de fato removidas.
• Aprovador de comunicação externa: quem assina qualquer correção enviada a clientes ou fornecedores. Mantenha essa pessoa separada do dono do agente, para que as correções sejam revisadas por alguém com outra visão.
• Contato de operação gerenciada: quando um provedor opera o agente em regime gerenciado, o líder de operações do provedor entra aqui com o caminho de escalonamento, para que o runbook cubra os dois lados da passagem de responsabilidade.

Defina também a regra de escalonamento para cada nível. O guia de escalonamento humano para falhas de agentes de IA mostra como enviar a decisão necessária a uma pessoa, em vez de um histórico confuso de conversa, o que economiza tempo quando uma ocorrência de severidade 1 acontece em horário inconveniente.

Contenha primeiro, investigue depois

A contenção é o único passo que precisa acontecer antes do entendimento. O objetivo é impedir novos danos enquanto os fatos ainda estão sendo levantados. Siga estes passos nesta ordem:

• Pause o canal de saída do agente. Faça isso mesmo quando a causa ainda não for conhecida, já que um agente pausado pode voltar em minutos, mas um agente que continua ativo pode enviar mais mensagens erradas nesse intervalo.
• Remova a permissão de escrita da ferramenta ou do sistema afetado. Revogue ou troque a credencial se o agente puder ter sido usado indevidamente, e registre o horário de cada mudança.
• Abra o registro do incidente com data e hora, severidade, versão do agente, versão do prompt ou da configuração em vigor e o nome do responsável pelo incidente.
• Preserve as evidências. Exporte as entradas, as chamadas de ferramenta, as saídas e os registros de aprovação do período afetado. Não edite nem apague os registros originais e não confie apenas no resumo que o próprio agente faz do que executou.
• Avise internamente quem precisa saber, incluindo o dono do agente e o aprovador de comunicação externa, usando o mesmo registro do incidente para que ninguém trabalhe com uma versão diferente dos fatos.

Não reinicie o agente durante a contenção para ver se o problema volta. Um reinício altera o estado que você está tentando examinar.

Faça rollback e correção, passo a passo

O rollback devolve o negócio ao estado em que ele deveria estar, e a correção informa às partes afetadas o que de fato aconteceu. São tarefas diferentes, com donos diferentes. Depois que a contenção estiver feita, siga esta sequência.

• Dimensione o dano. Use os identificadores de ação e a janela de tempo dos registros para listar cada mensagem, registro e transação afetados. Uma lista feita de memória deixa itens de fora.
• Reverta as ações reversíveis. Restaure os valores anteriores dos campos, cancele o agendamento indevido ou devolva-o à data original e confira cada reversão com o registro original.
• Verifique duplicidades. Se o agente repetiu uma escrita, confirme que o sistema processou apenas uma vez. Provedores como a Stripe descrevem chaves de idempotência justamente para isso, e o guia sobre ações idempotentes em agentes de IA explica como desenhar ações para que uma repetição não gere um segundo reembolso.
• Redija as correções para as partes afetadas. O aprovador de comunicação externa escreve ou aprova cada mensagem manualmente. A correção deve dizer o que estava errado, o que está certo agora e o que o destinatário precisa fazer, se houver algo.
• Restaure a configuração ou a versão anterior do modelo somente depois de compará-las em um ambiente de teste. Não presuma que a versão anterior era segura.
• Mantenha o agente em modo de sombra após a restauração. Ele redige as ações, uma pessoa as revisa e a autonomia volta por etapas.

Cenário ilustrativo: um agente que confirma janelas de entrega para clientes passa a enviar a janela da semana anterior depois de uma mudança em um modelo de mensagem. A contenção pausa as mensagens de saída em menos de uma hora. O dimensionamento usa o log de mensagens para localizar cada confirmação enviada desde a mudança. O aprovador de comunicação externa envia uma correção curta para cada cliente afetado, o operador técnico reverte o modelo, e o dono do agente confere três entregas de amostra antes de o agente voltar ao modo de sombra.

Revise, reabra a autonomia e mantenha o runbook vivo

A revisão deve responder por escrito a quatro perguntas: o que aconteceu, por que as verificações não barraram o problema, qual permissão ou limite deve mudar e qual caso de teste passa a cobrir a falha. Mantenha a revisão sem culpar pessoas, mas específica sobre o sistema. Se o agente tinha permissão para enviar sem uma segunda checagem, a correção costuma ser uma permissão mais restrita, e não um alerta para a equipe.

Reabrir a autonomia é uma decisão, não um prazo. O responsável pelo incidente e o dono do agente combinam quais evidências mostram que a falha foi corrigida, geralmente um conjunto de casos reexecutados que agora passam, e o agente volta à operação supervisionada antes de voltar à autonomia plena. O NIST AI Risk Management Framework é uma referência útil para enquadrar esse trabalho em governança, mensuração e gestão, e não em uma correção pontual. Para as notas operacionais que devem continuar atualizadas depois da revisão, veja o guia de documentação de operação com runbook para agentes de IA.

A Be Human define esses limites como parte de um primeiro projeto, descrevendo memória, ferramentas, canais e etapas de aprovação do agente, e pode executar monitoramento, avaliações recorrentes, revisões de permissão e resposta a incidentes como operação gerenciada. O papel do provedor é manter o runbook atualizado conforme o agente muda, não tirar da empresa a decisão. Se você quer saber qual tarefa é a melhor primeira candidata para um agente com esses controles, faça o diagnóstico gratuito de IA da Be Human para identificar a primeira tarefa que vale entregar a um agente.

Perguntas frequentes

Em que um incidente com agente de IA é diferente de um bug comum de software? Um agente pode produzir uma saída errada que parece correta, e pode executar várias ações em sequência antes que alguém perceba. Por isso, o runbook precisa cobrir mensagens e decisões, além do código, e depender de registros de entradas, chamadas de ferramenta e aprovações. A contenção geralmente significa pausar a autoridade do agente, e não reverter uma versão de software.

Devemos desligar o agente inteiro durante um incidente? Não necessariamente. Pause o canal de saída e remova a permissão de escrita da ferramenta afetada, o que interrompe novos danos e mantém o acesso de leitura para a investigação. Um desligamento completo se justifica quando a falha afeta todos os fluxos que o agente executa, ou quando a causa é desconhecida e o agente consegue acessar dados sensíveis.

Quem pode reiniciar um agente depois de um incidente de severidade 1? A decisão cabe ao responsável pelo incidente, com base em uma revisão escrita e em casos de teste reexecutados que mostrem que a falha foi corrigida. O dono do agente confirma que o resultado de negócio está correto, e o operador técnico confirma que as permissões estão como previsto. Reinicie primeiro em modo de sombra e depois restaure a autonomia por etapas.

Precisamos avisar clientes quando um agente envia uma mensagem errada? Se a mensagem afetou uma decisão, uma entrega, um pagamento ou um compromisso, quase sempre é preciso corrigir, e a correção deve ser escrita e enviada por uma pessoa. Seja breve, diga o que estava errado e o que está certo agora e informe ao destinatário o que fazer, se houver algo. Registre cada correção no arquivo do incidente para que a equipe possa comprovar o que foi enviado e quando.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.