Where your prompts go: EU AI data residency

Your prompt goes to a machine in a building with an address. EU AI data residency means that building sits inside the European Union, and it is a fact you can check. It is not the same thing as sovereignty, which is about which government can compel the company that owns the machine, and most providers are happy to let you blur the two.

Union AI runs all AI inference on infrastructure inside the European Union. Our hosting, our database and our payment processing involve companies with United States parent entities, so we do not tell you that no data ever leaves the EU. That sentence is the whole point of this post: residency is a real, useful property, and it stops well short of what the word sovereign implies.

Does my data leave the EU when I use an AI API?

That question has no single answer, because "my data" is at least four different things, and they travel differently. Splitting them is the fastest way to get past marketing copy.

Data	What it is	Where it goes with Union AI
Prompt and response	The text you send and the answer the model writes	Processed inside the European Union, never in the US or China
Account and usage data	Your account, your balance, token counts, timestamps	An EU region, run by a company with a US parent
Billing data	Name, email, VAT number, payment details	EU processing, US parent entity
Traffic in transit	The encrypted request on its way to us	Through Cloudflare's edge, in its EU region

Most providers answer the question with the first row and stop. It is the row that matters most, because it is where your customer contract, your patient note or your unreleased code actually gets read. It is also the easiest row to be honest about, which makes the silence on the other three telling.

Data residency, sovereignty and jurisdiction are three different things

Data residency is geography. It answers the question: in which country is the hardware that stores or processes this data? It is checkable, and a provider that will not answer it is telling you something.

Jurisdiction is legal reach. It answers: which state's courts and agencies can issue a binding order to the company that controls that hardware? Jurisdiction follows the company, not the cable.

Data sovereignty is the claim that the answers to both questions land in the same place, and that no foreign authority can get at your data. It is the strongest claim of the three, and it is the one most often made by companies that cannot support it.

Region is not the same as jurisdiction. A US parent company falls under the CLOUD Act, and that changes nothing about where your prompts are processed, but it does change what anyone can honestly promise about them.

Sovereignty in the full sense has more layers than these two, and the companion piece on European sovereign AI takes all four apart. That distinction is why our subprocessors page lists three parties with US parent entities instead of hiding them behind a European flag. A list that leaves the awkward rows out is not transparency, it is advertising.

Does the US CLOUD Act reach data stored in Europe?

Yes, in principle. The Clarifying Lawful Overseas Use of Data Act of 2018 lets United States authorities require a provider under US jurisdiction to produce data in its possession, custody or control, wherever in the world that data is stored. A datacentre in Frankfurt does not put data beyond that reach if the operator is a US company or a subsidiary of one.

What that means in practice

It does not mean your prompts are being read. It means the legal question "who could be compelled to hand this over?" has a different answer than the technical question "where does this run?", and you should answer both before you sign anything.

For most teams the practical consequence is narrow. If you process ordinary business data, the exposure is a risk to document rather than a reason to panic. If you handle health records, legal files, trade secrets or anything covered by professional secrecy, the answer to the jurisdiction question is part of your compliance story, and your customers will eventually ask for it in writing.

What actually reduces the exposure

Four things, in rough order of effect:

1. Fewer parties with foreign parents in the path. Every one you remove is one subpoena target fewer.
2. Keeping the content and the identity apart. Our inference provider sees the prompt but not who sent it. Our database sees who you are but not what you asked.
3. Short retention. Data that no longer exists cannot be produced.
4. Encryption you hold the keys to, where the workload allows it. Inference is the one workload where it usually does not, because the model has to read the text.

Which parts of a request can read your prompt?

Five hops, and only one of them reads the text. Walking through them is the difference between a claim and an understanding.

Your machine holds the prompt in the clear before anything encrypts it. The edge terminates TLS, so your request passes through that machine's memory, and nothing is cached there. Our router sees your key, your balance and the tier you asked for, and forwards the prompt without writing it down. The model reads the prompt and writes the answer, on infrastructure inside the European Union, with no idea who you are. The ledger records token counts, a timestamp and a price, and never the content.

The edge runs in Cloudflare's EU region, so the hop that terminates TLS sits inside the European Union too. The full list of parties, with their regions and the entity behind each one, is on the subprocessors page.

What does the GDPR expect you to know about your AI provider?

More than most buyers ask for. Under the GDPR you are usually the controller and your AI provider is a processor, which means you owe your own users an answer about who processes their data, where, and on what legal basis. Three concrete things follow.

You need a data processing agreement that names the roles and the safeguards. Ours is published in full on the DPA page, not sent on request after a sales call. You need a current subprocessor list, with a right to object before a new party is added. And you need to know whether prompts are used for training, because that changes the purpose of the processing, not just the risk.

Which of your data may go into an AI tool at all is a separate question from where that tool runs, and it is worked through, with a copyable usage policy, in is ChatGPT GDPR compliant for company data.

The regulators are still working out how the GDPR applies to models themselves. The European Data Protection Board's Opinion 28/2024 on data protection aspects of AI models, adopted in December 2024, sets out when a model trained on personal data can be treated as anonymous and when legitimate interest can serve as a lawful basis. Its recurring answer is that this has to be assessed case by case, which is unsatisfying and also correct. Anyone selling you a one-line compliance guarantee is selling you a story.

What changed on 2 August 2026 under the AI Act

The transparency obligations in article 50 of the AI Act, Regulation (EU) 2024/1689, became applicable on 2 August 2026. If you build a system that talks to people, you now have a legal duty to make sure they know they are talking to a machine.

The European Commission's guidance on transparency obligations under article 50 is specific about how: users must be told from the start of the first interaction, in a clear and distinguishable manner. A line buried in your terms of service does not count. Neither does a label that only a developer would recognise.

This is a low bar and worth clearing properly. It is also a good moment to check what your provider will tell your users about the model behind the answer. We publish the model, the licence and the system prompt for every tier on our AI transparency page, so you can pass that on rather than guess at it.

How to check any provider's residency claims in ten minutes

Run this on us too. A claim you cannot verify is a claim you should not repeat to your own customers.

1. Find the subprocessor list. If there is not one, stop here. Every serious processor publishes one.
2. Look for the region column and the entity column. A list with regions but no legal entities hides exactly the thing that matters.
3. Count the parent companies outside the EU. Not to disqualify them, but to know the number.
4. Read the training clause in the terms. Search for "train" and read every hit.
5. Ask for per-request evidence. We return the tier on every API response, alongside the token counts and what the request cost, and the documentation lists every header.
6. Check retention. How long are prompts kept, and by whom, and can you turn it off?

Ten minutes of this beats an hour of reading a vendor's sovereignty page, because the answers are structural. They do not change with the marketing copy.

What we claim, and what we refuse to claim

We claim that all AI inference runs inside the European Union, that your prompts and outputs never go to the United States or China, and that the models run under our management and are never trained on customer data.

We do not claim that no data leaves the EU, because hosting, database and payments are in the path. We do not claim a fully sovereign stack, and we do not claim to be CLOUD Act free. It is technically possible to put every layer in Europe. It is not possible to do that today, run it reliably, and charge the prices on our pricing page. If that changes, we will move, and we will report it.

If the money side is what you are weighing next, the companion piece on what an AI API actually costs per token works through the same honesty test on prices rather than on geography.