The short version
Residency is decided by four separate things — model inference, retrieval index, logs and telemetry, and human review. Pin each one explicitly; a single unpinned component is what breaks an otherwise EU-only deployment.
Every enterprise AI security review eventually reduces to one question: does any personal data leave our region, and can you prove it? Vendors answer with a region name. That is not an answer, because a typical retrieval-augmented system has at least four places data comes to rest.
The four places to pin
| Component | What sits there | Common mistake |
|---|---|---|
| Model inference | Prompt, retrieved excerpts, output | Regional endpoint for the main model, global endpoint for the small 'helper' calls |
| Retrieval index | Document chunks and embeddings — often the most sensitive copy | Treated as derived data and left in a default region |
| Logs and telemetry | Prompts and outputs in traces, error reports, analytics | Observability vendor outside the region |
| Human review | Whatever a reviewer or annotator sees | Offshore review queue nobody documented |
Embeddings deserve particular attention. They are derived, but they are derived from personal data and can carry it; the EDPB's opinion on AI models discusses when model-related data should still be treated as personal data. Treat your index as in-scope by default and make anyone arguing otherwise write down why.
The paperwork that actually gets asked for
- —A data-flow diagram naming every processor and its region.
- —A DPA with sub-processor list and change notification.
- —A DPIA where processing is likely high risk — the EDPB publishes a template and guidance on when one is required.
- —Retention rules per store: prompts, outputs, traces, index, evaluation datasets.
- —A statement, contractual not verbal, that your data does not train shared models.
Design choices that make residency easy
- —Redact before you retrieve: strip identifiers at ingest where the workflow does not need them.
- —Keep the index inside your own tenancy, so the sensitive copy never moves.
- —Log references, not payloads, where the audit trail allows it — store document IDs and hashes plus a retained excerpt.
- —Use a small self-hosted or on-device model for the high-volume steps, keeping frontier calls for the rare hard cases.
- —Prefer providers whose regional endpoints cover every model you plan to use, including the cheap ones.
Fully offline is a real option, not a fallback. Document extraction and edge inference both run with no external network at all, which turns a long residency negotiation into a short one.
What we would do in a pilot
A one-page data-flow diagram for your workflow, a residency decision per component, and DPIA-ready documentation produced alongside the build — plus an on-premise variant costed if the review demands it.
Sources
- 01Opinion 28/2024 on data protection aspects of AI models — European Data Protection Board
- 02Guidelines on Data Protection Impact Assessments (high-risk processing) — European Data Protection Board
- 03Template for Data Protection Impact Assessment — European Data Protection Board
Figures drawn from our own engagements elsewhere on this site are illustrative placeholders. Anything attributed above links to its public source.