An AI outage does not need to be technical.
That is the lesson I would take from the Fable 5 and Mythos 5 suspension.
According to Anthropic, the US government issued a directive requiring it to suspend access to those models for foreign nationals. Anthropic said the practical effect was that it had to disable the models for all customers while it complied.
Whether that access is restored quickly is not the main point.
The main point is simpler: if a workflow depends on a model you do not control, that workflow can be interrupted by a decision outside your company.
Not a server failure.
Not a bad deployment.
Not ransomware.
A policy decision, a vendor decision, a compliance decision, or a jurisdictional decision.
That belongs in the DRP conversation.
AI is now operational infrastructure
For years, many companies treated AI as a productivity layer. Useful, powerful, sometimes impressive, but still sitting around the edge of the business.
That view is becoming harder to defend.
AI is moving into the daily work: summarizing client files, drafting contracts, triaging tickets, supporting developers, searching internal knowledge, preparing reports, mapping entities, reconciling data, and helping teams make decisions faster.
At that point, AI is no longer just a tool someone opens in a browser.
It becomes part of the operating path.
And once something is part of the operating path, it needs the same discipline we already apply to servers, networks, databases, backups, suppliers, and identity systems.
We do not ask whether backup is useful.
We ask what happens when restore is needed.
We do not ask whether cybersecurity is convenient.
We ask what happens when protection fails.
AI is entering the same category.
The risk is not only vendor downtime
A normal SaaS outage is easy to understand. The vendor is down. The API is unreachable. The region has a problem. You wait, fail over, or degrade the service.
The Fable 5 situation points to something wider.
The interruption did not come from a technical outage. It came from a regulatory directive, applied through a provider, with impact on customers who were not part of the decision.
That matters.
It means the risk surface is not just uptime. It is also policy, jurisdiction, export control, provider compliance, customer classification, model availability, and internal access rules.
For a small experiment, that may not matter much.
For a critical workflow, it matters a lot.
If your legal review process, customer support process, development workflow, or internal research workflow depends on one external model, the dependency is not only technical. It is also institutional.
That is the part many AI adoption plans still miss.
Multi-provider is useful, but it is not always enough
The first objection is fair: if one cloud model disappears, just switch to another one.
For many workflows, that is exactly the right answer.
If the task is generic writing, summarization, brainstorming, or search over non-sensitive public information, a second cloud provider can be a perfectly reasonable fallback.
Private AI does not have to replace every cloud model.
That would be the wrong architecture and the wrong economics.
But some workflows are different.
They involve sensitive data. They require audit trails. They depend on customer commitments. They operate under contractual, regulatory, or sovereignty constraints. They require a known behavior, a known model, a known data path, and a known fallback when the main tool is not available.
In those cases, “we will just use another external model” is not a resilience plan.
It is another dependency.
That does not mean the private fallback has to be frontier-level. It means it has to be good enough for the task that must continue.
That distinction matters.
A private model may not produce the same output as the best frontier system. It may be slower. It may require narrower tasks. It may need better prompts, better retrieval, or more structure around it.
That is managed degradation.
And managed degradation is exactly what DRP is about.
The goal is not to pretend nothing happened. The goal is to keep the business moving in a controlled way when something important breaks.
The questions to ask
A useful AI continuity review does not start with models.
It starts with workflows.
Which workflows stop if your primary model disappears tomorrow?
Which teams lose meaningful capability?
Which data can still be processed if the cloud connection is cut?
Can you switch providers without breaking data rules, audit trails, contractual promises, or customer commitments?
Which tasks only need a degraded fallback, and which tasks need full capability?
Which processes should have a manual fallback because automation is convenient but not essential?
Which processes should have a private AI fallback because interruption would create business risk?
Those questions are more useful than a generic debate about cloud versus local AI.
Some answers will point to a second cloud provider.
Some will point to a smaller local model.
Some will point to better process documentation.
Some will point to no action at all, because the workflow is not critical enough to deserve the cost.
That is fine.
DRP is not about protecting everything equally. It is about knowing what matters before it breaks.
Private AI is not only about confidentiality
Most private AI discussions start with data privacy.
That is still important. For many Canadian businesses, data location, customer confidentiality, and vendor exposure are not theoretical issues.
But confidentiality is only one part of the argument.
The other part is continuity.
Can the business still run if the best model is unavailable?
Can the team still process the sensitive file if the cloud service cannot be used?
Can the organization still answer the client if the external provider changes policy, pricing, terms, access, or geography?
Can the board honestly say AI dependencies have been reviewed the same way other operational dependencies are reviewed?
For many organizations, the answer today is no.
Not because they are careless.
Because AI moved faster than the governance around it.
First it was an experiment. Then it became a productivity tool. Then it quietly became part of how work gets done.
The governance did not always follow.
Final words
The Fable 5 suspension may become a temporary incident. It may be resolved quickly. It may end up as a footnote in the history of frontier AI access.
But the category of risk will not disappear.
AI will keep moving deeper into operations. Governments will keep treating frontier models as strategic infrastructure. Providers will keep changing access, pricing, retention, policy, and availability. Companies will keep building workflows on top of systems they do not fully control.
That is not a reason to avoid AI.
It is a reason to architect it properly.
Use cloud models where they make sense.
Use multi-provider fallback where that is enough.
Use private AI where continuity, confidentiality, sovereignty, or contractual risk requires more control.
And for the workflows that really matter, stop asking only which model is best today.
Ask what still works when that model is gone tomorrow.