Sovereignty Isn't "Hosted in Europe." It's 7 Layers

Most vendors claiming AI sovereignty only cover 2 of the 7 layers that actually matter. Here's the full stack, where vendors quietly stop, and how to tell a marketing claim from a defensible one.

"Our platform is fully sovereign and hosted in Europe" is one of the most confident sentences in enterprise AI sales, and one of the least specific. It names no layer of the system. It could be true of nothing more than the web server. And under audit, it's undefendable.

That's the gap worth closing before you sign anything: sovereignty is not a location, it's a property of the entire data chain, where your prompts are processed, where responses are stored, whether they train the model, and who holds audit access. It resolves into seven distinct layers, and most self-labelled "sovereign" vendors stop at the first two.

Seven layers, in order of increasing rigour

Each layer up the stack closes a gap the one below leaves open, and the Act's questions reach considerably higher than most vendors' answers do.

  1. Application server residency: The Drupal or content application runs on EU infrastructure. Table stakes, and the layer almost every vendor already offers.
  2. Data residency: Every store touching customer data lives in the EU: databases, file storage, backups, log archives.
  3. Model inference residency: The prompt sent to the language model, and the response returned, are processed on infrastructure inside the EU.
  4. Model residency: The language model itself runs on infrastructure you or your vendor operate, not a third-party cloud API.
  5. Vector storage residency: The vector database holding your embeddings sits on EU infrastructure.
  6. Embedding residency: The embedding model that turns your content into vectors runs on EU infrastructure.
  7. Audit residency: The trace logs of every AI interaction stay in the EU and are accessible to your compliance team.

Layers 1 and 2 answer "where does the infrastructure sit." Layers 3 through 7 answer the question that actually matters under the EU AI Act: where does the data actually go once the AI runs.

Where most vendors stop, and where the Act reaches

This is the split that separates a marketing claim from a sovereign one, and it's worth naming plainly rather than leaving implicit.

Most vendors stop at layers 1 and 2, infrastructure sits in Europe, but nothing is said about where the model runs. The Act's questions reach layers 3 through 7: inference, model, vectors, embeddings and the audit trail. These are the layers that decide whether your data crossed the Atlantic, whether it can be reconstructed on demand, and whether a compliance team can actually defend the answer six months later.

The Atlantic test

Layer 3 is where "hosted in Europe" stops being a sufficient answer, and it's the single question that filters out the most vendors fastest.

If your prompt is sent to a US-hosted API, even if the response comes back through an EU server, your data crossed the Atlantic. The application can be entirely EU-hosted and this can still be true, which is exactly how a vendor ends up making a truthful-sounding claim that fails the moment you ask which layer it applies to.

The two layers vendors get wrong most often

Layers 5 and 6 rarely come up in a sales conversation, mostly because they require the vendor to have actually tested them, not just described them.

Vector storage (layer 5) is where a vendor's migration story matters, because default configurations frequently point at a US-hosted service, and a vendor who has never migrated a vector store has never had to find out whether it's possible. Embedding residency (layer 6) is the most overlooked layer of all, your content passes through the embedding model just as surely as it passes through the LLM, and it's US-hosted by default in a lot of stacks without anyone flagging it.

The Belgian water utility Pidpa ran into exactly this during its public chatbot rollout, and migrated its vector database off a US-hosted service specifically to close layer 5. The trade-off was operational complexity. The win was regulatory defensibility for a system answerable to a public regulator and over a million citizens, the kind of trade that looks obvious in hindsight and easy to skip under deadline pressure.

What a defensible answer sounds like

The difference between the two claims below is the difference between a vendor you can shortlist and one you can't:

A marketing claim: "Our platform is fully sovereign and hosted in Europe." Names no layers. Could be true only of layer 1. Undefendable under audit.

A sovereign claim: "Inference, embeddings, vectors and audit logs all run and stay in the EU. Here is the architecture diagram." Names the layers, specific enough to verify, and specific enough for your legal team to defend.

How to use this

Run this stack past any vendor currently in your evaluation, and ask them to tell you, layer by layer, which ones they cover and which they don't, not as a yes/no, but with a named region for each. Nine times out of ten, the conversation stalls somewhere around layer 4 or 5, and that stall is the answer.

This is one section of a larger procurement conversation. The source whitepaper takes it further with the fifteen contract-stage questions that turn these seven layers into something your legal team can actually defend, plus the full EPSO and Pidpa sovereignty scorecards, and if you want the forty-question scored version for a formal RFP, that's a separate checklist worth asking us about directly.

For the architecture-level view of how these seven layers come together in a live platform, see hosting and sovereignty.

For the full regulatory reasoning behind why these particular layers matter under the EU AI Act, read AI sovereignty: a CIO's procurement guide for the EU AI Act.

Where Dropsolid AI fits in this

Dropsolid AI's own architecture is built around this same seven-layer stack, not the two-layer version most vendors lead with. EPSO's deployment answers the majority of the seven layers by design, EU-hosted inference, a governed model gateway, and a full per-interaction audit trace, and Pidpa's rollout is the six-of-seven case, including the vector database migration described above.

If you're mapping a vendor shortlist against this stack, or want to see which layers our own platform covers and how, talk to our team or book a demo to look at the architecture directly.