AI Providers: A Sovereignty Check

When I started building myself a small security adviser — a tool that walks through your own weak points in an interview format and makes recommendations — the first decision was not which model is the cleverest. The first decision was that none of it leaves the machine. If you build a tool you tell where your own gaps are, you can hardly send that list off to someone else's service.

That is the moment the question flips. Before it, you ask: which model is the best? After it, you ask: what happens to what I put in?

That second question is one clients almost never ask me. They ask for a name — which model should we use? I stopped answering that with a name a while ago.

Why leaderboards answer the wrong question

Every month a new ranking of the best AI models appears, and every month it looks different. Anyone who pegs their provider choice to benchmarks is making a decision with an expiry date.

There is, however, one kind of list that is more useful than the usual capability rankings. The LLM Safety Leaderboard on Hugging Face rates models not by how clever they are but by how they behave. It is built on DecodingTrust, whose paper won an Outstanding Paper award at NeurIPS 2023. Eight perspectives are scored, each normalised from 0 to 100:

Toxicity · stereotype and bias · adversarial robustness · out-of-distribution robustness · privacy · robustness to adversarial demonstrations · machine ethics · fairness

That is the more interesting way to ask. "Privacy", for instance, measures whether a model leaks training data or content from the ongoing conversation — a property that appears in no coding benchmark and that matters a great deal in production.

And still, the important caveat: the leaderboard was last updated in November 2024. The models listed there are two generations old. Which makes it an unintended proof of this article's point — even good lists go stale. Take the method, not the ranking.

Four questions instead of a leaderboard

1. Which legal jurisdiction does your input land in?

OpenAI, Anthropic, Google and Microsoft are US companies. Even when processing happens in a European data centre, the operator is subject to US law — the CLOUD Act obliges American providers to hand over data on order, regardless of where it is stored. An EU data centre is a location, not a jurisdiction — for the larger picture behind this, see digital sovereignty. European providers such as Mistral are positioned differently; you still have to check case by case.

2. Is your input used for training?

This is where the biggest difference lies — between access routes, not between providers. Free consumer chatbots generally reserve the right to use input to improve their models. Paid API and enterprise contracts usually exclude it. Anyone using the same interface at work as at home is usually on the wrong contract tier. This belongs in every AI policy: which access, which contract, which data classes.

3. Which operating models does the provider offer?

The range runs from pure SaaS through EU data regions and zero-retention agreements to open model weights you run entirely yourself. The more sensitive the data, the further along that scale you should move.

4. How do you get out again?

Exportable data, documented interfaces, no proprietary formats at the core of your own processes. Anyone who interlocks their workflows deeply with a single provider has no negotiating position at the next price rise. Switching systems has to stay possible; otherwise the selection was not a decision but an accession.

What is different about Chinese models

DeepSeek and Qwen are good, cheap and openly available. Ignoring them would be silly. Adopting them unexamined would be too. The important thing is to separate two matters that are almost always conflated: the service and the weights.

The service: an unambiguous case

Anyone using the hosted DeepSeek app or its API sends inputs, chat histories and location data to China. That is not conjecture but an official finding: the Italian data protection authority had DeepSeek removed from Italian app stores in January 2025. Berlin's data protection commissioner Meike Kamp reported the app to Apple and Google as unlawful content in June 2025 — on the grounds that DeepSeek had not convincingly demonstrated that German users' data in China is protected at an EU-equivalent level. Authorities in South Korea, Taiwan and Australia acted as well.

For question 1, that settles it. For business data the hosted service is out.

The weights: the underestimated half

The second part is more interesting — and far less often understood. You often hear: "We'll just run DeepSeek locally, that solves the data problem." It does. It just does not solve the other problem.

A model's alignment sits in the weights, not merely in the filter in front of them. The study R1dacted examined the openly released R1 weights and their distilled variants and found the censorship there too — not only in the app. A locally running DeepSeek will answer questions about the Kent State shootings in the US and decline to discuss Tiananmen Square in 1989. Politically sensitive subjects — Tiananmen, the status of Taiwan, the Uyghurs — are refused or deflected in a large share of cases, whether you reach the model through the API or run it on your own hardware.

For most companies this is not a political problem but an operational one. A model trained to omit certain things will omit them in your risk analysis too. In your market assessment of a Chinese competitor. In your supplier due diligence. You will not notice, because an omission produces no error message.

In fairness: no model is neutral. Western models carry a trained alignment as well, just a different one. The difference is not whether edges exist but whether you know where they are — and whether you can test for them in your own use case. Which is precisely why the behavioural measurement described above is worth more than any capability ranking.

Open weights, run locally: what they can do and where the dangers are

How to run a model on your own machine I have described elsewhere. In short: for summaries, drafts, explanations and comprehension work, open models are good enough for everyday use. At the frontier the gap to the commercial models remains visible.

The dangers sit somewhere other than most people assume.

"Open weights" is not "open source". You get the weights, not the training data. You can run and adapt the model — but you cannot look at what went into it. Only behaviour can be inspected, never provenance. On top of that come licences that only partly deserve the word "open": Llama, for instance, carries usage restrictions a genuine open-source licence would not.

The supply chain is a real attack surface. Models are downloaded from public platforms. Alongside the originals sit countless derivatives, "uncensored" variants and names that differ by a single character. Download from the publisher's official source, prefer the safetensors format over older Python formats that can execute code on load, and treat a model like any other third-party software: document its provenance, pin its version.

From now on you do the patching. A cloud provider updates its model when a weakness becomes known. Your local model stays exactly as you downloaded it — along with everything later found in it.

Local does not mean secure. A model on an unmaintained machine without disk encryption, without backups, with an open network service is in worse shape than a proper contract with a European provider. The sovereignty gain is worth exactly as much as the operations behind it. That is no small matter: you are taking on the role the provider previously held — responsibility included.

Brokers such as OpenRouter

OpenRouter is a middleman: one key, one interface, dozens of models from different providers behind it. Switching from one model to another is a changed string in your code.

For question 4 this is the best answer on the market. No lock-in, direct price comparison, a fallback when a provider goes down, and testing a new model costs minutes rather than a new contract. For prototypes, and for anything where you do not yet want to commit, it is exactly right.

For question 1 you make things harder for yourself. Your input now travels one station further: from you to OpenRouter — a US company — and from there to the actual provider. Two jurisdictions instead of one, two contracts instead of one.

What you should know:

• OpenRouter itself does not store request and response content as long as you do not explicitly switch logging on. If you do switch it on, you grant OpenRouter an irrevocable right to commercial use of those inputs and outputs. That line is worth reading.
• Metadata — token counts, latency, model, cost — is retained in every case.
• Whether the downstream provider logs or trains is governed by its own policy, not OpenRouter's. OpenRouter publishes that policy per endpoint.
• Account settings let you switch off routing to providers permitted to train on your data — separately for paid and free models.
• There is a zero-data-retention setting that routes requests only to endpoints which store nothing; a provider that stores nothing cannot train on it either. Enforceable account-wide, per model group, or per individual request via the zdr parameter.

My verdict: for prototypes, without reservation. For internal data, defensible — but only with zero data retention enforced and training routing switched off, and that belongs in documentation, not clicked once and forgotten. For the crown jewels, no. A broker solves the lock-in problem; it does not solve a confidentiality problem.

My rule of thumb in practice

The provider is not the first decision. The data class is.

This classification survives every model generation. Which provider currently leads the benchmark is then the last question — and the least important one.

And the one test I recommend to everyone costs nothing: take a real but uncritical task from your own organisation and put it to three models. Not to see which one wins. To see where they differ — and whether one of them quietly leaves something out.