Resposta a incidentes com agentes de IA: um guia prático

Para responder a um incidente com agente de IA, interrompa primeiro a ação que está causando dano, avise em seguida as pessoas responsáveis pelo trabalho afetado, preserve as evidências e só depois diagnostique e corrija. Mantenha esta ordem: conter, avisar, preservar, diagnosticar, corrigir, revisar. O objetivo é limitar o prejuízo rapidamente e deixar a empresa com um sistema alterado, não apenas com um pedido de desculpas discreto.

Principais pontos

• Contenha antes de investigar. Suspenda a capacidade de o agente agir, e não necessariamente o sistema inteiro, para que o problema pare de crescer enquanto você analisa.
• Nomeie um único responsável pelo incidente. Responsabilidade compartilhada durante uma crise costuma significar que ninguém decide.
• Comunique em camadas: quem precisa agir agora, quem foi afetado pelo erro e quem precisa saber depois. Cada grupo precisa de uma informação diferente.
• Registre os fatos enquanto estão frescos: o que o agente fez, o que ele viu, quem aprovou e o que foi desfeito.
• Encerre todo incidente com uma revisão que mude algo concreto: uma permissão, um teste, uma regra ou um item de memória.

O que conta como incidente com agente de IA?

Incidente é toda vez que um agente executa ou prepara uma ação que a empresa não pretendia e que tem, ou poderia ter, efeito real sobre um cliente, um registro, dinheiro ou um compromisso. Uma resposta errada em um rascunho que uma pessoa corrigiu é um problema de qualidade. A mesma resposta errada enviada a um cliente é um incidente.

Vale combinar categorias antes de qualquer problema, porque sob pressão as pessoas discutem rótulos em vez de agir. Um conjunto funcional é este:

• Ação errada: o agente fez algo que tinha permissão para fazer, mas no caso errado (um reembolso para a conta errada, uma mensagem para o contato errado).
• Ação fora dos limites: o agente fez algo que nunca deveria ter conseguido fazer, o que aponta para um problema de permissão.
• Informação errada: o agente afirmou algo falso ou desatualizado a uma pessoa de fora da equipe.
• Exposição de dados: o agente revelou, copiou ou armazenou informações em um lugar indevido.
• Manipulação: um texto dentro de um documento, e-mail ou página da web desviou o agente de suas instruções. A lista OWASP Top 10 para aplicações com LLMs descreve esse risco e outros relacionados, e serve como vocabulário útil para a revisão.
• Falha silenciosa: o agente parou de fazer o trabalho e ninguém percebeu.

Você não precisa de uma taxonomia longa. Precisa de categorias suficientes para que a pessoa de plantão diga a qual delas o caso se parece, porque a categoria define quem será acionado.

O que fazer nos primeiros minutos?

Os primeiros minutos são para conter o problema, e conter é mais restrito do que parece. Você não está tentando entender o incidente. Está tentando garantir que ele não gere uma segunda, uma terceira ou uma décima ocorrência enquanto você trabalha.

Um roteiro que a pessoa de plantão consegue seguir sem precisar pensar muito:

• Interrompa o caminho da ação. Desative a ferramenta, o canal ou a permissão específica que o agente usou. Pausar o envio de e-mails é melhor do que desligar tudo se o dano veio do e-mail.
• Pare o trabalho em fila. Verifique envios agendados, aprovações pendentes e novas tentativas que dispararão mais tarde. Um agente pausado com a fila cheia ainda pode causar dano.
• Não apague nada. Logs, histórico de conversas, itens de memória e resultados de ferramentas são suas evidências. Deixe tudo como está.
• Anote o horário e quem tomou a decisão. Registre quando e como a contenção foi feita, mesmo que seja numa mensagem rápida para você mesmo.
• Defina o responsável pelo incidente. Uma pessoa decide o que acontece a seguir e quem será avisado. Os demais apoiam.
• Verifique se o mesmo padrão ocorre em outros lugares. Se um cliente recebeu uma mensagem errada, procure outros no mesmo lote antes de presumir que foi um caso isolado.

Se o agente pode ser parado rapidamente é algo decidido, em grande parte, muito antes do incidente. Se a única forma de pausá-lo é pedir à pessoa que o construiu, o desenho tem uma lacuna. Um agente deve ter um interruptor documentado para cada canal e ferramenta, e alguém na empresa autorizado a usá-lo sem pedir licença.

É também aqui que o menor privilégio compensa na prática. Um agente que só podia redigir, ou só mexer em uma pasta, limita o que há para conter. Um agente com acesso amplo transforma cada incidente em uma busca extensa. As orientações de autorização da OWASP dizem o mesmo para software em geral: conceda o mínimo necessário e verifique a cada requisição.

Quem precisa ser avisado e o que precisa ouvir?

A comunicação falha de duas formas: poucas pessoas ficam sabendo cedo, ou todos recebem a mesma mensagem longa e ninguém sabe o que é seu para fazer. Trabalhe em camadas e dê a cada uma só o que ela precisa.

Quem age agora. São o dono do processo afetado, quem pode reverter a ação e quem gerencia o acesso do agente. Avise essas pessoas diretamente, não por um canal geral. A mensagem deve dizer o que aconteceu, o que já foi contido, o que você precisa delas e quando haverá a próxima atualização. É o mesmo princípio do escalonamento humano em falhas de agentes de IA: envie a decisão, não a bagunça.

Quem foi afetado. Se um cliente, candidato, paciente, aluno ou fornecedor recebeu algo errado ou teve dados expostos, alguém precisa entrar em contato. Esse contato deve vir de uma pessoa, ser claro sobre o que aconteceu, dizer o que está sendo feito e não especular sobre a causa. Se houver dúvida, diga que os detalhes ainda estão sendo confirmados e que você retornará. Não espere a investigação completa para enviar uma primeira mensagem curta.

Liderança e áreas jurídica ou de compliance. Tudo que envolva dados pessoais, compromisso contratual, atividade regulada ou efeito financeiro deve chegar rapidamente a quem responde por essas áreas. Se existe obrigação formal de notificação depende do seu setor e da legislação aplicável, e essa é uma pergunta para elas, não para quem conduz a resposta técnica. Referências como o NIST AI Risk Management Framework ajudam a estruturar quem responde pela gestão do risco de IA desde o início.

O restante da equipe. Colegas que trabalham ao lado do agente precisam saber o que está pausado, o que fazer no lugar e o que não repetir. Duas linhas bastam: o agente não está cuidando de X agora, faça manualmente e envie dúvidas ao responsável pelo incidente.

Evite um erro comum: culpar o modelo na primeira mensagem. Afirmações iniciais sobre a causa costumam estar erradas e moldam a forma como as pessoas pensam na correção. Descreva o efeito, não a explicação.

O que registrar enquanto tudo está fresco?

Um bom registro de incidente é escrito durante a resposta, não reconstruído uma semana depois. Não precisa ser elaborado. Precisa ser completo o bastante para que alguém que não estava presente entenda o que aconteceu e por que você decidiu como decidiu.

Registre estes itens:

• Linha do tempo: quando a ação errada ocorreu, quando foi percebida, quem percebeu, quando foi contida e quando as pessoas afetadas foram avisadas.
• A ação em si: o que o agente fez, em qual sistema, sobre quais registros ou pessoas, e o resultado ou a mensagem exata, quando relevante.
• Contexto na hora: a instrução que ele seguia, os documentos ou a memória em que se apoiou, as ferramentas que chamou e a versão da configuração ou do modelo em uso.
• Autoridade: se uma pessoa aprovou a ação, se ela estava dentro das permissões do agente e quem definiu essas permissões.
• Impacto: quem ou o que foi afetado, se é reversível e o que já foi revertido.
• Decisões: o que você escolheu fazer e por quê, incluindo o que escolheu não fazer.

A maior parte dos itens de contexto só estará disponível se você registrar as coisas certas com antecedência. Isso significa guardar chamadas de ferramentas, entradas, saídas e decisões em um formato pesquisável. A introdução à observabilidade do OpenTelemetry explica a ideia de reconstruir o que um sistema fez a partir de traces, logs e métricas, e nosso artigo sobre o que registrar na observabilidade de agentes de IA cobre os detalhes específicos de agentes. Se a evidência de que você precisa nunca foi registrada, diga isso no relatório do incidente. Essa lacuna já é uma conclusão.

Faça uma cópia da memória e da configuração do agente no momento do incidente, antes de qualquer edição. As correções posteriores vão mudar o estado, e você vai querer comparar.

Como encontrar a causa sem adivinhar?

Quando a situação estiver estável, diagnostique. A tentação é escolher a primeira explicação plausível e aplicar um remendo. Resista. Percorra as camadas em ordem, da mais barata de verificar à mais difícil.

• Instrução: ela era ambígua, deixava um caso de fora ou entrava em conflito com outra? Muitos incidentes são uma lacuna no procedimento escrito.
• Informação: o agente leu algo desatualizado, errado ou irrelevante? Memória antiga e documentos conflitantes são causas frequentes. Veja como evitar que contexto antigo engane seu agente de IA e a importância de dar ao agente uma fonte de verdade confiável.
• Entrada: uma mensagem ou documento continha texto que redirecionou o agente? Trate tudo que vem de fora da empresa como potencialmente hostil.
• Permissão: o agente deveria conseguir executar essa ação? Se não, a correção está no acesso, não na redação.
• Aprovação: uma checagem humana deveria ter ocorrido, e ocorreu? Uma etapa de revisão em que as pessoas apenas clicam em aprovar não é um controle.
• Ferramenta: alguma ferramenta devolveu algo inesperado, falhou no meio do caminho ou rodou duas vezes? Ações repetidas após erros são tratadas em política de repetição para agentes de IA sem duplicidades.
• Mudança de modelo ou configuração: algo mudou recentemente? Atualizações podem alterar o comportamento sem que ninguém toque nas instruções.

Tente reproduzir a falha em um ambiente seguro, usando o contexto registrado. Se conseguir reproduzir, você pode confirmar a correção. Se não conseguir, diga isso com honestidade no registro, trate a causa como não confirmada e acrescente monitoramento para detectar uma recorrência.

Corrija nesta ordem: reverta o dano a pessoas e registros, corrija a causa, adicione um teste que teria pegado o problema e só então devolva a autoridade ao agente. Ao devolvê-la, faça isso de forma gradual. Comece apenas com rascunhos ou com aprovação obrigatória e amplie de novo quando o comportamento se mostrar correto.

O que a revisão posterior precisa mudar?

Uma revisão que termina em "vamos ter mais cuidado" não mudou nada. Faça uma revisão curta e sem busca por culpados, em prazo razoável após o encerramento do incidente, com quem conduziu a resposta e o dono do processo. Faça quatro perguntas: o que aconteceu, por que nossos controles não impediram, como descobrimos e o que será diferente da próxima vez.

Depois exija ao menos uma mudança concreta desta lista:

• Uma permissão reduzida ou removida.
• Uma etapa de aprovação adicionada, ou uma já existente tornada realmente efetiva.
• Um novo caso incluído no seu conjunto de testes de referência, para que a mesma falha seja verificada a cada mudança futura.
• Uma instrução ou um procedimento esclarecido.
• Um item de memória corrigido, ou um documento de origem ajustado.
• Um novo alerta para um sinal que passou despercebido.
• Uma linha no runbook de operação, para que a próxima pessoa de plantão saiba o que fazer.

Dê a cada mudança um responsável e uma data para conferir se foi feita. Decida também se o incidente altera o escopo do agente. Às vezes o resultado certo é que uma tarefa volte para as pessoas por enquanto. Isso é um resultado legítimo, não um fracasso do projeto.

Um cenário ilustrativo

Este é um exemplo ilustrativo, não um caso real. Uma empresa de serviços usa um agente para enviar avisos de remarcação de atendimentos. Numa manhã, um colaborador percebe que vários clientes receberam avisos de atendimentos que não estavam mudando.

A gerente de plantão, nomeada responsável pelo incidente em poucos minutos, desativa a ferramenta de envio de e-mails do agente e esvazia a fila de avisos agendados. Ela deixa os logs e a memória do agente intactos. Envia uma mensagem direta ao líder de operações e à pessoa que cuida do relacionamento com clientes, dizendo o que aconteceu e o que está pausado. Uma correção curta e objetiva segue para os clientes afetados, assinada por uma pessoa identificada da empresa.

O registro mostra que o agente cruzou os clientes com uma exportação da agenda gerada de novo com linhas deslocadas, ou seja, lia um mapeamento desatualizado. Não havia etapa de aprovação para avisos em lote. As correções: o agente passa a ler a agenda em tempo real, envios em lote exigem que uma pessoa aprove uma amostra, um caso de teste reproduz a exportação deslocada e a empresa adiciona um alerta para volume de envio fora do normal. O agente volta ao trabalho primeiro em modo rascunho e recupera o direito de enviar depois de se comportar corretamente na revisão.

Como uma operação gerenciada lida com isso?

A Be Human projeta e opera agentes pensando em resposta a incidentes desde o início. Cada agente tem permissões definidas, limites de aprovação e uma forma documentada de pausar ferramentas ou canais individualmente. O registro é configurado para que ações, entradas e decisões possam ser revisadas depois. Na operação gerenciada, a Be Human pode apoiar o monitoramento, a resposta a incidentes, a revisão de permissões e melhorias controladas, enquanto o cliente mantém a autoridade de decidir o que o agente pode fazer e quando ele volta a operar. As conclusões de um incidente voltam para testes, instruções e para o runbook, e as verificações semanais descritas no nosso checklist de manutenção de agentes de IA buscam os mesmos pontos fracos.

Perguntas frequentes

Devemos desligar o agente inteiro quando algo dá errado? Em geral, não. Desative a ferramenta, o canal ou a permissão específica envolvida e pare o trabalho em fila, para que o problema cesse sem perder as partes que funcionam. Desligue tudo apenas se você não souber o que o agente alcança ou se a causa for incerta e o risco, alto.

Quem deve ser o dono de um incidente com agente de IA? Uma pessoa nomeada, com autoridade para pausar o agente, contatar os afetados e chamar ajuda. Costuma ser o dono do processo de negócio que o agente apoia, com respaldo de quem cuida da parte técnica. Sem um responsável único, as decisões travam.

Precisamos avisar os clientes toda vez que um agente erra? Nem todo erro. Se uma pessoa o pegou antes de chegar a alguém, um registro interno basta. Se chegou a um cliente, expôs dados pessoais ou criou um compromisso, uma pessoa deve entrar em contato logo e com clareza, e o contato jurídico ou de compliance deve decidir sobre eventuais obrigações formais.

Como nos preparar antes de um incidente? Escreva quem pode pausar o agente e como, mantenha logs detalhados o bastante para reconstruir as ações, limite as permissões ao que a tarefa exige e faça um simulado para que a primeira resposta real não seja a primeira tentativa. Revise o plano sempre que o agente ganhar uma nova ferramenta ou canal.

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