Keeping AI workloads and data inside the EU

Somebody has asked you to confirm that your data stays in Europe. Perhaps a customer's procurement form, perhaps your own board, perhaps a public tender with a clause about it.

The honest first answer is that "in the EU" is not one property of a system. It is three separate questions with three separate answers, and a vendor can say yes to the easy one while the other two are somewhere else entirely.

The three layers people mix up

Storage. Where the data sits when nothing is happening: the database, the file store, the backups. This is the layer every vendor advertises, and the easiest to satisfy.

Processing. Where the computation happens. For an AI system this is where the model runs, and it is not automatically the same region as the storage. A European database calling a model endpoint in Virginia is processing in the United States, whatever the storage page says.

Access. Who can read the data while supporting the product, and from where. A platform hosted entirely in Frankfurt with a support team in another continent that can open a customer record has an access route out of the EU. This is the layer that almost never appears in the sales material and almost always appears in the subprocessor list.

Your answer to procurement has to cover all three. A yes on storage alone is the answer that comes apart under questioning.

The options, from lightest to heaviest

A business tier of a large vendor, pinned to an EU region. Azure OpenAI in West Europe or Sweden Central, AWS Bedrock in Frankfurt or Ireland, and the EU residency options that the larger AI vendors now offer on their business plans. Storage and inference in the EU, a real DPA, and almost no work for you. The vendor's parent company is usually American, which matters for the next section.

A European vendor on European infrastructure. Mistral in France, and European clouds such as Scaleway, OVHcloud, Exoscale or Hetzner underneath. This removes the parent-company question and narrows your model choice. For extraction, classification, summarising and most assistant work, the narrower choice is rarely the constraint people expect.

An open-weight model you run yourself. A model served with something like vLLM on your own EU infrastructure, or on hardware in your own building. Nothing leaves. You now own capacity planning, patching, version upgrades and evaluation, permanently. This is the right answer far less often than it is chosen.

Most businesses land on the first option and are done. The second is worth it when a customer contract or a tender genuinely asks about corporate control rather than location. The third earns its keep when the data cannot leave your network at all, and when somebody in-house can run it.

What EU hosting does not solve

An EU region reduces exposure. It does not make data unreachable. US law can reach data controlled by a US company regardless of where the servers stand, which is exactly why some organisations distinguish between EU-hosted and EU-operated, and why a few tenders insist on the second. If your customer's clause uses that language, read it closely before answering, because the two are priced very differently.

Residency also does nothing about the rest of your obligations. Personal data processed without a lawful basis in Frankfurt is processed without a lawful basis. A five-year retention nobody can justify is just as indefensible in Amsterdam as in Oregon. Location is one control among several, and it is the one people buy first because it is the one you can point at.

Getting a straight answer out of a vendor

Four questions, asked in writing, answered in the contract or the DPA rather than on a marketing page:

1. Where is the data at rest, by region, including backups? Backups are where a clean answer usually breaks.
2. Where does inference happen, and can we pin it? Ask whether the region is a setting you control or a default they can change. Ask specifically about failover: some services fail over out of region under load.
3. Who can access the data for support, and from which countries? Ask what is logged when they do.
4. What is the current subprocessor list, and how much notice do we get before it changes? Thirty days notice with a right to object is normal. No list is a red flag.

Then do the part people skip: draw your own data flow and mark every hop. Not the model call, the whole path. The file store, the queue, the transcription step, the vector database, the analytics tag, the error monitoring SDK, the email provider that sends the result. Each one is a separate answer to the same four questions.

When EU hosting is the wrong answer

If the data in question is not personal data and not commercially sensitive, sovereign hosting is a cost with no matching risk. Plenty of automation work moves invoice line items, stock levels and public web content. Paying a premium and accepting a weaker model for that is a decision made to feel safe rather than to be safe.

Self-hosting deserves the same scepticism. An unpatched model server that one person understands is a worse risk than a managed EU endpoint with a DPA behind it. If nobody owns upgrades, do not self-host, whatever the brochure says about control.

And if the real driver is a single customer clause, read the clause before designing anything. We have seen requirements satisfied by naming a region and a subprocessor list, which is a configuration change, not a project.

The failure mode to picture

The architecture diagram says Frankfurt. The model runs in Frankfurt, the database is in Frankfurt, and the DPA is signed. Six months in, someone asks where the transcripts go and it turns out the audio step calls a consumer transcription API on a personal key, because that was how the prototype worked and nobody revisited it. Alongside it, the error monitoring SDK is shipping request payloads, including prompts, to a US region on the free plan.

Nothing in that story required a bad decision. It required a prototype that became production without anyone re-reading the data flow. That is the ordinary way residency claims turn out to be untrue, and it is why the hop list matters more than the headline region.

Building this properly is most of the work in a private AI assistant, and it sits alongside the rest of the compliance guides. Two neighbouring questions: what your team is already sending to consumer AI tools, and what an owned system costs over three years once hosting is on your side of the line.

Frequently asked questions

Does EU hosting mean US authorities cannot access the data?

No. Hosting in an EU region keeps the data physically and operationally in Europe, but a US parent company can still be subject to US legal process for data it controls. If that distinction matters to your customers, you need an EU-operated provider, not just an EU region.

Is self-hosting a model the only way to be certain?

It is the only way to keep data entirely inside your own network, and it trades that certainty for permanent maintenance: patching, upgrades, capacity and evaluation. A managed EU endpoint with a proper DPA is the right answer for most businesses.

Is a US vendor's EU region enough to satisfy the GDPR?

Usually yes, provided the DPA is signed, the subprocessor list is acceptable and any remaining transfer has a valid mechanism. The GDPR does not ban transfers, it requires them to be governed. Sovereignty clauses in customer contracts are a separate and stricter test.

Does a model train on our data if we use a business tier?

On the major business tiers, no, and that should be stated in the terms rather than assumed. Check it per vendor and per tier, and check it again when a vendor changes plans, because the default is what changes most often.