On a Friday afternoon this month, two of the most capable AI models on the market went dark for every customer using them. Not throttled. Not deprecated with six months notice. Pulled, over a single weekend, after a regulatory order landed.
The models were Anthropic's most advanced systems. The reason behind the order is its own tangled story, and not the point here. The point is what every company building on a single model just learned the hard way. The intelligence you rented can be switched off by someone who is not you and not your vendor.
Dependency Is a Decision You Are Already Making
Most AI strategies have a quiet assumption baked in. The model will be there tomorrow, priced about the same, behaving about the same. For two years that assumption held well enough that nobody stress-tested it. This weekend stress-tested it for them.
Think about what sits on top of a frontier model inside a real company. Customer support that now routes through it. A coding workflow that doubled output. A content engine, a research assistant, a pricing tool. If your single provider disappears on a Friday, every one of those processes is down on Monday, and your team is improvising in a crisis instead of executing a plan.
And it is not only the dramatic case of a model vanishing. The softer version is more common and almost as costly. Your provider raises prices, changes its terms, deprecates the exact model version your prompts were tuned on, or quietly degrades quality under load. Each of those is a switch being flipped on your operation by a hand that is not yours. You just feel it as a slow tax instead of a sudden outage.
This is not an argument against building on AI. It is an argument against building on one source of it with no exit. I made a version of this case when Microsoft started reducing its dependence on a single model supplier. The largest software company on earth decided vendor optionality was worth billions to protect. The lesson scales down to everyone else.
What Concentration Risk Actually Costs
Finance teams have a word for this that marketing and product teams rarely borrow. Concentration risk. One supplier, one customer, one channel holding up too much of the operation. The discipline of treating no single dependency as permanent is old and well understood everywhere except, somehow, in the AI stack.
The cost of concentration is invisible until the day it is the only thing that matters. A buyer of cloud compute who built everything on one hyperscaler knows this. So does anyone who watched a platform change its API terms overnight. The model layer just joined the list of dependencies that can move without your permission.
There is a pricing dimension too. A vendor that knows you cannot leave has no reason to keep its prices honest. The moment switching costs you a month of rebuilding, your negotiating position is gone, and you will pay for that dependency every renewal cycle whether or not a model ever goes offline. Optionality is not just insurance against disaster. It is bargaining power in the boring quarters.
Here is the cold version. If a model going offline for a week would materially hurt your revenue, you do not have an AI capability. You have an AI single point of failure that happens to be working today. The difference between those two things is architecture you have not built yet.
Build for the Switch Before You Need It
The fix is not paranoia. It is design. Abstract your model calls behind a layer your team controls, so swapping providers is a config change, not a rebuild. Teams that wired their app directly to one vendor's specifics this weekend learned why that shortcut is expensive.
Keep a tested fallback. Not a theoretical one. An alternative model your critical workflows can actually run on, checked often enough that you trust it under pressure. The point of a spare is that you have driven on it before the night you need it.
And rank your AI processes by blast radius. Which ones stop revenue if the model vanishes, which ones are merely inconvenient. The revenue-critical handful deserve redundancy now. The rest can wait. I wrote that you should rebuild your AI stack before the agents arrive, and this is the part most teams skipped. Resilience is unglamorous, so it gets postponed until a Friday makes it urgent.
Portability has a quiet side benefit. The same abstraction layer that lets you survive an outage also lets you route each task to the model that is best and cheapest for it, and to adopt a better one the week it ships instead of the quarter you finally get around to the rewrite. Resilience and agility turn out to be the same architecture.
None of this slows you down in normal weeks. It just means an abnormal week costs you a config change instead of your quarter. That is the entire trade.
The companies that treated their model like infrastructure, with backups and abstraction and a plan, barely noticed this weekend. The ones that treated it like a faucet that would always run spent it scrambling. Rent the intelligence if you want. Just never let one landlord hold the only key.