Where a prompt actually travels
A question typed into an internal assistant looks like one hop. It is usually five or six, and each one is a place where personal data sits, is logged, or can be read by someone.
- 01Your application receives the question and attaches context, often including the user's identity.
- 02A retrieval step searches your index and pulls document fragments into the prompt. This is where most of the personal data enters.
- 03The prompt goes to the model provider's API endpoint in whichever region you selected.
- 04The provider runs inference, and usually writes the request to a log for abuse monitoring and billing.
- 05The answer returns, and your application stores it in a conversation history.
- 06Telemetry, error traces and evaluation samples go wherever your own observability stack lives.
The processor chain
Under the GDPR you are the controller for this processing. Everyone else in the list above is a processor or a sub-processor, and each needs an Article 28 agreement and a lawful ground for any transfer outside the EEA. In a typical build the chain has four links.
| Link | What it handles | What to check |
|---|---|---|
| Your hosting provider | The application, the database and the retrieval index | Region, backup location, and which support staff can reach production |
| The vector or search index | Document fragments, which is often the richest personal data in the system | Whether it is a managed service in a third country, and whether you can delete a single person's fragments |
| The model provider | Prompts and outputs | Inference region, log retention, abuse-monitoring access, sub-processor list |
| Observability and evaluation | Traces, prompt samples, error payloads | Whether prompts are captured in full, and where that service runs |
The index is the link most often treated as infrastructure rather than as a store of personal data. It usually holds more about a person than the prompt does, because it holds the source documents in pieces.
What EU hosting does and does not cover
A European region means your data is stored and processed in European data centres. That is worth having. It is not the same as saying no one outside the EEA can reach it, and the difference is where most compliance arguments fall over.
| Usually covered | Usually not covered unless stated |
|---|---|
| Data at rest in a named European region | Engineering and support access from outside the EEA, including out-of-hours support |
| Inference running on European infrastructure | Abuse-monitoring and safety review, which may be handled centrally |
| Backups kept in the same region | Telemetry, metadata and aggregated usage statistics |
| A contractual commitment not to train on your prompts | Failover to another region during an incident or capacity event |
There is also the question of who the provider is rather than where the servers are. A company subject to another country's legal process can face a demand for data it holds, wherever it holds it. That is the concern the Court of Justice raised in Schrems II, and a region setting does not answer it. Whether it matters for you depends on the sensitivity of the data, not on the marketing page.
Transfers: adequacy, clauses and Schrems II
Checked on 16 October 2026
Chapter V of the GDPR allows a transfer outside the EEA on three kinds of ground: an adequacy decision for the destination country, appropriate safeguards such as the standard contractual clauses, or one of the narrow derogations in Article 49. Access from a third country counts as a transfer even when the data never leaves European storage.
In 2020 the Court of Justice struck down the EU-US Privacy Shield in Schrems II, Case C-311/18, and kept the standard contractual clauses in place on the condition that the exporter checks whether the law of the destination country actually allows them to be honoured, and adds supplementary measures where it does not. That assessment is the transfer impact assessment, and it is the exporter's job, meaning yours.
The Commission adopted an adequacy decision for the EU-US Data Privacy Framework on 10 July 2023, which allows transfers to US organisations that have self-certified under it. Adequacy decisions are reviewed periodically and have been challenged in court before, so confirm the current status and the counterparty's certification rather than assuming both.
- Check whether the specific legal entity you contract with is certified, not whether the brand appears somewhere on the list.
- Where you rely on the standard contractual clauses instead, keep the transfer impact assessment on file with the module and the supplementary measures named.
- Encryption helps where the provider genuinely cannot read the data. It helps far less where the provider must decrypt it to run inference, which is the normal case.
Four deployment patterns
In practice the choice is between four shapes, and the right one follows the sensitivity of the data rather than a preference for any provider.
| Pattern | What it is | Fits | Cost of it |
|---|---|---|---|
| Frontier model, European region | A leading commercial model called in a European region under an enterprise agreement | Most business data, where capability matters and the data is not special category | Provider is often outside the EEA as a company, so transfers still need addressing |
| European provider | A model from a provider established in the EU, run in the EU | Data where the legal chain should stay inside the EEA end to end | A narrower model choice, and you track a smaller roadmap |
| Open-weight model on your own infrastructure | An open-weight model running in your cloud account or data centre | Special-category data, and clients who will not accept an external processor at all | You own the serving, the scaling, the upgrades and the evaluation |
| Inside the client's own tenancy | The system runs in the client's cloud subscription, under their controls | Regulated clients who already have an approved landing zone | Slower to deploy, and you inherit whatever their platform allows |
Most systems end up mixed: an open-weight model for anything touching the sensitive set, a frontier model in a European region for the rest, and a routing rule between them. That is more work to build and considerably easier to defend.
What to insist on in the contract
Six terms carry most of the weight. They are ordinary asks for a business agreement, and a provider unwilling to put them in writing is the answer to a different question.
- No training on your prompts or outputs, stated in the agreement rather than in a settings page.
- A named processing region, and notice before it changes.
- A retention period for prompts and logs, with zero retention available where the data warrants it.
- The sub-processor list, and notice with a right to object before it is added to.
- Named support access: who can read production data, from where, and under what approval.
- Breach notification to you without undue delay, so you can meet your own 72-hour duty.
When we build for a client we settle these before the first document is shared, because the answers change the architecture. A client who needs zero retention and no third-country access is choosing an open-weight pattern whether or not anyone has said so yet.
Where to start
- 01Draw the actual path of one real prompt, including logging and error tracking, and mark every service it touches.
- 02For each service, write down the region and the legal entity you contract with.
- 03Sort your data into two sets: ordinary business data, and anything special category under Article 9.
- 04Choose the pattern for each set, and route between them rather than picking one model for everything.
- 05Collect the processor agreements and the transfer grounds, and keep the transfer impact assessment where you rely on the clauses.
- 06Re-check the residency and sub-processor pages at renewal, since both move without announcement.
The legal basis for the processing itself is a separate question, covered in GDPR and AI: what you may feed an AI system. The classification of the system under the AI Act is covered in our EU AI Act summary.
Questions about EU hosting and AI
Is choosing a European region enough for GDPR compliance?
No. It addresses where data is stored and processed. It does not by itself address access from outside the EEA, your legal basis for the processing, the processor agreements, or retention. It is one of several things, and it is the easiest of them.
Does an American provider with EU servers count as an international transfer?
If staff outside the EEA can access the data, yes, that access is a transfer and needs a ground under Chapter V. Storage location and access are different questions, and the second one is what Chapter V is about.
Do I need a self-hosted open-weight model to be compliant?
Usually not. For ordinary business data, a commercial model in a European region with a proper agreement and a transfer ground is defensible. Self-hosting earns its cost where the data is special category, where a client contractually refuses external processors, or where zero retention cannot be obtained.
Where does the retrieval index fit in all this?
It is usually the most sensitive store in the system, because it holds your source documents in fragments. Give it the same scrutiny as the model: region, access, and whether you can delete one person's data from it on request.
Read Chapter V of Regulation (EU) 2016/679 on EUR-Lex (opens in a new tab), the EDPB guidance pages (opens in a new tab) and the Commission's page on international transfers (opens in a new tab). This article is general information and is not legal advice. Guidance and rules can change, so check your situation with your legal adviser.