Is EU hosting the same as data sovereignty?

No, and the gap between the two is where most European AI procurement currently goes wrong. "Hosted in the EU" is not a lie, and it is not worthless. It is an answer to a question almost nobody asked, offered in place of an answer to the question they did ask.

The question a buyer is usually asking is some version of: if this goes wrong, who can reach our data, under whose law, and can we prove afterwards what actually happened? A region answers none of that. It answers where the electricity was spent.

A region is a place. Sovereignty is ownership, access, and evidence. They are not the same thing, and the market keeps selling the first as the second.

What does "hosted in the EU" actually establish?

It is worth being fair to the claim before taking it apart, because it does establish something real. If a workload genuinely executes in a European region, then the data is physically processed inside the EU, latency is usually better for European users, and one common GDPR transfer question becomes easier to answer, because there is no transfer at the point of processing.

That is worth having. It is simply much narrower than the word sovereignty implies, and the distance between what is proven and what is inferred is where the risk sits.

What does it not establish?

Seven things, each of which a serious buyer eventually has to answer, and none of which follows from a region:

• Who owns the company operating the service, and where its parent sits.
• Who can be legally compelled to grant access to the data, and under which jurisdiction's law.
• Which subprocessors touch the data on its way through the system.
• Where the encryption keys live and who holds them, which is a different question from where the data lives.
• Who runs the build and control plane, which is often outside the region the workload runs in.
• What happens to the data during an incident, when support engineers need access to debug a live system.
• Whether the model that answered was the model you were promised, at the version you were promised.

That last one is the least discussed and, for AI specifically, the most consequential. Every other item on the list has an analogue in ordinary cloud procurement. Model identity does not. A region says nothing about which weights served your request.

Why does the distinction keep getting blurred?

Because the shorter claim sells, and because it is genuinely easier to prove. A region is a configuration setting. Ownership, custody and access are a contract, an architecture and an operating practice, and they take real work to establish and more work to evidence.

There is also an honest version of the confusion. Many vendors saying "hosted in the EU" are not trying to mislead anyone. They have done the one thing they could do quickly, they are proud of it, and they have not been asked a harder question yet. The fix is usually not indignation. It is a better question.

What would actually settle it?

Evidence attached to the individual response, rather than assurances attached to the company. In EUChat we call this a sovereignty receipt, and it is the object the whole argument turns on.

Sovereignty receipt

A signed record produced for a single AI response, stating the resolved model and version, the deployment and provider that served it, the region and retention profile, the guardrail and system prompt versions in force, the privacy mode, any tools invoked, and the usage and timing. Signed so it can be checked later by someone who does not trust the vendor.

Strict sovereignty

A separately evidenced deployment and contract profile covering ownership, access, subprocessors, transfers, key custody, operations and incident handling. It is not implied by, and does not follow from, an EU region.

The difference between a receipt and a policy document is the difference between evidence and intent. A policy says what is supposed to happen. A receipt says what did happen, for the response you are looking at, in a form that survives the vendor's marketing department.

What a receipt still does not prove

This is the part usually left out, so it goes here rather than in a footnote. A receipt is evidence, not a guarantee, and it has clear edges.

• When a model is served through a provider-hosted API, the receipt can record the alias the provider published, but it cannot cryptographically prove which weights answered. A hosted API is not able to demonstrate that. The honest response is to say so on the receipt, which is what we do, rather than to imply a verification that did not happen.
• A receipt records what the system observed. It cannot, by itself, prove that a provider honoured its own retention commitments after the response left.
• Signatures prove the record was not altered after the fact. They do not prove the record was complete in the first place; that depends on the system generating it.
• None of this substitutes for contracts, a DPA, or a data protection impact assessment. Evidence and legal basis are different instruments and you need both.

What should a buyer ask instead?

Replace "where is it hosted" with questions that cannot be answered by a configuration setting. These five are enough to separate a serious vendor from a confident one:

1. Who owns the entity operating this service, and which law governs a request for access to our data?
2. Which subprocessors touch our data, and can we see the current list rather than a right to be notified of changes?
3. Where are the encryption keys held, and can you technically read our data if you are compelled to?
4. During an incident, who gets access to production, from where, and what record is kept of it?
5. For a single response, can you show me which model and version served it, in which region, under which policy, in a form I can verify later?

The fifth question is the one that ends most conversations quickly, and it is the fairest, because it asks for evidence about one concrete event rather than a promise about all future ones.

Ask your vendor for the receipt, not the region.

Why this matters now

European companies are moving from AI pilots to AI in the operating path of real work, and the moment a system touches customer data, HR decisions or regulated processes, the question stops being whether the output is good and becomes whether the process can be defended. Boards, auditors and regulators do not accept a region as an answer to that, and increasingly neither should buyers.

The useful thing about the receipt framing is that it is constructive rather than adversarial. It does not require a vendor to be suspected of anything. It just moves the conversation from what a company promises to what a system can show, which is a standard any honest vendor should welcome and a dishonest one cannot meet.