The AI sovereignty conversation in Europe has gotten louder this summer, and most of the energy behind it is pointed at the wrong problem.
Back in June, Washington placed export controls on Anthropic’s newly released models, just three days after launch. There was no mechanism to comply on a selective basis quickly enough, so the company pulled access globally. It took roughly three weeks for things to come back online. European observers largely treated this as confirmation of something they already suspected: dependence on American technology carries risk, and the fix is to pull control closer to home. Buy local. Host local. Tighten the regulatory grip.
I read the situation differently. What happened in June wasn’t evidence that Europe lacks AI sovereignty. It was a demonstration that the United States has it. A government looked at a technology operating inside its borders, decided it mattered strategically, and used the authority it had. People can debate how that was handled, and Anthropic did push back publicly even as it complied. But the underlying authority to intervene isn’t unique to Washington, and it isn’t going anywhere.
Every government that comes to view frontier AI as strategically important will eventually reach for that same lever. The US happened to move first simply because the leading models were built on its soil. Brussels has its own regulatory machinery and its own ambitions, and any homegrown European model would be just as exposed to a future EU directive as Anthropic was to an American one. Trading one geographic dependency for another doesn’t buy you independence. It just changes whose policy decisions can knock you sideways.
What this means for a business
There’s a real question buried in all this sovereignty talk. Europe just keeps asking the wrong version of it. For a company running production systems, sovereignty has nothing to do with where the model’s flag was planted. It’s about whether your product keeps functioning when a government, a vendor, or a pricing committee somewhere changes the terms you were relying on. That’s not something procurement policy solves. It’s a property you have to design into the architecture itself.
I learned that the hard way, decades before anyone was calling it sovereignty.
Early 2000s. A freezing data center in the middle of the night, a new code version to push live for millions of telco subscribers. The architecture gave us no way to swap the new version in underneath a running system, so the price of change was taking production down, with a four-hour window to pay it. I mostly remember the arithmetic. At every step we recalculated how much time was left for a rollback if the next step failed. We finished with minutes to spare.
There was nothing political about that night. It was a pure lesson in system design. When your architecture won’t let you replace a piece while everything else keeps running, you pay for that limitation eventually. That night, the price was a four-hour blackout window and a lot of adrenaline. Today’s teams pay in other forms, but it’s the same underlying bill, generated by systems that can only be changed through shutdown.
Why June was a warning, not a crisis
June was that same bill showing up at a new layer of the stack. And here’s the part that should give people pause. The only reason this played out as a minor inconvenience rather than a genuine crisis was that the affected models had only been live for three days. Barely anyone had built anything on top of them yet, and Anthropic’s other models stayed available the whole time, so most teams simply routed around the disruption without their users noticing a thing. The next time something like this happens, it may not be so forgiving. It could hit a model that’s been sitting inside your core product for two years. What was brief this time doesn’t mean the underlying exposure is small.
Using a frontier model isn’t the risk
To be clear about something the sovereignty framing tends to obscure: frontier cloud models, American providers included, remain the right tool for a lot of real work. Using them isn’t the problem. The problem is building on top of one so tightly that replacing it later would require a rewrite from scratch. Models evolve, sometimes dramatically. New versions behave in new ways. Capabilities shift underneath you. If your product only functions with one specific model deployed in one specific location, you’ve made an architectural bet you probably didn’t realize you were making.
And this isn’t just about the model itself, even though the model gets all the attention right now because it’s the loudest layer. The real question stretches across the entire stack. Can you remove one capability and slot in a replacement without tearing apart everything built on top of it?
Swapping sounds straightforward until you inventory what actually depends on the thing you’re swapping. Prompts calibrated to a specific model’s quirks. Downstream logic written to parse that model’s particular output patterns. Latency and cost assumptions baked directly into the user experience. Evaluation benchmarks that only carry meaning against the exact model they were built around. None of it shows up on an architecture diagram. All of it is the real price tag when the swap actually happens.
Reversibility is the real test
That’s what AI sovereignty actually means at the enterprise level. Reversibility, not isolation from any single provider.
Can you replace a model without rebuilding the product around it? Can the system degrade gracefully through a disruption rather than going dark completely? And can you do all of that while holding quality, latency, security, and cost at acceptable levels? A fallback path that produces garbage output, fails your own security standards, or costs five times as much isn’t really a fallback. It’s a slide deck talking point.
Building that kind of resilience doesn’t come from a top-down policy memo, and honestly, it doesn’t come from a procurement rule tied to a vendor’s headquarters address either. It has to be engineered one workload at a time. Some workflows genuinely require a frontier model and nothing less. Others can run perfectly well on something smaller, an open-weight alternative, or a private deployment, with users never noticing the difference. You only find out which is which by actually looking.
Making it operational
None of this requires waiting for the next regulatory move, wherever it originates.
Start by mapping every production workflow that depends on a single external model, and be honest about which of those have zero fallback plan. Pick the riskiest one and build a working failover path, then test it for real rather than on a whiteboard. Add continuity and exit terms to your procurement checklist so those questions get asked before contracts are signed, not after something breaks. And treat model-replaceability as a conscious choice made for each workload, rather than something you inherited by default from whoever had the best benchmark numbers a year and a half ago.
Europe is welcome to keep debating whose models belong on its shelves, and some of that debate genuinely matters. But it won’t determine whether your product survives the next policy shift, no matter which capital that shift comes from.
I haven’t stood in a freezing data center in a long time. Most of those rooms don’t even exist anymore. But the lesson from that night never expired. Build systems that let you swap a component out while everything keeps running, or accept that eventually you’ll find yourself standing there again, watching the clock, doing the math on how many minutes you have left.
That’s what AI sovereignty actually means to me.
