Os Incidentes de IA Estão se Tornando Crises Operacionais. Precisamos Tratá-los Dessa Maneira.

Nos últimos anos, a maioria das organizações discutiu o risco de IA na linguagem da governança.

A modelo é preciso? É justo? Os dados são aprovados? Estamos cumprindo com a regulamentação emergente? Essas são perguntas importantes, mas não são as únicas perguntas. A pergunta mais urgente é o que acontece quando algo dá errado?

O que acontece quando um agente de IA toma uma ação que nunca foi destinada a tomar? O que acontece quando um modelo vazou dados sensíveis? O que acontece quando uma resposta alucinada cria exposição legal, ou uma decisão automatizada afeta um cliente, funcionário, paciente ou parceiro de uma maneira que não pode ser facilmente desfeita?

E talvez mais pragmaticamente: onde a organização vai para coordenar a resposta? Essa é a mudança que agora está em andamento. O risco de IA está se tornando uma questão de resiliência operacional, não apenas uma questão de governança.

A IA está se movendo da experimentação para a máquina de trabalho da empresa. Está sendo incorporada ao suporte ao cliente, desenvolvimento de software, operações financeiras, fluxos de trabalho de saúde, contratação, processamento de reclamações, cadeias de suprimentos e automação interna. À medida que a IA se torna mais conectada aos negócios, os fracassos da IA se tornam incidentes de negócios.

O Monitor de Incidentes de IA da OCDE rastreou 596 incidentes de IA em janeiro de 2026 apenas, um crescimento de 200% em relação ao ano anterior. Esforços como o Monitor de Incidentes de IA da OCDE e o Banco de Dados de Incidentes de IA documentam resultados negativos ou prejudiciais envolvendo sistemas de IA para que a indústria possa aprender com a experiência da mesma forma que a aviação e a cibersegurança fizeram por anos.

Essa comparação é importante. Indústrias maduras perguntam como prevenir falhas E como responder quando a falha acontece de qualquer forma.

Os Incidentes de IA Não se Comportam como Erros de Software Tradicionais

Um erro de software tradicional geralmente tem um limite relativamente claro. Algo quebra, os engenheiros investigam e a equipe reproduz o problema, corrige o código e envia uma correção.

No entanto, os incidentes de IA são mais complicados. Eles podem ser probabilísticos, intermitentes e surgir da interação entre um modelo, um prompt, um sistema de recuperação, um plug-in, um agente, um usuário e um processo de negócios downstream. Às vezes, o sistema de IA está operando exatamente como projetado, mas o design é incompleto para o ambiente em que está sendo usado. Isso torna a resposta mais desafiadora.

Uma alucinação em um chatbot de consumidor é um tipo de problema. Uma alucinação dentro de um fluxo de trabalho legal, financeiro, clínico ou de RH é outro. Uma saída tendenciosa em teste é séria. Um processo de decisão automatizado em execução em escala em produção é algo completamente diferente. Um assistente de IA que redige um e-mail é uma coisa, mas um agente que pode alterar permissões, emitir reembolsos, atualizar registros, acionar fluxos de trabalho ou executar código é uma categoria de risco muito diferente.

O Repositório de Risco de IA do MIT captura uma ampla gama de riscos de IA, incluindo informações falsas ou enganosas, falhas de privacidade e segurança, discriminação, uso indevido e problemas de segurança do sistema. A lista de riscos de LLM da OWASP destaca riscos como injeção de prompt, divulgação de informações confidenciais, tratamento de saída inseguro e agência excessiva. Esses são modos de falha práticos, e não preocupações técnicas abstratas.

Se um agente de IA tiver autoridade demais, pode tomar ações que nenhum ser humano pretendia. Se uma injeção de prompt for bem-sucedida, o sistema pode divulgar informações ou seguir instruções hostis. Se dados confidenciais vazarem por meio de um modelo ou sistema de recuperação, a resposta terá implicações legais, regulamentares, de cliente e de reputação. É por isso que a linguagem da governança de IA pode se tornar passiva demais. A governança nos diz o que deve ser verdade. A resposta a incidentes nos diz o que fazer quando a realidade está se movendo mais rápido do que a política.

A Resposta Será Cross-Functional

Uma das lições mais importantes da cibersegurança é que os incidentes raramente permanecem dentro da equipe de segurança. No início, um evento pode parecer técnico. Muito rapidamente, envolve questões legais, comunicações, liderança de negócios, conformidade, equipes de clientes, conselheiros externos, seguradoras, especialistas forenses e, às vezes, o conselho de administração.

Os incidentes de IA seguirão o mesmo padrão.

Imagine um modelo que expõe informações confidenciais de clientes. As equipes de segurança e privacidade precisam entender o que aconteceu. A equipe jurídica precisa avaliar as obrigações. A equipe de comunicações pode precisar se preparar para os clientes, reguladores ou a mídia. A equipe de engenharia pode precisar desativar ou reverter um sistema. Os líderes de negócios podem precisar pesar a continuidade em relação à contenção.

Ou imagine um agente de IA que começa a tomar ações não intencionais em sistemas de empresa. A equipe técnica pode ser capaz de desligá-lo, mas a organização ainda precisa saber o que ele fez, quem foi afetado, quais decisões foram tomadas, se obrigações contratuais foram acionadas e como a mesma falha será prevenida no futuro. Isso não pode ser resolvido apenas pela equipe de IA.

As organizações devem construir músculo cross-functional antes de precisar. Isso significa gatilhos de escalada claros, papéis claros, direitos de decisão claros, caminhos de comunicação claros, documentação clara e prática.

Em uma crise, a coordenação é infraestrutura, não apenas uma habilidade suave.

O AI Que Está Sendo Investigado Não Deve Controlar a Resposta

Há outro problema que as organizações precisam pensar muito mais cuidadosamente. Se o sistema de IA sob investigação puder acessar as mesmas comunicações, documentos, fluxos de trabalho ou automação sendo usados para coordenar a resposta, a organização tem um problema.

Na cibersegurança, esse é um princípio familiar. Se o ransomware comprometeu a rede corporativa, você não coordena a resposta em sistemas que o atacante possa ler, interromper ou manipular. Você move para fora da banda. Você separa o incidente da resposta.

A mesma lógica se aplica à IA.

Um sistema de IA pode não ser malicioso no sentido humano, mas se puder ver o plano de resposta, resumir a reunião de resposta, influenciar o fluxo de trabalho, recomendar a próxima etapa ou operar dentro do mesmo ambiente sendo usado para contê-lo, então a organização não isolou verdadeiramente a resposta.

Isso se torna ainda mais importante com a IA agente. O Quadro de Segurança de IA da Google destaca riscos como injeção de prompt, envenenamento de dados e ações descontroladas, e os mapeia para controles em toda a vida útil da IA. Essa é a estrutura certa. À medida que os sistemas de IA se tornam mais capazes de agir em ferramentas, dados e fluxos de trabalho, as organizações precisam pensar sobre a segurança do modelo E sobre a separação operacional.

Pense nisso como investigar um incêndio. Você não gostaria que os controles do sprinkler estivessem ligados ao mesmo sistema com defeito que está tentando diagnosticar.

Prepare, Pratique, Responda, Relate

Um quadro útil para a preparação para incidentes de IA é o mesmo que amadureceu na cibersegurança: prepare, pratique, responda, relate.

Prepare significa definir tipos de incidentes antes que eles aconteçam, como viés, alucinação, vazamento de dados, deriva de modelo, injeção de prompt, fuga de agente, uso de ferramenta não autorizado e falha de modelo de terceiros. Cada um requer stakeholders e decisões diferentes.

Um bom livro de jogadas não deve ser um documento de 200 páginas sentado em uma pasta. Ninguém abre a página 137 durante uma crise. Um bom livro de jogadas é baseado em papéis, acessível e ação. O jurídico sabe o que o jurídico precisa fazer. A engenharia sabe o que a engenharia precisa fazer. A comunicação sabe quando engajar. O conselho de administração sabe quando a gestão irá escalar.

Pratique significa executar exercícios de mesa. Não uma vez por ano como uma caixa de seleção, mas o suficiente para construir memória muscular. A primeira vez que o conselho de administração discute um incidente de IA não deve ser durante um incidente de IA real. A primeira vez que o jurídico, a engenharia, a privacidade, a segurança e a comunicação trabalham juntos em uma falha de IA não deve ser quando os clientes já estão fazendo perguntas.

Responda significa coordenar o evento ao vivo com disciplina. Quem está na sala? Quais fatos são conhecidos? Quais fatos ainda são incertos? Quais decisões foram tomadas? Quem as aprovou? O que mudou entre a hora 12 e a hora 48?

Relate significa reconhecer que a regulamentação de IA está se tornando mais concreta. O Ato de IA da UE inclui obrigações de relatório de incidentes graves para provedores de certos sistemas de IA de alto risco. Os detalhes variarão por jurisdição, indústria e caso de uso, mas a direção é clara. Os incidentes de IA exigirão cada vez mais um registro defensável do que aconteceu, do que era conhecido, das ações tomadas e de quando.

A IA Pode Ajudar, Mas Não Pode Substituir o Julgamento

Há uma tentação de pensar que a resposta a incidentes de IA deve ser totalmente automatizada. Acho que essa é a estrutura errada.

A IA pode ajudar tremendamente. Pode resumir fatos. Pode identificar informações ausentes. Pode comparar um incidente com padrões anteriores. Pode redigir relatórios pós-incidente. Pode ajudar a mapear obrigações regulamentares. Pode reduzir a carga administrativa quando as pessoas estão sob pressão.

Mas em um incidente grave, os seres humanos permanecem indispensáveis.

Alguém tem que decidir se os fatos são suficientes. Alguém tem que pesar o impacto no cliente. Alguém tem que decidir se deve pausar um sistema. Alguém tem que determinar se a organização cruzou um limiar de relatório. Alguém tem que se comunicar com responsabilidade e empatia.

O papel certo da IA na resposta a incidentes não é substituir a equipe de crise. É dar à equipe de crise um melhor contexto, mais rápido.

O Quadro de Gerenciamento de Risco de IA do NIST é útil porque estrutura o gerenciamento de risco de IA em torno de quatro funções: governar, mapear, medir e gerenciar. Para a resposta a incidentes, eu adicionaria uma extensão prática: ensaiar.

Um plano que nunca foi testado não é realmente um plano. É uma teoria.

Os Conselhos de Administração Precisam de um Livro de Jogadas, Também

O risco de IA está se tornando um tópico de nível de conselho de administração, mas a participação do conselho de administração não pode parar em slides de supervisão. Os conselhos de administração precisam entender seu papel antes que uma crise ocorra.

Quando o conselho de administração será informado? Quais decisões exigirão entrada do conselho de administração? Quais informações a gestão fornecerá? Como a materialidade, o impacto no cliente, a exposição legal, as obrigações regulamentares e a interrupção operacional serão avaliadas?

Muitas organizações têm livros de jogadas de segurança, livros de jogadas de privacidade, livros de jogadas de comunicações e livros de jogadas jurídicas. Muito menos têm um livro de jogadas do conselho de administração para incidentes de IA. Essa lacuna se tornará mais visível à medida que os sistemas de IA se moverem para fluxos de trabalho regulamentados, geradores de receita e voltados para o cliente. O papel do conselho de administração é ajudar a organização a tomar melhores decisões sob pressão, não se tornar mais técnico.

A IA Confiável Exige Resiliência Operacional

Há muita conversa sobre IA confiável. Essa é a aspiração certa, mas a confiança não é criada por princípios apenas. A confiança é criada quando as organizações podem mostrar como elas se preparam, como elas detectam problemas, como elas respondem, como elas se comunicam, como elas documentam decisões e como elas melhoram.

A cibersegurança passou pela mesma evolução. As organizações gastaram anos investindo em prevenção, e devem continuar a fazê-lo. Mas as organizações maduras eventualmente aprenderam que a prevenção não é suficiente. Você também precisa de resiliência. A IA está entrando na mesma fase.

Devemos absolutamente construir modelos mais seguros, controles mais fortes, avaliações melhores, melhor teste de penetração, melhor governança, mas também devemos aceitar que os incidentes acontecerão. Os modelos falharão, os agentes se comportarão de forma inesperada, os dados vazarão, os seres humanos usarão os sistemas de forma indevida, os fornecedores cometerão erros, e as regulamentações evoluirão.

A pergunta é se a organização pode responder com velocidade, coordenação, julgamento e responsabilidade quando um incidente ocorre. É assim que a IA se move da experimentação para a infraestrutura confiável, e é assim que a resiliência se torna cultura.