Within a day of two frontier models going dark, the advice was everywhere and it was all the same. Own your model. Self-host. Get off the single API before someone you never contracted with decides your product is done for the afternoon. Every word of it assumes taking control is the easy part.
My last piece asked what happens when the model you depend on disappears. That was the availability question. The harder one is what you actually control, and what you give up to get it. It took a government switching off a model for most firms to notice they had no answer.
Model sovereignty is a ladder, from renting a frontier model at the bottom to holding your own weights at the top. No rung on it is free. Every step up trades one kind of exposure for another, and none of them lets you stop trusting someone. What climbing changes is who you trust, and for what.
The sovereignty ladder
Start at the bottom rung, where most teams live. You call a frontier model through an API. You picked it the way you pick any SaaS vendor: capability, price, convenience. You hold nothing.
That bottom rung has two ways to fall, and most teams have noticed only one. The first is availability: the model can be changed underneath you, deprecated or switched off by a government you have no relationship with. The second is quieter and older. The data you send the model sits with a provider, and if that company is American, US law can reach it. The CLOUD Act compels any US-headquartered company to hand over data in its control to US authorities, wherever in the world it is stored. Picking the Frankfurt region does not change that. Last year a Microsoft France executive told a Senate committee in Paris, under oath, that the company could not guarantee its customers’ data would be shielded from US authorities, even under its “sovereign” offering.
There is a sharper edge to this. The order can carry a gag, which legally stops the provider from telling you it arrived. Whatever your contract says about notification, a non-disclosure order voids it at the one moment it would matter, and you may never find out the data was handed over.
How likely is that? For an ordinary company, rarely. The CLOUD Act is not mass surveillance. It still needs a warrant, and Justice Department guidance steers prosecutors to the company itself rather than its cloud provider. That is why the big providers report almost no offshore enterprise disclosures. So for most workloads it sits low on the list. The catch is that you cannot see it happen, and you cannot promise a regulator it did not. Low odds you cannot verify are still a risk you carry, and on sensitive data that is the part that matters. Residency is about where the data physically sits. Whose law can compel it is a different question, and that is the one most firms never asked.
The next rung up is a multi-vendor gateway: the routing layer the last piece told you to build, bought as a product rather than wired by hand. One abstraction layer, several providers, automatic fallback. If one model vanishes, traffic reroutes and you stay up. Worth doing. But it defends against one thing only, a single vendor failing, and does nothing against a whole-jurisdiction action. If the rule is “no US-hosted frontier model for foreign nationals,” routing between three US-hosted frontier models buys you nothing. All you have done is spread the dependency across more vendors in the same jurisdiction.
The top rung is open weights, self-hosted. You download the artefact, run it on infrastructure you control, and nobody can revoke it. This is the only rung where the switch-off risk disappears. It still leaves two open questions, though. Where you run it matters: self-host on a US hyperscaler and the CLOUD Act is back at the door, because the law reaches the provider regardless of which model it hosts. And which weights you run matters even more.
The trust you trade for control
The cheapest capable way to buy back control today is open weights. But “open” hides a choice most teams have not faced. The permissive frontier-class weights, the ones under MIT or Apache with no strings attached, are largely Chinese. DeepSeek shipped V4 in April under MIT: download it, run it, fine-tune it, ship it. Zhipu’s GLM-5 and Alibaba’s Qwen sit at the top of the open-weight rankings on similar terms. These are not toys. They post scores alongside the closed frontier, and you can hold the file.
Set the licence aside; it is clean. The harder thing is what you have taken on. You self-hosted to dodge a model Washington could switch off, and now you run one whose training data you cannot inspect, and whose values came from somewhere you understand even less. The trust decision has changed jurisdiction, from a vendor’s government to the country that trained the model.
Meta’s Llama is the model most Western teams reach for first, and it is open-weight but not open-source. The licence caps you at 700 million monthly active users, forbids using it to train a competing model and carves out parts of the EU entirely. That licence is itself a sovereignty string, written by a company that can change it.
Which leaves the European corner. Mistral is French, and it releases its core models, including the Large 3 flagship, under Apache 2.0. Once you hold those weights, no government can switch them off, not Washington and not Paris, because that holds for any open weight you self-host. Its advantage over the alternatives is provenance and jurisdiction: a model whose origins you can trace, run by a company that sits outside the CLOUD Act. The cost is capability. Mistral’s open models are strong and improving, but on the hardest reasoning tasks they still trail the US frontier.
That makes three options, each with its own bill. Rent the US frontier, and you carry revocation and reach. Self-host the best open weights, and you take on Chinese provenance. Go European, and you accept a capability gap. Teams get caught out when they treat one of these as free.
Classify your models the way you classify your data
You already do the harder version of this. You have a data classification policy. Public, internal, confidential, regulated: each tier has rules about where it can live and who can touch it. You built it because not all data carries the same risk, and the CLOUD Act is the reminder of why residency alone was never enough.
Almost no one has the equivalent for models. Model choice is still made per project, on capability and price, by whoever is building. There is no map of which workloads could survive their model vanishing, and which carry data that must never sit where a foreign government can compel it. So the firm cannot answer the question the last piece put on the board: if our primary model disappeared on a Friday, which products break and which reroute? Add a second to it: for which workloads does the jurisdiction of the model itself matter?
The fix is not exotic. Classify workloads by sovereignty requirement the way you classify data by sensitivity. A throwaway internal summariser can rent the best frontier API and shrug if it blinks. A regulated decision path handling sensitive data probably needs a model you hold, on infrastructure you control, even at a capability cost. Most workloads sit between. Decide it on purpose, before the next directive makes the choice for you.
What sovereignty is
Sovereignty is knowing, for every workload, which trust problem you have chosen and why. A sovereign firm can walk its own stack and give the reason for each model: this one rented because the workload is trivial, that one on European weights because the data cannot leave its jurisdiction, the last on open weights it holds because it cannot stop. Every line is a risk it picked on purpose.
Self-hosting alone does not get you there. A team running a Chinese open-weight model it has never evaluated, on US cloud, has swapped a loud risk for two quiet ones and called it safety. Reaching for the best model going, or the cheapest weights you can self-host, ends the same way: a decision no one chose.
Either way, you are making trades. The only thing you fully control is whether you make them on purpose.
Sources
DeepSeek V4: Features, Benchmarks, and Comparisons — DataCamp on the V4-Pro and V4-Flash release under the MIT licence, with open weights downloadable from Hugging Face (April 2026).
Top 10 Open-Weight LLMs in 2026 — Tech Jacks Solutions on Zhipu’s GLM-5 and Alibaba’s Qwen leading the open-weight field on MIT and Apache terms, and on the Llama Community Licence’s 700M-MAU cap, no-compete clause and EU carve-out (2026).
Meta’s Llama license is still not Open Source — the Open Source Initiative on why the Llama Community Licence fails the open-source definition, including its restrictions on users and fields of use (2025).
Introducing Mistral 3 — Mistral on releasing Mistral Large 3 under the Apache 2.0 licence as a permissive open-weight model (2026).
Mistral AI Strengths and Weaknesses 2026 — an honest guide to Mistral’s European data-sovereignty positioning and the capability gap at the hardest reasoning benchmarks (May 2026).
What the US CLOUD Act Actually Does to Data Stored in Europe — SoftwareSeni on US jurisdiction following the provider’s corporate ownership, and on non-disclosure orders that bar a provider from notifying you and override contractual notification clauses (April 2026).
The US CLOUD Act Explained: Why European Businesses Need Non-US Cloud Alternatives — DanubeData on US authorities compelling US providers regardless of storage region, including Microsoft France’s sworn 2025 testimony to the French Senate (June 2026).
CLOUD Act — AWS on the warrant standard behind such requests, Justice Department guidance to seek data from the enterprise rather than its cloud provider, and no offshore enterprise or government content disclosures reported as of June 2025.
Anthropic blocks all public access to Claude Fable 5, Mythos 5 following US government order — VentureBeat on the enterprise response and the shift toward AI supplier diversification and hardware sovereignty (June 2026).
Leave a Reply