Skip to content
Compliance · 10 min read

GDPR & data residency for LLM inference

GDPR applies to any organization that processes personal data of people in the EU, regardless of where the company is incorporated. When that processing includes LLM inference — prompts that contain names, emails, identifiers or customer records — the controller-processor relationship, cross-border transfer rules and data residency all come into play at once.

Elena Vasquez
Compliance Lead

This is practical guidance, not legal advice. Work with your DPO and counsel on your specific GDPR obligations.

Controller, processor and the DPA

Under GDPR, your organization is almost certainly the controller — you decide the purposes and means of processing. Your inference provider is the processor — it handles data on your documented instructions. That relationship is governed by a Data Processing Agreement (DPA) , which must specify the subject matter, duration, nature and purpose of processing, the type of personal data involved and the categories of data subjects. A DPA isn't a nice-to-have; it is Article 28's binding instrument. If your vendor can't produce one that your DPO is comfortable signing, they can't process EU personal data on your behalf.

Cross-border transfers — SCCs and the Schrems II legacy

When personal data leaves the EEA, GDPR requires a valid transfer mechanism. Since Schrems II invalidated Privacy Shield in 2020, the primary tool for most organizations has been Standard Contractual Clauses (SCCs) , paired with a Transfer Impact Assessment (TIA) . The TIA evaluates whether the law and practice of the destination country provide a level of protection essentially equivalent to that within the EU. An inference provider operating US-based infrastructure must offer SCCs as a baseline, but the TIA is your responsibility — you need to document and assess the risks, including whether US surveillance law could compromise the data in transit or at rest.

Why region pinning cuts through the complexity

The cleanest way to avoid the entire cross-border-transfer problem for EU personal data is simple: keep it in the EU. Region-pinned inference — routing your prompts and completions exclusively through data centers in Ireland or Frankfurt — means the data never leaves the EEA. No SCCs to negotiate, no TIA to write, no surveillance-law analysis. For organizations that want to avoid cross-border transfer risk entirely, in-region processing is the most defensible posture available.

  • Ireland (eu-west) and Frankfurt (eu-central) both fall within the EEA, keeping processing inside GDPR's territorial scope.
  • Regional isolation means no failover to US regions — your data stays pinned to the jurisdiction you choose.
  • Contractual region commitment in the DPA reinforces the technical control with a legal obligation.

Subprocessor transparency

Article 28 requires the controller to authorize every subprocessor the processor engages. Your DPA should list all subprocessors, their locations, and what they do. Before signing, ask whether any subprocessor outside the EEA touches personal data — if so, the transfer mechanism must extend to them as well. A provider that limits subprocessors to metadata-only operational functions (monitoring, billing, orchestration) keeps the processing chain narrow and the authorization burden light.

How zero retention shrinks your processing footprint

Every byte of personal data your inference provider stores is a byte you have to account for in your GDPR documentation, your data-retention schedule and your breach-notification plan. Zero data retention — where prompt content exists only in volatile GPU memory for the duration of a single request — eliminates that entire category of stored data. Combined with in-region processing, you can document that personal data at the inference layer is processed transiently, within the jurisdiction, under a DPA, with no persistent storage. That is about as narrow a processing footprint as Article 5's data-minimization principle allows.

Questions to ask your inference vendor

  • Is a DPA available as a signed contract, not just a policy page? Does it specify subprocessors, their locations and the data each one touches?
  • Can you region-pin to Ireland or Frankfurt, with that commitment spelled out in the DPA?
  • Are SCCs provided for any transfers outside the EEA? Has a TIA been prepared?
  • Is prompt or completion content ever written to disk, logged, or transmitted outside the inference region?
  • How is the processor handling breach notification under Art. 33 — and can it do so within 72 hours when it holds no prompt content to lose?

A quiet requirement becoming a loud one

Three years ago, GDPR questions in a vendor procurement were a checkbox. Today they're a gate. Compliance teams are asking about SCCs, DPAs and data residency before they approve any AI tool that touches personal data. The vendors that can answer those questions in contract language — not marketing language — are the ones that get approved. The EU AI Act only raises the bar further, layering AI-specific governance on top of the data-protection baseline GDPR already requires. If your inference infrastructure already meets both, you're ahead of the procurement curve. For a closer look at the full zero-retention posture that supports it, talk to an engineer.

Run this privately, in your own environment

A solutions engineer will scope a zero-retention deployment for your models and volume.

Talk to an engineer