· architecture · 7 min read
Model Access Just Became a Supply-Chain Risk
A government directive can now switch off your AI provider overnight - and pricing, deprecation, and policy could always do it. If a core feature depends on one model API you don't control, that's a single point of failure. Here's how to treat model access like any other supply-chain risk.
TL;DR: If a core feature in your product depends on a single model provider’s API, you have a single point of failure you do not control. The trigger that made this obvious was geopolitical, but the risk was always there: pricing changes, deprecations, rate limits, policy shifts, outages. The fix is old and boring - put an interface between your code and the model, keep a self-hostable open-weights fallback, and route by capability instead of defaulting every call to one frontier model.
The news that made it concrete
This week a US government export-control directive suspended access to two frontier models for any foreign national - anywhere in the world, including foreign-national employees of the company that builds them.
I have a personal stake in this: I’m a foreign national. A line in a directive I had no part in could cut off the tools I work with, overnight, for reasons that have nothing to do with me or my work. That stings.
But the personal angle is not the point. The point is what it revealed for everyone shipping software on top of these models: access to a model is not a property of your architecture. It’s a permission someone else grants, and can revoke. Most teams had quietly assumed otherwise.
This is an architecture problem, not a politics problem
It’s tempting to file this under geopolitics and move on - “doesn’t apply to me, I’m not in the affected group.” That’s the wrong lesson. Geopolitics was just the trigger that fired first. The underlying exposure was there the whole time, and plenty of other triggers can pull it:
- Pricing. A provider triples the price of the model your margins were built on. (This has already happened to teams more than once.)
- Deprecation. The model version you tuned every prompt against gets a six-month sunset notice, and the replacement behaves differently.
- Rate limits and capacity. You get throttled exactly when a traffic spike means you need the capacity most.
- Policy and ToS. Your use case gets reclassified as disallowed, or a region gets cut off for compliance reasons.
- Plain outage. The provider goes down and takes your feature with it.
Every one of these is the same shape as the geopolitical one: a thing you depend on, controlled by someone whose incentives are not yours, with no fallback. That is the textbook definition of a supply-chain risk. We just don’t usually say “supply chain” about an API call.
What to actually do
You don’t fix this by panic-migrating off your current provider. The good ones are good for a reason - keep using them. You fix it by making sure that depending on them is a choice you can reverse, not a wall you’ve built yourself into.
1. Put an interface between your code and the model
If swapping providers means touching call sites all over your codebase, you
don’t have an integration - you have a dependency baked into your domain
logic. Wrap it. One internal interface (generate, embed, classify,
whatever your verbs are), provider-specific adapters behind it, and the rest
of your app talks only to the interface.
This is the anti-corruption layer pattern, nothing new. The payoff: changing provider becomes a config change and a new adapter, not a rewrite. You can also run two providers side by side - primary and fallback - behind the same interface.
You don’t have to build that seam from scratch. I work mostly in Java, so my
default is Spring AI - its ChatClient already abstracts the provider,
and switching between OpenAI, Anthropic, a self-hosted Ollama model, or
Mistral is largely a matter of swapping a starter dependency and some config.
LangChain4j gives you the same in the Java world; most other ecosystems
have an equivalent. The pattern matters more than the library: whatever you
pick, make sure your domain code depends on its abstraction, not on a
vendor SDK imported directly into your business logic.
2. Keep an open-weights fallback you can self-host
The single most resilient property a model can have, from your point of view, is: you already have the weights. Nobody can revoke a model you’re already running.
Open-weights models in the Llama and Mistral families are good enough for a large share of real production tasks - classification, extraction, summarization, routing, most RAG. They won’t match a frontier model on the hardest reasoning, but most features don’t need the hardest reasoning. Stand one up (even if it’s just warm and idle), wire it behind your interface as the fallback path, and a provider cutoff becomes a quality degradation instead of an outage.
3. Route by capability, don’t default everything to the frontier
Teams reach for the biggest model for every call out of habit. Map your actual calls to the capability each one needs. The cheap, boring, self-hostable model handles the bulk; the frontier model is reserved for the genuinely hard slice. This cuts cost today and shrinks your blast radius if the frontier provider disappears - because most of your traffic was never depending on it.
4. For regulated or EU data, this was already the safer call
If you handle regulated or EU-resident data, self-hosting and EU-based providers were already the more defensible choice on data residency and compliance grounds. The access risk just adds a second, independent reason to do what you should have been considering anyway. Residency and resilience point the same direction.
The honest caveat: abstraction is not free
I’m not going to pretend a clean interface makes providers perfectly swappable. It doesn’t, and anyone who tells you otherwise hasn’t shipped it:
- Prompts are coupled to models. A prompt tuned for one model often needs rework for another. Your fallback needs its own tested prompts, not a copy-paste.
- Tool-use and structured-output APIs differ in shape and reliability across providers - the leakiest part of any abstraction.
- Behavior differs even when the API matches. Only an eval set catches this, which means you need one.
So the interface is necessary but not sufficient. The real deliverable is an eval harness: a set of cases that tells you, in an afternoon, whether the fallback is good enough to flip to. Without it, “we have a fallback” is a hope, not a plan. With it, switching providers is a measured decision instead of a fire drill.
The boring lesson, again
We have seen this movie. It was called cloud vendor lock-in, and the lesson was identical: never build a core capability on something you cannot control, and if you must depend on it, make the dependency reversible before you need to reverse it.
AI is the same risk wearing newer clothes, moving faster. The teams that treat model access as a supply-chain input - with a second source, an interface, and an eval to switch on - will shrug off the next directive, price hike, or deprecation. The teams that wired one provider straight into their core loop will be rewriting under pressure, again.
Sovereignty, in the end, isn’t a slogan. It’s just good architecture.
Summary
A single model provider behind a core feature is a single point of failure - geopolitics was only the trigger that made it visible. Put an interface between your code and the model, keep a self-hostable open-weights fallback, route by capability so most traffic never touches the frontier, and back it all with an eval harness so switching is a decision, not a scramble. The same discipline that beat cloud lock-in works here.
Worried a single provider sits on your critical path - AI, cloud, or database? Book a free 30-minute call and I’ll help you find the single points of failure before they find you.
