Por Eduardo Martins*
Quando um sistema tradicional cai e volta ao ar, a crise termina com uma verificação objetiva, na qual a equipe confere a integridade dos bancos de dados, processa uma transação de teste e encerra o incidente. Quando um assistente de inteligência artificial volta ao ar depois de um incidente, a crise pode estar apenas mudando de forma: ele responde com fluência, parece confiável e pode estar produzindo respostas erradas, incompletas ou manipuladas, porque o comprometimento pode estar no dado de treinamento, no prompt de sistema ou no próprio modelo, camadas que nenhum plano de continuidade tradicional foi desenhado para inspecionar.
A distância entre confiança declarada e capacidade real de recuperação já é mensurável mesmo nos ativos convencionais. Segundo o Data Trust and Resilience Report, publicado pela Veeam em 2026 com base em entrevistas com mais de 900 executivos seniores de TI, segurança e risco, 90% das organizações se declaram confiantes em se recuperar de um incidente cibernético dentro dos prazos estabelecidos, mas apenas 28% das vítimas de ransomware conseguiram restaurar completamente os dados afetados, com recuperação média de 72% do que foi comprometido.
Se o descompasso é esse para bancos de dados e aplicações, ativos para os quais existem décadas de prática consolidada, a situação dos ativos de inteligência artificial, que na maior parte das empresas sequer constam do inventário de continuidade, é necessariamente pior.
Restauração de um ativo de inteligência artificial deixou de ser binária
Restaurar um sistema tradicional é uma operação de resultado verificável, na qual a aplicação está no ar ou não está, o banco de dados fecha ou não fecha, e a integridade pode ser conferida por soma de verificação e por transações de teste.
Restaurar um ativo de inteligência artificial não oferece essa garantia, porque o comportamento do sistema depende de camadas que um backup convencional não sabe validar: os dados com os quais o modelo foi treinado ou ajustado, as instruções de sistema que orientam suas respostas, as bases vetoriais que alimentam suas consultas e as credenciais e ferramentas às quais seus agentes têm acesso.
Cada uma dessas camadas é um vetor de comprometimento com efeito retardado. Um envenenamento de dados de treinamento contamina o modelo muito antes de qualquer sintoma aparecer, uma alteração sutil em um prompt de sistema muda o comportamento do assistente sem derrubar nada, e um ajuste malicioso em uma base de conhecimento faz o sistema responder com segurança sobre informações falsas.
O ponto que quebra o plano de contingência existente é que o backup mais recente pode conter fielmente a versão já comprometida, e uma restauração tecnicamente perfeita devolve à produção exatamente o problema que motivou o incidente.
Os agentes ampliam o alcance do dano. Diferentemente de um chatbot que apenas responde, um agente executa ações, dispara integrações, movimenta registros e consome credenciais, de modo que um agente comprometido que volta ao ar depois de uma restauração malfeita não produz apenas texto errado, e sim ações erradas com aparência de normalidade, distribuídas ao longo de dias em sistemas que confiam nele. O dano deixa de ser o evento visível da parada e passa a ser silencioso e cumulativo, o tipo de prejuízo que os indicadores clássicos de tempo de recuperação não capturam.
Adoção de inteligência artificial correu à frente da continuidade de negócios
Segundo o Global Cybersecurity Outlook, publicado pelo Fórum Econômico Mundial em 2026 em parceria com a Accenture, a partir de consulta a 804 executivos de 92 países, 94% dos respondentes apontam a inteligência artificial como o principal vetor de mudança na segurança cibernética, e 87% classificam as vulnerabilidades ligadas a ela como o risco de crescimento mais rápido do período analisado.
O mesmo levantamento mostra que cerca de um terço das organizações ainda não possui processo algum para avaliar a segurança de ferramentas de inteligência artificial antes de colocá-las em produção, e que apenas 40% fazem revisões periódicas depois da implantação.
Se a avaliação de segurança antes da entrada em produção ainda é lacunar, a preparação para o dia seguinte ao incidente está um estágio inteiro atrás. Os planos de continuidade herdados foram construídos em torno de dois indicadores, o tempo máximo de indisponibilidade e a perda máxima de dados tolerada, e ambos pressupõem que o objeto restaurado é confiável por definição.
O próprio levantamento da Veeam mostra a fragilidade dessa premissa já no mundo tradicional, no qual somente 69% dos executivos afirmam que seus objetivos de tempo de recuperação estão de fato alinhados às metas de continuidade do negócio. Para ativos de inteligência artificial, esses indicadores medem a parte errada do problema, porque um assistente pode estar disponível em minutos e permanecer não confiável por semanas.
O movimento das empresas brasileiras torna essa lacuna menos teórica a cada trimestre. Copilotos corporativos, assistentes de atendimento e agentes que automatizam etapas de processos já operam dentro de fluxos críticos de receita e de relacionamento com clientes, o que significa que esses ativos passaram a ter o mesmo peso operacional dos sistemas cobertos pelo plano de contingência, sem terem herdado nenhuma das disciplinas que protegem esses sistemas. A adoção correu na velocidade das áreas de negócio, e a continuidade ficou na velocidade dos comitês.
Plano de contingência para IA exige inventário, versionamento e validação
A correção começa pela visibilidade. A organização precisa de um inventário de ativos de inteligência artificial com o mesmo rigor do inventário de aplicações, cobrindo modelos próprios e de terceiros, prompts de sistema, bases vetoriais e de conhecimento, conectores, credenciais atribuídas a agentes e as dependências entre tudo isso, cada item com dono nomeado e classificação de criticidade. Sem esse mapa, qualquer discussão sobre recuperação é abstrata, porque não se restaura o que não se sabe que existe.
Do inventário decorre a exigência de tratar esses ativos como artefatos versionados com histórico auditável. Guardar versões datadas de prompts, modelos e bases, com trilha de origem dos dados que os alimentaram, é o que permite voltar a um estado anterior ao comprometimento, e não apenas ao estado mais recente, que pode ser justamente o contaminado. Essa disciplina de linhagem, que a engenharia de dados já pratica para fins de qualidade e conformidade, ganha na continuidade uma segunda função, a de definir pontos de restauração íntegros para sistemas cujo defeito não é visível a olho nu.
Mas é a validação comportamental que efetivamente diferencia a recuperação de um ativo de inteligência artificial. Restaurar deixa de ser o fim do processo e passa a ser o meio, seguido de baterias de teste com conjuntos de referência de perguntas e respostas esperadas, verificação de desvio em relação ao comportamento registrado antes do incidente e monitoramento reforçado no período seguinte. A recuperação só deveria ser declarada encerrada quando o ativo prova que responde e age como deveria, critério que nenhum indicador de disponibilidade substitui.
A régua externa vai se mover nessa direção antes do que os comitês de risco imaginam. Reguladores, seguradoras e clientes corporativos, que já cobram evidência de backup testado e de plano de resposta ensaiado, tenderão a estender a mesma exigência aos ativos de inteligência artificial que sustentam decisões e atendimentos, e a empresa que hoje sequer inventariou esses ativos descobrirá a lacuna no pior momento possível, durante o incidente ou durante a auditoria que se segue a ele. Fechar essa distância enquanto ela ainda é um projeto, e não uma constatação forense, é a diferença entre estender uma disciplina existente e reconstruir a confiança do zero.
*Eduardo Martins, Diretor de Serviços e Soluções da Solo Network.
