By Hernan Fino, Head of Innovations at Making Sense
In mid-June, a piece of news made headlines around the world: a U.S. government directive tied to export controls required Anthropic to suspend Claude Fable 5 and Claude Mythos 5 for use outside U.S. territory. Since the company had no reliable way to confirm users’ nationality, it ended up blocking access to both models worldwide, just three days after their release.
While access began to be restored a few weeks later, it wasn’t on the same terms as before: one of the models was made available only to approved organizations, while the other was reopened more broadly but at a higher cost.
Since these were such recent models, the episode was unlikely to disrupt operations already in place. But I bring up this example because it made something clear: access to technologies that companies increasingly depend on can change overnight, for reasons entirely outside their control.
As AI becomes a bigger part of products and day-to-day operations, companies need to ask a simple question: How much of their systems depend on a technology provider whose decisions they cannot control?
Multi-model does not automatically mean resilience
A few years ago, most generative AI implementations were still experiments, so if a model became unavailable, teams could wait, fall back to a manual process, or simply pause the test. But that is becoming harder as AI moves into document processing, customer operations, software development, fraud detection, analytics, and workflows where models can interact with tools and take action.
At the same time, companies are already using more than one model. In its January 2026 CIO Survey of 100 Global 2000 companies, Andreessen Horowitz found that 81% were using three or more model families in testing or production, up from 68% less than a year earlier.
And here’s something worth pointing out: working with several models doesn’t necessarily mean a company can replace one when it needs to. Maybe this example helps illustrate what I mean: having several licensed pilots doesn’t mean any of them can step into any aircraft and fly it without additional training. Each aircraft model requires its own specific type rating, even though they’re all “planes” and the pilot already knows how to fly.
In that same sense, tool integrations, output formats, safety rules, and orchestration tend to be built around how one specific model behaves. So if that model suddenly becomes unavailable, the team will have to work through major, urgent changes to get everything running again.
While AI vendor dependency is fairly new, companies have been managing technology dependencies for years, whether in cloud infrastructure, databases, payment systems, or other critical vendors. AI simply adds a twist those dependencies rarely had: two models, or two providers, can receive the exact same instructions and produce different results. They may interact with tools differently, or require adjustments to prompts, validation rules, or the workflow itself, even when their APIs look similar.
A recent MIT Sloan Management Review analysis points the same way: as companies scale AI, they get better results when control lives in the workflow around the model, adjusted to what each use actually risks, instead of sitting on top of the model as a separate layer. The model is one part of the system, not the thing the system is built around.
Every production system depends on something, so the goal was never zero dependency. It is knowing where the dependencies sit, and making sure a change in one place stays in one place.
What a multi-model AI architecture actually looks like
I’ve written before about why I prefer structured AI workflows over automations where a single prompt is responsible for most of the process. Keeping the model as one clearly defined part of the workflow also makes it easier to manage vendor changes.
When the model’s role is separated from everything around it, a provider change stops being a threat to the whole system and becomes a change to one component. A backup still needs to be tested, and prompts or validation rules may need adjusting, but the rest of the product keeps its shape.
Take document review. A file comes in, the system identifies what it is, pulls the relevant data, checks it against business rules, and routes it. The model steps in only for the part that needs judgment, reading ambiguous content a fixed rule cannot resolve, and anything it cannot settle goes to a person. The model does real work, but it stays one station on the line. Swap it out and you retest that station, maybe adjust a prompt or a validation rule. You do not rebuild the line.
A few design choices make that separation easier to hold:
- Keep the provider’s details in one place. The rest of the system should not need to know which vendor is behind the model or how that vendor works. When those specifics live in a single, well-defined spot instead of being wired throughout the product, switching providers means changing one thing, not hunting through everything.
- Build a test set from real business cases. If you need to evaluate a new or backup model, you should be able to test it against the work your system actually performs rather than starting the evaluation from scratch.
- Keep business rules outside the model when possible. Permissions, validation rules, routing decisions, and other predictable logic are easier to manage when they are not buried inside prompts.
- Watch where the dependency hides. It is easy to solve this at the model level and recreate it one step up. If the tool you use to coordinate everything only works with one provider, you have simply moved the problem: the model can change, but that tool can’t, and now the whole system leans on it instead. A setup that supports several models on paper can still be locked to one underneath.
- Plan for what happens when the primary model goes down. The backup does not have to match it feature for feature. It might handle only the routine work while anything sensitive waits for a person, or the feature might run with less capability until the main model returns. What matters is that the behavior is decided in advance, not improvised during an outage.
That last design choice, planning for an unavailable model, is as much operational as it is technical. Supporting more than one provider does not help much if the team does not know when to switch, how to test the alternative, who makes the call, or which parts of the product can keep running during the change.
The goal is not to make every model interchangeable. It is to make a provider change a defined problem the team can manage, rather than one that forces them to rethink the whole system.
AI should not be an exception
The Anthropic episode matters because it turned a theoretical risk into something concrete. That does not mean companies should avoid building on external AI models, but treating them like any other critical technology dependency, which starts well before a provider change, with an honest read on whether the organization is ready to scale AI in the first place.
As I mentioned at the start, none of what’s happening with AI now is new. Things like redundancy, disaster recovery, vendor risk, and business continuity are risks that have existed for years. The main difference is that, since AI models don’t behave the same way, a backup model isn’t something that simply steps in for the primary one. It needs to be adapted, tested, and validated to actually replace it without disrupting the operation.
In my experience, resilience is less about removing dependency than about keeping it contained. You might still test a new model, rewrite a prompt, or rework part of a flow. What matters is whether that work is bounded and planned, or whether it turns into an emergency that spreads through the whole product.
The question is no longer whether a model is good enough to build around. It is whether the system can keep operating when that model is no longer an option.
Hernan Fino is a product experience and innovation leader with more than 10 years of experience connecting technology, design, and strategy. He’s self-taught and data-driven, and works on turning trends into meaningful interactions and links experimentation into measurable, human-centered value for organizations.
Featured image: Omar:. Lopez-Rincon via Unsplash+
Disclosure: This article includes a client of an Espacio portfolio company.
