AI is now, fairly indisputably, operational infrastructure for many businesses around the world. Models from OpenAI and Anthropic, as well as smaller developers, are being used for everything from mundane administrative tasks to software development and customer service, all the way up to high-level decision-making.

So when these companies suffer an outage, as happened in early September when OpenAI, Anthropic, and xAI all experienced overlapping disruptions lasting around two to three hours, there are business implications – and lots of questions from executives.

Beyond anything else, the incident served as a warning that AI is shifting from a nice-to-have productivity add-on to operational infrastructure, and that some of these dependencies sit outside an organization’s direct control.

As AI becomes deeply embedded in all kinds of workflows, organizations must consider what happens when – not if – those capabilities become unavailable, whether for a few hours or for longer.

Traditional disaster recovery (DR) is centered on restoring critical applications, infrastructure, and data, but AI can add new layers: models and retrieval-augmented generation (RAG) data under an organization’s control, as well as prompts, configurations, identity systems, and third-party APIs.

While the fundamentals haven’t disappeared, businesses face questions about what now constitutes a critical recoverable service in the AI era, as well as how to deal with AI components they cannot restore themselves and how to establish that a recovered AI workload is fit to return to production.

To make sense of how disaster recovery looks in our brave new world, spoke to Johnny Yu, research manager for Storage and Data Management, Enterprise Infrastructure at IDC, and Todd Thiemann, principal analyst at Omdia.

The ‘minimum viable company’ now includes AI

At a fundamental level, the objective of DR is still the same: restore whatever the business needs to operate. The difference now is that AI changes which assets, services, and dependencies may need to sit inside that minimum viable environment.

AI does not necessarily mean that everything must be rethought from scratch; the priority remains identifying the apps and services the business actually needs to function.

IDC’s Yu argues that AI is still usually an accelerator rather than a core component of application functionality, and so restoring critical services to a stable state remains the top priority should disaster strike.

Omdia’s Thiemann introduces a useful concept here: the ‘minimum viable company’, or set of assets and services that have to come back online for operations to continue.

“Some things change, but a lot of the underlying philosophy and strategy stay the same as enterprises become more dependent on AI,” he says. “Enterprises and their IT operations teams traditionally needed to establish data resilience ... to establish a ‘minimum viable company’ so operations could continue in the event of an attack.”

“AI changes that equation in that you still need to consider the minimum viable company, but also take into account AI assets and workflows,” he continues.

Thiemann says those assets can include AI models, RAG data, prompts, and configuration data. For agentic AI in particular, service accounts, API keys, Active Directory, and cloud identity providers can also become part of the recovery dependency chain.

Not every AI component should receive the same recovery priority. The key is ‘business criticality’: an experimental internal chatbot and an AI service sitting inside a core customer workflow clearly do not warrant the same treatment, particularly when recovery time and resources are constrained.

To help smooth out the process (which, naturally, is occurring under pressure), establishing ownership of critical components like infrastructure or data is important, and many companies have fragmented ownership across senior roles.

Even well-prepared companies that have identified their critical AI dependencies may run into another problem: not all of them are things they can restore themselves – particularly services supplied by external model providers.

Recovery can mean two things: substitution and restoration

In the event of a disaster, some AI components can be restored from systems the organization controls; externally hosted model services cannot.

“It’s possible to keep local backup copies of prompts and outputs, and to keep a log of any codebase changes. However, the actual AI generation still wouldn’t be possible if the AI service is unavailable,” says Yu.

“Organizations that intend to be deeply reliant on AI functionality currently don’t have many [business continuity] or DR options to ensure service uptime, so they should be thinking of some sort of multi-model framework with appropriate means of failover,” he continues.

Yu notes that, as far as he is aware, login credentials and the state of an existing conversation cannot simply be transferred to another model, making this kind of ‘failover’ more challenging.

The key is to design fallbacks in advance – whether that means preparing another AI model, reducing functionality, or temporarily reverting to a manual process – and then testing those arrangements like any other continuity measure.

When is an AI service actually restored?

Traditional DR still revolves around concepts executives are familiar with: recovery time objective (RTO), or the target time for restoring a service; and recovery point objective (RPO), or the amount of data loss an organization can tolerate.

AI can add another validation step before recovery is considered complete.

“AI workloads are non-deterministic; the same input twice doesn’t always lead to the same output,” says Yu. “I am therefore of the opinion that organizations should scrutinize their AI workloads a bit after a recovery to ensure the outputs are within expectations.”

The validation bar is higher after a cyberattack or data-poisoning incident. “Restoring the most recent backup risks reintroducing poisoning,” says Thiemann. “While traditional data resilience asks ‘Can we restore service within the Recovery Time Objective?’, you now also need to ask ‘Can we prove the restored system is the right and safe version to run?’”

For AI workloads in 2026, then, recovery can increasingly mean validating that the restored service is fit to resume work, rather than simply confirming that it is available.

AI in the workplace is now a lot more than a chatbot you type questions into. AI developers are increasingly building agents that can take actions autonomously, either individually or as part of multi-agent systems, with varying degrees of human oversight.

Agents can act across multiple systems at superhuman speeds, meaning an incident may involve undoing actions rather than restoring a service.

The scale of the problem is fairly mind-blowing: OpenAI CEO Sam Altman recently said the company has “petabytes of agent activity logs” as part of an ongoing review of its agents’ use of internet access during training and evaluation.

“AI agents introduce the ability for unintended actions or changes to be made at a large scale very quickly,” says Yu. “The new recovery challenge now lies in catching these mistakes as they happen and rolling them back without undoing legitimate and authorized actions in that same timeframe.”

Thiemann points out that agents also rely on non-human identities such as service accounts and API keys, while Active Directory and cloud identity providers can become critical dependencies during recovery.