Disaster recovery precisa ser repensado para empresas que dependem de IA

A tese central é que o objetivo do disaster recovery continua o mesmo: restaurar o que o negócio precisa para operar. Muda o que entra nessa conta. Segundo Todd Thiemann, da Omdia, o conceito de empresa mínima viável agora precisa incluir modelos de IA, dados de RAG, prompts e configurações. Para agentes, contas de serviço, chaves de API, Active Directory e provedores de identidade em nuvem entram na cadeia de dependências da recuperação.

Johnny Yu, da IDC, lembra que a IA ainda costuma ser acelerador, não componente central das aplicações, então estabilizar os serviços críticos segue como prioridade. Há um limite prático: modelos hospedados por terceiros não podem ser restaurados pela empresa. Backups locais de prompts, saídas e histórico de mudanças no código ajudam, mas não geram resposta se o serviço estiver fora. A recomendação é um arranjo multimodelo com failover, fallback desenhado antes (outro modelo, funcionalidade reduzida ou volta ao processo manual) e testado como qualquer medida de continuidade. Yu observa que credenciais e o estado de uma conversa não migram simplesmente para outro modelo.

Outro ponto é a validação. Como as cargas de IA são não determinísticas, Yu defende checar as saídas após a recuperação. Thiemann alerta que restaurar o backup mais recente após envenenamento de dados pode reintroduzir o problema. Com agentes agindo em vários sistemas em alta velocidade, o incidente pode exigir desfazer ações, sem reverter as legítimas feitas no mesmo intervalo. O texto cita a interrupção simultânea de OpenAI, Anthropic e xAI no início de setembro, de duas a três horas.

O tema evoluiu da constatação do problema para a prescrição. Em 4 de setembro de 2026, o CEVIU noticiou, em "Empresas em Alerta: Paralisação Simultânea de IAs Gigantes Expõe Fragilidade da Dependência Tecnológica", a queda simultânea de ChatGPT, Claude e Grok e a vulnerabilidade de quem automatiza fluxos com IA. Agora a discussão trata de como planejar a recuperação. Em 11 de março de 2026, em "A AIOps Amadurece: Ferramentas de Reversão para Erros de IA Já São Oferecidas por Fornecedores", o CEVIU já registrava Cohesity, ServiceNow e Datadog desenvolvendo ferramentas para reverter danos de ações de IA, o que dialoga com o desafio de desfazer ações de agentes.

Para quem opera TI corporativa, isso significa tratar a IA como item do plano de continuidade, com dono definido, prioridade por criticidade e teste periódico de failover. Um chatbot interno experimental e um serviço dentro do fluxo de atendimento não pedem o mesmo investimento. Vale revisar também contratos com provedores de modelos e a dependência de identidade, já que o RTO sozinho deixou de provar que o serviço pode voltar à produção.