Sovereign AI is not a seal · four questions decide it

“Sovereign AI” now appears in nearly every proposal, which makes it useless as a selection criterion. It only becomes useful once you break it into questions that have checkable answers.

There are four, and not one of them can be answered with a badge.

One: Where Does the Computation Happen?

Not where the company is registered, not where the contract is signed, but where the computation runs with your data sitting in memory. That is a technical question with an unambiguous answer, and the answer is one of: on your own premises, in a private cloud under your control, in a data center inside the EU, or outside it.

Any of those is defensible as long as it was chosen deliberately. What is not defensible is not knowing. If you ask a vendor and get an answer about certifications instead of locations, you already have your answer.

Two: Who Holds the Keys?

Encryption has become standard; key custody has not. The distinction that matters is between encryption performed by the vendor and encryption with a key the vendor does not hold. Only in the second case does encryption change anything about who can access what.

The same applies to authentication against the connected systems. Access you can revoke yourself at any moment is a different situation from access whose revocation you have to request.

Three: Who Can Be Legally Compelled?

The most uncomfortable of the four, because no amount of engineering solves it. A vendor is subject to the legal order of its seat and to that of its parent companies. Whoever can be compelled to hand over data there can be compelled, regardless of where the servers stand or what the contract says.

That does not translate into a recommendation against particular vendors. It translates into a documentation requirement: the chain of subprocessors has to be known and inspectable. A vendor who cannot name it cannot answer the question.

Four: Can You Get Back Out?

The test is simple and almost never run: suppose the vendor discontinues the service in twelve months. What is left? The data, because it was never copied out. The process description, if it was documented outside the tool. The skills your team built, if your team built them.

What is not left is everything that existed only inside the vendor's interface. The size of that set is the most honest measure of dependency there is.

How SIMOSphere AI Answers the Four

• Computation runs on your premises or in your private cloud. Connectors read from your systems instead of copying data into a second store.
• The model choice is yours: open European models such as Apertus and Mistral, a commercial provider using your own key, or a model you host yourself.
• Every model comes with a model card stating provider, knowledge cutoff, and subprocessors. The subprocessors are publicly listed.
• Every call leaves an audit entry, exportable as CSV. Models are never trained on your content.

The second point is the important one. A setup where the model is replaceable survives any market movement. A setup locked to one specific model does not, no matter where that model runs.

Why Open Models Are the Sensible Default

Not on principle, but for three practical reasons. An open model can run where the data already is, instead of moving the data to where the model is. Its behavior stays put over time, because it does not change without your involvement. And it does not cease to exist when a vendor reworks its price list.

Against that stands an honest drawback: on the hardest tasks the large closed models generally still lead. Which is precisely why the right default is open and the right architecture is replaceable, rather than the other way around.

What Sovereignty Costs

Recommending sovereignty without naming its price is selling. Three costs are real.

• Operations effort. A system on your own premises has to be run, patched, and monitored by somebody. That work does not exist in pure cloud consumption.
• Giving up the newest thing. If you host it yourself, you are never on the vendor's latest state on the same day.
• Front-loaded work. Sorting out permissions, naming systems of record, keeping model cards current: that effort lands at the beginning, not at the end.

Against those stands one advantage, but a heavy one: whether you can still use the service tomorrow depends on you rather than on somebody else's decision.

Conclusion

Sovereignty is not a state you purchase. It is a property that follows from four decisions: where you compute, who holds the keys, whose law applies, and whether you can leave. All four are made while building, usually without discussion, and all four are expensive to reverse later.

If you want to know how those answers come out in your own company, start with the system inventory. The path is described in the EU AI Act guide, and the technical side of integration is on the MCP connectors page.