LLM API calls and EU customers: data residency and transfers

A regional endpoint from your model provider can keep storage or processing in a chosen region, but it rarely covers everything. GDPR Chapter V still governs transfers outside the EU. Confirm in writing what stays in region, what does not, and what your contract says about transfers. This is not legal advice.

The rule in one line

GDPR Article 44 sets the general principle: personal data may be transferred to a third country or international organization only if the conditions in Chapter V are met, and those conditions must ensure that the protection guaranteed by the regulation is not undermined. That includes onward transfers.

So the question for an LLM API is whether the prompt, the response and any stored data leave the EU or UK, and if so, on what legal basis.

What residency options typically cover

Provider offerings differ, so read yours. As one example, one major provider's documentation describes data residency configured per project. For supported endpoints, customer content is stored at rest in the selected region to the extent an endpoint needs persistence. Regional processing, where inference also runs in the region, is only available in certain regions and for certain endpoints. System data, such as account and billing information, is not covered. Non-US regions require approval for abuse monitoring controls and an amendment. Regional endpoints carry a price uplift for newer models, and requests go to a regional domain.

Three lessons from that description apply broadly:

1. Storage at rest and processing are different promises.
2. Not every endpoint or feature is covered.
3. Account and billing data may be handled elsewhere.

Map the real data flow

Draw the path of one request, from user to your app to the provider and back, and mark every hop:

• Your hosting region
• The provider endpoint and processing region
• Any fallback provider
• Logging and error tracking tools
• Vector database and file storage
• Support tools that receive pasted content

A regional model endpoint does nothing if your error tracker ships prompts to another continent.

What to get in writing

• Which region processes inference, and which stores data
• Which endpoints and features are excluded
• Whether abuse monitoring logs stay in region
• The transfer mechanism in the data processing addendum
• Sub-processor locations and the notice process. See what to publish about sub-processors.
• What happens when the provider adds a region or changes one

The addendum should also meet the other Article 28 points. See the DPA checklist for LLM API vendors.

Reduce what crosses the border

The simplest control is sending less. Redact names, identifiers and free-text fields that do not need to reach the model. Send an internal ID in place of an email address and map back after. Smaller, redacted prompts shrink the transfer question and the breach impact. See what log data to redact before sending to an LLM.

Document your decision

Record the data flow, the legal basis and your reasoning in your records of processing. If a customer asks, you can show how you decided. See the Article 30 records template.

Quick check

Sources

• GDPR Article 44: General principle for transfers
• GDPR Article 28: Processor
• Provider documentation: data controls and residency

Last reviewed: 19 October 2026.