As AI moves into the critical path, an outage or a government directive can take your most important capability offline with almost no notice. Continuity planning has to catch up.

A Model Can Now Disappear On You

On the evening of June 12, 2026, Anthropic disabled its two most capable models, Claude Fable 5 and Mythos 5, for every customer on the planet. Not because of a bug. Not because of a breach. The US Commerce Department issued an export-control directive barring access by any foreign national, and because nationality cannot be filtered in real time at the API layer, the only way to comply was to pull the models entirely. 

The notice window was roughly 90 minutes. Companies in finance, healthcare, and SaaS that had quietly folded those models into daily operations woke up the next morning to broken systems.  That “outage” has now reached thirteen days—with no announced end in sight.

Two weeks later it happened again, for a different reason. The White House asked OpenAI to stagger the release of ChatGPT-5.6, limiting it to a short list of government-approved partners with access cleared customer by customer. It was the first time the US government had preemptively asked an American AI lab to restrict a launch before it shipped. A model many teams were waiting on simply was not generally available when expected.

Those are the headline events, and they are the new part of the story. Underneath them is a steadier, more familiar outage cadence. On April 20, 2026, ChatGPT, Claude, and Gemini went down at roughly the same time, taking out the three platforms most teams treat as interchangeable backups for one another. Outage trackers have logged more than 200 Claude incidents since late 2025 alone, with typical resolution times measured in hours, not minutes. None of this is unique; it is the ordinary failure behavior of infrastructure under heavy load.

Put those two downtime drivers together, and the conclusion is hard to avoid. The model you depend on can go away for reasons unrelated to your architecture, contract, or uptime, and it can happen faster than you can convene a response call.

Why This Is a Business Continuity Problem, Not an IT Annoyance

For most organizations, AI started as an assistant. People used it, and if it was slow or down for an afternoon, they went back to doing the work by hand. That is an inconvenience, not a continuity event.

That era is ending. As you wire AI into agents and automation, you stop just using it and start depending on it. The model is no longer a person’s helper sitting beside a process. It is the process. When an agent triages your support queue, drafts your quotes, reconciles your invoices, or screens your intake, the model is critical path.  It’s worse if you have repurposed the employees who used to execute the process.

This is where standard business continuity discipline applies directly, and where most AI adoption has gotten ahead of its own planning. Run the same analysis you would run for any dependency:

• A Business Impact Analysis that identifies which processes now rely on a model and what breaks, in dollars and in customer impact, when that model is unavailable.
• A Recovery Time Objective (RTO) for each of those processes. This is the part most teams have never set for AI, and it is the part that has quietly become urgent. The more of a process you automate, the less of it your people can absorb manually when the model goes dark.  So your exposure grows and your ability to weather an outage shrinks, which compresses your RTO. 
• A dependency map that makes the single point of failure visible. For many organizations, that map ends in a single frontier model from a single provider, accessed through a single API. That is a single point of failure dressed up as a productivity win.

If a core business process has an RTO of four hours and its only path to functioning runs through a model that a vendor outage or a government letter can remove with 90 minutes notice, if you do not have an AI continuity plan you will experience significant business impacts.

Two Failure Modes, and Why the New One Is Harder

Traditional vendor risk planning assumes failures are technical and temporary. The server fails over, the provider works the problem, service comes back. You plan for it with redundancy and you wait it out. The AI outages discussed above fit that mold, and they are manageable with conventional thinking.

The Fable and GPT-5.6 episodes introduce a second failure mode. The model can be perfectly healthy and still vanish, because a government or a provider decides it should. 

Perhaps worse, Fable was also crippled in certain use cases (e.g., AI model development, cybersecurity testing) by intentionally failing to provide accurate data and to communicate its actions. This creates another scenario in which the model is up but not operating as expected, leading to a different type of model availability challenge. The common thread between both failure modes is the same, and so is the fix. Anything you reach only through someone else’s API can be taken away by someone else’s decision.

The Core Move: Diversify Your Model Reliance

The single most important step toward AI continuity is to stop relying on a single model from a single provider, and to ensure at least one of your fallbacks cannot be revoked from the outside.

That last qualifier matters more than it looks. Adding a second commercial API as a backup helps with ordinary outages, but it does not help with the new failure mode, because the same regulatory or business pressure that takes down one frontier model can take down its closest competitor. The April 20 event is the proof: the three obvious substitutes failed at once. The only model class that no third party can switch off after the fact is one that you more directly control. An open-source model you have downloaded keeps running regardless of what happens upstream, because there is no upstream left to fail.

Open-source models generally trail leading closed models in raw capability, but that gap is narrowing and is currently approximately 6 months, which means most AI work will work fine. Continuity planning has never been about preserving peak performance during a disruption. It is about keeping the critical path alive at an acceptable, degraded level until normal service returns. Borrowing the BCM term, you are defining a minimum continuity objective for each AI-dependent process, and a vetted open-source model is usually more than good enough to meet it.

Three Paths to Open-Model Resilience

There is no single right way to run an open-source model, and the three options trade control against operational burden differently. Most organizations will end up using more than one.

1. Open models through a cloud provider. The major clouds and dedicated inference providers offer popular open-source models behind a managed API. You get the convenience of a hosted endpoint without being locked to a single proprietary model, and you can move between hosts because the weights are portable. This is the lowest-effort starting point, though you are still dependent on that host staying up.
2. Open models running on your own cloud infrastructure. You deploy the models yourself on rented GPUs inside your own environment. This is more operational work, but you control the deployment, the data path, and the version, and nobody can deprecate or pull the model out from under you. For regulated workloads where data residency and control matter, this is often the sweet spot.
3. Open models running locally on purpose-built hardware. For the highest assurance, you run inference on hardware you own on-premises. The models live on your equipment and cannot be remotely disabled, throttled, or recalled by anyone. This carries real capital and operational cost, and it is overkill for most use cases. But for the handful of processes where continuity is non-negotiable, it is the only option that fully removes external dependency.

The strategy is not to pick one. It is to match the path to the process’s criticality, just as you already match disaster recovery tiers to system importance.

Building the Plan You Can Actually Use

Diversification only helps if you can switch on demand, and that depends on a few architectural decisions you make before the disruption, not during it.

Put an abstraction layer between your applications and your models, such as a gateway or router, so that swapping a model is a configuration change rather than a code rewrite. If your support agent is hard-coded to one model string, your failover plan is a sprint. If it calls a gateway, your failover plan is a setting.

Then design for tiered failover. Run your best model as primary for everyday quality, and keep a pre-tested fallback wired up and warm, so that when the primary goes dark the critical path drops to an acceptable level rather than to zero. And test it the way you test any other recovery plan. A failover model you have never actually run under load is a theory, not a plan. Schedule a deliberate cutover, watch what breaks, and fix it while the stakes are low.

None of this is a reason to slow down your AI adoption, and that is the point worth ending on. A continuity posture is what lets you lean into AI confidently, because you are no longer betting your critical processes on a single provider’s uptime and a single government’s posture. 

Governance and resilience are not brakes on AI. They are what make it safe to press the accelerator.

If AI is now in your critical path, treat it the way you treat everything else in that path. Find out what depends on it, decide how long you can live without it, and make sure you hold at least one model that no one else can take away.