Quando o agente de IA para, sua operação sabe assumir?

Às 10h, o agente deixa de registrar cinco pedidos. Às 10h20, volta sozinho e envia dois deles em duplicidade. A equipe percebe a divergência ao meio-dia, desliga tudo e começa a conferir conversas, planilhas e ERP sem saber qual sistema contém a verdade. O modelo ficou indisponível por vinte minutos; a operação perdeu duas horas reconstruindo o estado.

Incidente de IA não é apenas invasão ou vazamento. Para o negócio, também é qualquer comportamento inesperado que ameaça cliente, dado, dinheiro, prazo ou continuidade: uma saída silenciosamente errada, uma ação duplicada, uma integração parcial, uma regra vencida, uma permissão usada fora do escopo ou um volume que cresce sem controle.

Este artigo entrega o plano RETOMA: uma matriz simples de severidade, quatro modos de operação, um cartão de resposta por agente e um exercício de mesa de 45 minutos. A meta não é prometer risco zero. É impedir que a primeira falha real transforme uma automação útil em improviso coletivo.

Por que o plano precisa existir antes da falha

Em uma pesquisa publicada em abril de 2026, a Cloud Security Alliance informou que 65% dos 418 profissionais de TI e segurança consultados relataram ao menos um incidente relacionado a agentes no ano anterior; entre os impactos apontados estavam exposição de dados e interrupção operacional. O estudo foi encomendado e coelaborado por uma fornecedora do setor, portanto seus percentuais não devem ser projetados automaticamente para toda PME brasileira. Ainda assim, ele registra um sinal relevante: incidentes deixaram de ser hipótese de laboratório.

Uma apresentação da equipe de resposta a incidentes da AWS no NIST, em maio de 2026, descreveu três diferenças nas equipes que responderam melhor: identidades não humanas governadas, telemetria posicionada antes do problema e decisões de contenção previamente desenhadas. O ponto mais operacional é incômodo: desligar um agente sem entender dependências pode corromper estados posteriores, quebrar serviços e causar mais dano que a falha original.

O NIST SP 800-61 revisão 3, publicado em 2025, integra resposta a incidentes ao gerenciamento contínuo de risco em vez de tratá-la como uma atividade isolada depois do evento. Já o guia de resposta a incidentes de IA generativa da OWASP adapta práticas de segurança para aplicações com IA. Para uma PME, a tradução é direta: o plano tem de ligar a falha técnica à função de negócio, ao dono da decisão e ao modo de continuar trabalhando.

Primeiro: defina o que conta como incidente

Se cada resposta ruim abrir uma crise, a equipe logo passa a ignorar alertas. Se apenas vazamento for chamado de incidente, erros operacionais relevantes ficam invisíveis. Adote uma definição em três camadas:

• desvio: o agente errou ou saiu do padrão, mas o controle normal reteve o caso antes de qualquer efeito; entra na fila de melhoria;
• incidente: houve ou pode haver efeito em cliente, dado, dinheiro, prazo, sistema ou decisão, exigindo contenção e coordenação fora da rotina;
• crise: o impacto é amplo, sensível, difícil de reverter ou exige comunicação executiva, jurídica, regulatória ou pública.

O nome importa menos que o gatilho observável. “Comportamento estranho” é vago. “Mais de três pedidos duplicados em dez minutos”, “qualquer mensagem enviada ao cliente errado” ou “fila sem confirmação do ERP por quinze minutos” permite agir sem esperar consenso.

Matriz de severidade: impacto × propagação × reversibilidade

Classifique o evento com perguntas de negócio, não pela aparência dramática da resposta da IA:

1. S1 — retido: erro detectado antes de produzir efeito; registro e correção seguem a rotina normal.
2. S2 — localizado e reversível: poucos casos afetados, estado conhecido e correção simples; o owner decide entre modo assistido e manual.
3. S3 — propagável ou externo: efeito alcança vários registros, clientes ou sistemas, ou o estado real é incerto; suspenda ações, preserve evidências e convoque responsáveis de negócio e tecnologia.
4. S4 — crítico: dado sensível, segurança, obrigação legal, valor material, decisão irreversível ou grande alcance; contenha imediatamente e acione os responsáveis especializados previstos pela empresa.

Use três fatores para subir ou baixar a severidade: impacto por ocorrência, velocidade de propagação e facilidade de reversão. Uma resposta textual errada pode ser S1 quando retida por revisão. A mesma resposta, enviada automaticamente a milhares de clientes, muda de classe porque escala e deixa rastro externo.

Quatro modos evitam a escolha falsa entre “ligado” e “desligado”

O erro mais comum é permitir autonomia total até o susto e depois abandonar a solução inteira. Desenhe quatro estados operacionais antes de produzir:

• automático: o agente executa apenas as ações aprovadas dentro dos limites monitorados;
• assistido: continua preparando ou classificando, mas toda ação externa ou gravação exige aprovação;
• manual: pessoas assumem o processo com fila, formulário e regra de priorização definidos; o agente não altera estado;
• suspenso: entradas são represadas ou redirecionadas porque nem a continuidade manual é segura.

Cada transição precisa de gatilho e autoridade. O supervisor pode mover de automático para assistido? Quem pode suspender credenciais? Quem autoriza sair do manual? Sem essas respostas, “humano no circuito” significa apenas que alguém será avisado depois.

Plano RETOMA: seis decisões em ordem

1. R — Reconhecer o alcance: confirme qual função de negócio foi afetada, quando começou, quais clientes, registros, sistemas e credenciais podem estar envolvidos. Diferencie evidência de hipótese.
2. E — Estancar a propagação: escolha a menor contenção capaz de parar o dano: bloquear uma ação, retirar uma integração, revogar uma chave, limitar uma fila, voltar versão ou suspender o agente. Registre quem decidiu e por quê.
3. T — Transferir o processo: mova o trabalho para o modo assistido, manual ou suspenso. Nomeie o responsável pela fila, a ordem de prioridade e o ponto a partir do qual novas entradas serão tratadas.
4. O — Organizar evidências e comunicação: preserve horário, entrada, saída, decisão, ferramenta chamada, retorno do sistema, versão, permissão e intervenção humana. Avise apenas os públicos necessários com fatos, impacto conhecido, ação em curso e próximo horário de atualização.
5. M — Mudar a causa com controle: corrija configuração, dado, integração, regra ou permissão em ambiente controlado. Teste o cenário do incidente, casos próximos, efeitos colaterais e reconciliação do que ficou pendente.
6. A — Autorizar a retomada: o owner do processo aceita evidências de recuperação, libera primeiro com menor autonomia e acompanha uma janela reforçada. Feche apenas depois de reconciliar duplicidades, lacunas e ações parcialmente concluídas.

A ordem evita dois impulsos perigosos: investigar longamente enquanto o dano continua e voltar rápido porque “o sistema respondeu”. Conter vem antes de explicar; reconciliar vem antes de esquecer.

O cartão de resposta de uma página

Crie um cartão para cada agente ou fluxo crítico. Ele deve caber em uma página e estar acessível mesmo se a ferramenta principal estiver fora do ar:

• função do negócio, owner, substituto e contatos de tecnologia;
• gatilhos objetivos para S2, S3 e S4;
• ações que o agente pode executar e sistemas que pode alterar;
• comandos de contenção por componente, com efeito colateral esperado;
• modo assistido, modo manual, fila alternativa e limite de capacidade;
• fontes de evidência e tempo de retenção;
• autoridade para conter, comunicar e retomar;
• critérios de recuperação e roteiro de reconciliação.

O cartão também deve declarar três tolerâncias: por quanto tempo o processo pode ficar interrompido, quantos itens podem aguardar e qual divergência é inaceitável. Em cobrança, uma fila pode esperar algumas horas; uma mensagem duplicada ou dirigida ao cliente errado pode ter tolerância zero. A prioridade do plano nasce do impacto, não da ansiedade técnica.

Sem evidência, a empresa só tem versões da história

Logs genéricos de “sucesso” não bastam. Para reconstruir um incidente, conecte seis peças:

1. entrada: dado, mensagem, arquivo e fonte recebidos;
2. contexto: instrução, regra, base consultada e versão usada;
3. decisão: saída, classificação e motivo disponível;
4. ação: ferramenta chamada, parâmetros e identidade utilizada;
5. confirmação: retorno do sistema de destino e estado final;
6. intervenção: revisão, aprovação, correção ou cancelamento humano.

A AWS alerta que evidência específica de IA — como histórico de versões, rastros de decisões e consultas à base — não pode ser recriada depois se nunca foi coletada. Guarde o necessário pelo tempo adequado ao risco, com controle de acesso e minimização de dados. Registrar tudo indefinidamente também cria custo e exposição.

Exemplos de contenção por setor

• v7 Obras: o agente começa a atribuir atrasos ao responsável errado. Bloqueie notificações externas, mantenha a coleta de evidências e passe a classificação para revisão do engenheiro até reconciliar ocorrências abertas.
• v7 Carteira: a régua dispara cobrança depois de uma baixa. Suspenda envios, preserve consultas e retornos do ERP, separe títulos incertos e só retome após confrontar baixas, promessas e mensagens já enviadas.
• v7 Agro: uma tabela comercial não confirma vigência. Mova propostas para modo assistido, impeça preço ou condição automáticos e encaminhe exceções ao responsável comercial.
• v7 Imob: o handoff ao corretor falha, mas o bot segue prometendo contato. Pare novas promessas de prazo, crie fila manual com horário de entrada e reative somente após testar entrega e confirmação.
• v7 Clínicas Retorno: confirmações de agenda ficam sem retorno do sistema. Não presuma sucesso; represar novos envios, conferir registros e impedir duplicidade protege paciente e recepção.
• v7 Custom: uma integração grava parcialmente no ERP. Desabilite a escrita, mantenha leitura se ela for confiável e segura, identifique o último ponto confirmado e reconcilie item a item.

Exercício de mesa de 45 minutos

Escolha um fluxo em produção e reúna owner, operador, tecnologia e alguém que cuide da comunicação. Não avise qual falha será simulada.

1. 0–5 min: apresente o primeiro sinal, como pedidos sem confirmação ou mensagens duplicadas.
2. 5–15 min: peça severidade, decisão de contenção, autoridade e efeito colateral esperado.
3. 15–25 min: introduza uma complicação: estado do ERP incerto, owner ausente ou fila crescendo.
4. 25–35 min: execute a transferência para modo manual e redija a primeira comunicação interna.
5. 35–45 min: liste evidências exigidas para retomar e transforme cada dúvida em correção do cartão.

Meça tempo para detectar, tempo para estancar, clareza do responsável, capacidade manual, acesso às evidências e qualidade da reconciliação. Se a equipe sabe desligar mas não sabe continuar, ainda não existe continuidade operacional.

Sinais de alerta para o gestor

• ninguém sabe qual foi a última ação confirmada pelo sistema de destino;
• o único plano é desligar a solução inteira;
• a mesma pessoa desenvolve, libera, contém e autoriza a volta;
• o modo manual existe na teoria, mas não tem fila, capacidade nem responsável;
• logs guardam a resposta, mas não a ferramenta chamada e o estado final;
• a retomada depende de “parece normal” em vez de testes e reconciliação;
• cliente, financeiro e operação recebem versões diferentes do mesmo evento;
• o exercício nunca inclui ausência do owner ou indisponibilidade de um fornecedor.

O ponto de vista da V7 Agents

IA só vira operação real quando a empresa sabe trabalhar também no dia ruim. Um agente sem owner, trilha de evidência, limite de autonomia, modo degradado e critério de retomada não é uma capacidade operacional; é uma dependência que ainda não foi governada.

Na escada da V7 Agents, o V7 IA Ready identifica processos críticos, tolerâncias e responsáveis antes da automação. Os Agentes Verticais incorporam regras e exceções do setor. A Operação Contínua monitora sinais, mantém cartões de resposta, testa mudanças e transforma incidentes em melhoria do fluxo. ROI sustentável exige processo, dados, responsável, rotina de revisão e capacidade de recuperar — não apenas um modelo que funciona na demonstração.

Fontes consultadas

• Cloud Security Alliance — Autonomous but Not Controlled: AI Agent Incidents Now Common in Enterprises, abril de 2026.
• AWS Customer Incident Response Team no NIST — Incident Response Preparation for AI Systems, maio de 2026.
• NIST — SP 800-61r3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management, abril de 2025.
• OWASP GenAI Security Project — GenAI Incident Response Guide 1.0, julho de 2025.