Um plano de resposta a incidentes de IA é o protocolo que define, antes que algo dê errado, quem aciona, quem decide e quem contém quando um sistema de inteligência artificial causa dano — um agente autônomo agindo fora do escopo, um modelo alucinando em produção, um dado sensível vazado via prompt ou um shadow AI descoberto tarde demais. A maioria das empresas brasileiras já tem um plano de resposta a incidentes de segurança da informação. O problema é que ele não foi desenhado para os modos de falha específicos da IA — e essa lacuna aparece exatamente na hora em que mais custa.
Por que sua empresa provavelmente não tem esse plano
A lacuna não é teórica. Uma pesquisa da Proofpoint mostra que 42% das empresas no Brasil já sofreram incidentes relacionados a IA, mesmo com controles de segurança em vigor — e o mesmo levantamento aponta que 60% das organizações brasileiras não estão totalmente confiantes de que seus controles detectariam uma IA comprometida, e apenas 25% se dizem totalmente preparadas para investigar um incidente desse tipo (Security Leaders; TI Inside).
O descompasso entre adoção e preparo se confirma globalmente. O 2026 AI Impact Survey da Grant Thornton — 950 executivos seniores entrevistados entre fevereiro e março de 2026 — mostra que quase três em cada quatro organizações já estão dando a agentes de IA acesso a dados e processos (entre piloto, escala e produção), mas apenas 20% têm um plano de resposta a incidentes de IA testado. Em manufatura, a fatia cai para 7% — a menor entre todos os setores pesquisados.
O risco específico de agentes autônomos é ainda mais agudo. O 2026 Agentic AI Security Report, pesquisa global com 300 líderes de segurança, fraude, identidade e IA, encontrou que 97% das empresas esperam um incidente relevante de segurança ou fraude envolvendo agentes de IA nos próximos 12 meses — mas apenas 6% do orçamento de segurança está alocado para esse risco.
A combinação dessas três pesquisas conta uma história única: a IA já está causando incidentes reais, a maioria das empresas espera mais deles chegando, e quase nenhuma investiu no protocolo que determina o que fazer quando eles acontecem. Isso é decisão de investimento e de governança, não pauta só de TI — e cabe à diretoria fechar essa lacuna antes que um incidente a exponha. Se sua empresa ainda não tem a política e a estrutura de governança que sustentam esse plano, o ponto de partida é Governança de IA na prática: política, segurança e LGPD, o guia completo do tema.
Os cinco modos de falha que o plano precisa cobrir
Um plano genérico de resposta a incidentes de segurança da informação não cobre bem os padrões de falha específicos da IA. Cinco cenários concentram a maior parte do risco:
| Cenário | O que dispara | Sinal de detecção típico |
|---|---|---|
| Modelo alucinando ou enviesado | Output incorreto, discriminatório ou fabricado usado em decisão real (crédito, contratação, atendimento) | Reclamação de cliente/colaborador, divergência entre output e dado-fonte, auditoria de amostra |
| Agente autônomo agindo fora do escopo | Agente executa ação (transação, envio, alteração de sistema) além do que foi autorizado | Log de ação sem aprovação correspondente, alerta de sistema downstream, comportamento anômalo de API |
| Dado sensível vazado via prompt | Colaborador ou sistema envia dado pessoal/confidencial para um modelo de terceiros sem controle | DLP acusando payload sensível, denúncia interna, descoberta em auditoria de prompts |
| Deepfake ou fraude com IA generativa | Voz, vídeo ou imagem sintética usada para engenharia social, autorização fraudulenta de pagamento ou difamação | Solicitação atípica por canal incomum, checagem de verificação falhando, alerta de terceiro |
| Shadow AI descoberta em produção | Ferramenta de IA não aprovada em uso real, processando dado da empresa sem governança | Descoberta em auditoria de TI, relatório de despesas, gestão de identidade |
Os dois primeiros e o quinto cenário têm profundidade própria em Governança de agentes de IA autônomos e em Shadow AI: por que proibir não funciona — vale ler antes de desenhar os gatilhos de acionamento para esses casos. O quarto cenário — fraude com deepfake — tem um protocolo de verificação dedicado em Deepfake corporativo: como proteger sua empresa, que este plano deve referenciar diretamente quando o gatilho for esse.
As cinco etapas do playbook, adaptadas para IA
A estrutura clássica de resposta a incidentes — usada por times de segurança há décadas e formalizada por frameworks como o do NIST — tem quatro ou cinco fases dependendo da fonte: preparação, identificação, contenção, erradicação, recuperação e lições aprendidas. O conteúdo de cada fase muda quando o incidente é de IA. Um framework recente dedicado ao tema, o AI Incident Response Framework da Coalition for Secure AI, adapta exatamente esse ciclo para os modos de falha de sistemas de IA — e serve de referência técnica complementar ao que segue.
- Preparação. Antes de qualquer incidente: inventário de todo sistema de IA em produção (modelo, agente, fornecedor, dono do processo, nível de autonomia), matriz de severidade específica para IA, contatos de escalonamento definidos e testados, e o próprio plano revisado a cada novo caso de uso de risco alto colocado em produção. Sem esse inventário, a fase de identificação começa perdendo tempo perguntando "quem é o dono disso?" — a mesma base de visibilidade que sustenta Governança de dados para IA.
- Identificação. Confirmar que é, de fato, um incidente de IA (não um bug convencional) e classificar a severidade: impacto financeiro, exposição de dado pessoal, risco regulatório (LGPD, PL 2338), risco reputacional e se há decisão automatizada afetando pessoas em tempo real. A classificação decide quem é acionado — nem todo incidente sobe até o C-level, mas todo incidente crítico precisa de um caminho já definido para chegar lá rápido.
- Contenção. A ação mais específica de IA: suspender o agente ou desativar a integração (não só "desligar o servidor"), revogar credenciais e escopos de acesso do sistema envolvido, e — quando o caso for output incorreto já distribuído — bloquear a propagação (e-mails enviados, decisões tomadas, conteúdo publicado) antes de investigar a causa raiz. Contenção rápida depende de já saber, de antemão, quem tem autoridade para desligar um agente sem esperar aprovação em comitê — decisão que precisa estar pré-definida, não inventada sob pressão.
- Erradicação e recuperação. Corrigir a causa (retreinar, ajustar prompt/guardrails, corrigir integração, revogar acesso de fornecedor), validar que o sistema corrigido não repete o comportamento antes de reautorizar, e comunicar aos afetados internos e externos conforme exigido — inclusive obrigações de notificação sob LGPD quando houver dado pessoal envolvido, tratadas com mais profundidade em LGPD e IA generativa.
- Lições aprendidas (pós-mortem). Documentação sem caça às bruxas: o que falhou no controle, não quem errou. O output vira atualização do playbook, do comitê de governança e, quando aplicável, da matriz de risco de fornecedor — ver Gestão de risco de fornecedores de IA para o caso de o incidente ter se originado em um modelo ou serviço de terceiros.
Papéis e gatilhos de acionamento
Um playbook sem dono definido por etapa não funciona sob pressão. A tabela abaixo é o ponto de partida — adapte aos comitês que já existem na empresa, como o comitê de ética de IA ou o comitê de segurança da informação.
| Papel | Responsabilidade no incidente | Aciona quando |
|---|---|---|
| Dono do sistema de IA (área de negócio) | Primeiro a identificar e reportar; fornece contexto de uso | Sempre — é o gatilho inicial |
| Segurança da informação / CISO | Classifica severidade, coordena contenção técnica | Incidente confirmado como IA |
| Jurídico / compliance | Avalia obrigação de notificação (LGPD, regulador, cliente) | Dado pessoal ou obrigação contratual envolvida |
| Comitê de governança de IA | Decide suspensão definitiva ou reautorização do sistema | Incidente de severidade média/alta |
| Comunicação / RI | Prepara comunicação externa se houver exposição pública | Risco reputacional ou incidente com impacto em cliente |
| C-level / conselho | Informado e decide sobre incidentes de severidade crítica | Impacto financeiro, regulatório ou reputacional relevante |
Esse desenho de papéis se conecta diretamente ao que já deve estar formalizado em Framework de governança de IA — o plano de resposta a incidentes não é um documento isolado, é a extensão operacional da mesma estrutura de governança para o momento em que algo sai do controle.
Como testar o plano: o tabletop exercise
Um plano nunca testado é uma hipótese, não um protocolo. O tabletop exercise — uma simulação de mesa em que o time percorre um cenário hipotético e narra, passo a passo, o que faria — é o método mais barato e mais revelador de validar um plano de resposta a incidentes de IA. A própria CISA (Cybersecurity and Infrastructure Security Agency dos EUA), via Joint Cyber Defense Collaborative, já conduziu exercícios desse tipo especificamente para incidentes envolvendo sistemas de IA, reunindo dezenas de especialistas do governo e da indústria para simular um ataque e testar a coordenação de resposta.
Formato prático para rodar internamente:
- Escolha um cenário realista da tabela de modos de falha acima (ex.: agente autônomo executou uma transação fora do escopo autorizado).
- Reúna os papéis da tabela de acionamento — não substitutos, as pessoas reais que assumiriam a decisão.
- Um facilitador narra o incidente evoluindo em etapas de 15–20 minutos; cada participante diz o que faria, sem consultar o plano escrito.
- Documente toda lacuna: contato desatualizado, papel ambíguo, decisão que ninguém tinha autoridade clara para tomar.
- Atualize o plano com as lacunas encontradas — e agende o próximo exercício (recomenda-se cadência semestral para sistemas de IA de risco alto).
O tabletop não substitui a auditoria técnica preventiva descrita em Auditoria de IA: guia técnico para C-level e compliance — os dois são complementares. A auditoria reduz a chance de incidente; o tabletop garante que, quando ele acontecer mesmo assim, a empresa reage em minutos, não em dias.
Onde a capacitação e a governança bem feitas encurtam esse plano
O plano de resposta a incidentes de IA só funciona rápido quando existe visibilidade prévia de quem usa qual sistema de IA, com que nível de autonomia e sob qual aprovação. Sem esse mapa, a fase de identificação — a primeira e mais crítica do playbook — vira uma investigação sobre o que a empresa nem sabia que tinha em produção.
É exatamente essa visibilidade que o estágio Mission Control do método Flight Plan da Jetpacks constrói: acompanhamento contínuo e métricas de adoção que mostram, área por área, quem usa o quê e com que autonomia — depois que o Launchpad mapeou o impacto, o Flight Plan definiu a trilha por área e o Booster capacitou o time. Um plano de resposta a incidentes de IA escrito sobre essa base de visibilidade é executável desde o primeiro dia; escrito sem ela, é um documento teórico que ninguém consegue operar sob pressão. A Jetpacks não substitui o trabalho de segurança e jurídico de desenhar e testar o plano — mas capacitação e governança bem estruturadas desde o início reduzem a superfície de incidente e aceleram a detecção, que é onde a maioria dos planos falha primeiro.
Se sua empresa já tem agentes de IA ou modelos em produção sem esse mapa de uso, o primeiro passo não é escrever o plano — é fechar essa lacuna de visibilidade. Fale com a Jetpacks em um diagnóstico gratuito para mapear onde sua empresa está hoje.
FAQ
O que é um plano de resposta a incidentes de IA?
É o protocolo formal que define papéis, gatilhos de acionamento e etapas de ação (identificação, contenção, erradicação, recuperação e lições aprendidas) para quando um sistema de IA causa dano ou opera fora do esperado — diferente de um plano de resposta a incidentes de segurança genérico, que não cobre os modos de falha específicos de modelos e agentes.
Qual a diferença entre resposta a incidentes de IA e resposta a incidentes de segurança da informação tradicional?
A estrutura de fases é parecida, mas os gatilhos, os sinais de detecção e as ações de contenção mudam. Um incidente de IA pode ser um modelo alucinando, um agente autônomo agindo fora do escopo ou um dado vazado via prompt — cenários que um playbook de segurança tradicional, focado em invasão e malware, não antecipa nem tem procedimento de contenção específico (como suspender um agente).
Quem deve ser acionado primeiro quando um agente de IA age fora do escopo?
O dono do sistema na área de negócio identifica e reporta primeiro; segurança da informação classifica a severidade e coordena a contenção técnica (suspender o agente, revogar credenciais); jurídico entra se houver dado pessoal ou obrigação de notificação envolvida. Esses papéis precisam estar definidos antes do incidente, não decididos durante ele.
Com que frequência o plano deve ser testado?
Recomenda-se um tabletop exercise a cada seis meses para sistemas de IA de risco alto, e sempre que um novo agente autônomo ou modelo crítico entrar em produção. Empresas com plano nunca testado — a maioria, segundo o Grant Thornton 2026 AI Impact Survey — descobrem as lacunas do plano durante o incidente real, o pior momento possível.
O plano de resposta a incidentes de IA é obrigatório por lei no Brasil?
Não existe hoje uma exigência legal brasileira específica de "plano de resposta a incidentes de IA" nomeado assim. Mas a LGPD já exige notificação de incidentes envolvendo dado pessoal em prazo determinado, e o PL 2338 (Marco Legal da IA) avança na direção de responsabilização por dano causado por sistema de IA — o plano é, na prática, o mecanismo que permite cumprir esses prazos e demonstrar diligência.
O que é um tabletop exercise de IA?
É uma simulação de mesa em que o time responsável percorre, verbalmente, um cenário hipotético de incidente de IA — sem executar ações reais em sistema — para testar se papéis, contatos e decisões do plano funcionam na prática. Revela lacunas (contato desatualizado, autoridade de decisão ambígua) a custo mínimo, antes de um incidente real expor essas mesmas lacunas.
Quem deve ter autoridade para desligar um agente de IA autônomo durante um incidente?
Precisa estar pré-definido no plano — geralmente segurança da informação ou o dono técnico do sistema, com poder de agir imediatamente e reportar depois, sem esperar aprovação de comitê. Esperar aprovação para conter um agente agindo fora do escopo é o erro mais comum e mais caro em incidentes reais.
Conclusão
Um plano de resposta a incidentes de IA não elimina o risco de a IA falhar — elimina o risco de sua empresa não saber o que fazer quando ela falhar. Com 42% das empresas brasileiras já tendo enfrentado um incidente de IA e só uma minoria com plano testado, a lacuna entre adoção e preparo é hoje o maior risco não gerenciado da maioria das operações de IA corporativa. Os cinco passos — preparação, identificação, contenção, erradicação/recuperação e lições aprendidas — mais um tabletop exercise recorrente transformam esse plano de documento teórico em protocolo que a empresa consegue executar em minutos, não em dias.
Se sua empresa ainda não sabe, com precisão, quem usa qual sistema de IA e com que autonomia — a base sem a qual nenhum plano de resposta a incidentes funciona rápido — comece pelo diagnóstico gratuito da Jetpacks ou monte o business case para a liderança para priorizar essa lacuna antes do próximo incidente.
Descubra onde a IA gera mais resultado na sua empresa.
Comece com um diagnóstico gratuito: mapa de impacto por área e o desenho de um primeiro piloto medível, sem compromisso.