Stop Treating AI Like Magic and Start Treating It Like a Vendor
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 or a breach, but because the US Commerce Department issued an export-control directive barring access by any foreign national. Since nationality (apparently) can’t be filtered in real time at the API layer, the only way to comply was to pull the models entirely. Charmingly, there was effectively no notice, which means companies in finance and healthcare woke up the next morning to broken systems. Within the same two-week window it happened again, when the White House asked OpenAI to stagger the release of GPT-5.6. Both incidents have since eased. Commerce lifted the Anthropic restrictions on July 1, 2026, after Anthropic agreed to security commitments, and GPT-5.6 is rolling out. But that’s cold comfort; Commerce could reimpose the restrictions the moment circumstances change.
When the Helper Becomes the Process
Most organizations still treat artificial intelligence like a productivity tool rather than critical infrastructure. If the model slows down, you wait it out, and that approach worked a couple of years ago when AI was optional. But that time is ending because as teams wire AI into agents and automation, the model stops being a helper and starts being the process. When an agent triages your support queue or screens your intake, the model sits on the critical path. If you have repurposed the employees who used to execute those tasks, you have nowhere to go. Instead, you’re left staring at a screen waiting for an API response that might never come.
Translate the Risk Before You Sell the Fix
This is where a Business Impact Analysis (BIA) earns its keep, by helping to close the communications gap between technical teams and business leaders. The gap often comes down to language because engineers speak in vulnerabilities and exploits, while executives think in revenue and market share. BIA converts technical failures into clear business consequences.
You don’t sell leadership on the idea of a fallback model by talking about latency, token limits, or fears about AI zero days. You sell it by explaining that a four-hour outage costs $2.3 million once you add lost revenue to the churn it triggers. Once you have the numbers, the conversation changes.
Diversify Before You Lose the Option
The single most important step toward AI continuity is to stop relying on a single model from a single provider. Teams who’ve lived through multi-cloud migrations will try that playbook, where AWS shops would just set up backup operations on Azure. Unfortunately, while adding a second commercial AI API as a backup helps with ordinary outages, it won’t help with regulatory removal. The same pressure that pulls one frontier model can affect its closest competitor – both events came from the same policy posture, not two unrelated events. And even when the second provider stays up, it may not save you: when everyone fails over to the same handful of backups at once, you inherit a demand spike instead of an outage. A second API narrows your exposure to bad luck. It does almost nothing for exposure to a directive that names your whole model class.
The only model class that no third party can turn off is one you control directly, because an open-source model you’ve downloaded will keep running regardless of what happens upstream. Open-source models generally trail leading closed models in raw capability, though that gap is narrowing.
Be honest about the cost, though: self-hosting a capable open model isn’t a toggle you flip during an outage. It means standing GPU capacity, someone who owns the MLOps, and a bill you’re paying whether or not you ever fail over. The real decision is warm versus cold – a fallback kept running and ready costs money every month but restores service in minutes, while a cold one saves money and costs you the hours it takes to spin up under pressure. Pick deliberately, and price it as insurance. And remember, continuity planning has never been about preserving peak performance during a disruption. It’s about keeping the lights on at an acceptable, degraded level that your customers won’t notice or will tolerate until normal service returns.
This isn’t just a US story, either. Europe’s Digital Operational Resilience Act (DORA) already forces regulated firms to map and manage their dependence on critical third-party ICT providers – and a frontier model sitting on your critical path is that kind of dependency. It’s a short step from “your cloud vendor” to “your model vendor,” and regulators tend to take short steps. Building this discipline now means you’re ahead of the interpretation, not scrambling to catch up to it.
Build the Switch Before You Need It
Diversification only helps if you can switch on demand, and that depends on architectural decisions made before the disruption, not during an outage. Here are three concrete moves that actually work:
- Put an abstraction layer between your applications and your models so swapping is a configuration change rather than a code rewrite. If your support agent’s hard-coded to one model provider, your “failover plan” is going to look like an extended panic attack. If it calls a gateway, your failover plan is a setting.
- Run your best model as primary for everyday quality, and keep a pre-tested fallback wired up and ready to go.
- Test under load before the outage because a failover model you’ve never run in production is a theory, not a plan. Schedule a deliberate cutover, watch what breaks, and fix it while the stakes are low.
Decide Who Pulls the Lever Before You Need To
A fast failover is worthless if no one’s allowed to trigger it. If cutting over to your open-source fallback requires five signatures and a war room, your real recovery time depends on who talks the longest in that meeting, not on your architecture. Define in advance who can pull which lever at what threshold, and preauthorize them to act without a committee. Decision rights are the highest-leverage speed investment most organizations have never made, and they cost nothing to implement. The technology to switch models in minutes already exists. The permission to do it usually doesn’t.
The Proof Problem Nobody Talks About
There is also a growing legal exposure that most teams ignore because future disputes will turn on substantive evidence.
- Can you prove what your system did during the outage?
- What model produced which output?
- Was the degraded fallback model making defensible decisions?
If your AI-powered agent gives a customer bad advice during a failover to an open-source model, and that customer sues, the question becomes whether you can demonstrate your continuity plan was reasonable. Documentation can be the difference between quickly resolving a dispute and becoming embroiled in one. You need standing response frameworks for your highest-impact scenarios. Define a trigger condition, a decision threshold, a preauthorized action, and a named owner. When the trigger hits, execute on a plan the organization has already stress-tested.
For instance:
| Impact Tier | Trigger | Authority | Action |
|---|---|---|---|
| Level 2 ($10K-$100K) | Primary API degraded or erroring past SLA for > 15 min | Engineering Lead | Failover to secondary commercial API |
| Level 4 ($500K-$1M) | Primary provider unavailable with no confirmed ETA | VP Engineering | Cut over to warm open-source fallback |
| Level 5 (> $1M) | Structural loss of access (export controls, regulatory removal, provider exit) | CTO | Activate self-hosted model on standing hardware; open incident comms |
Press the Accelerator, Not the Brakes
Governance and resilience are not brakes on adoption. They’re what make it safe to press the accelerator, which means 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 have at least one tested model that no one else can take away.
Don’t wait for the next headline to validate what you already suspect. Your monitoring tools will fire alerts, but without a business impact framework attached to them, they’re just noise in a dashboard. It’s not enough to know the model went dark. You need to know how much the downtime burns through every hour it stays down, and you need to know who has the authority to pull the failover switch without calling a meeting. That clarity separates a manageable glitch from a business outage.
