# An EU region is not a data boundary **Summary:** Picking an EU cloud region fixes where data sits at rest, and almost nothing else. What decides sovereignty is what a component can see, not where it runs. **In short:** The vendor questionnaire has a comforting checkbox: EU data residency. Here is why that checkbox proves far less than it seems to, and the questions that actually decide whether your data stays under your control. **Published:** 2026-07-03 There is a checkbox on every vendor questionnaire in regulated Europe, and it is doing far more comforting than it has earned: "data stored in an EU region." Tick it, and the sovereignty question feels answered. It is not. An EU region fixes one thing: where your data sits at rest. Support access, telemetry, sub-processor chains, and model calls can all cross that line unless someone engineered them not to. The axis that decides sovereignty is what a component can see, not where it runs. ## The comforting checkbox Residency is having a moment. The European Commission is pushing its [tech sovereignty package](https://ec.europa.eu/commission/presscorner/detail/en/ip_26_1187), commentators keep pointing out that [AI is deepening Europe's dependence on US hyperscalers](https://www.techpolicy.press/how-ai-keeps-europe-hooked-on-us-cloud/), and every cloud provider now sells an "EU region" as the answer. ASEE made the point sharply in a [June piece on EU cloud regions for banks](https://asee.io/blog/eu-cloud-region-bank-data-stays-europe/): a region pins down primary storage, and little else. Procurement teams feel this pressure and reach for the checkbox. It is easy to verify, easy to compare, and easy to report upward. The problem is that it measures the wrong thing. ## What actually crosses the line Think about what touches your data after it lands in that EU region. Support engineers may access it from anywhere in the world when they debug an incident. Telemetry and usage metadata often flow to systems that were never scoped to a region. Then come the chains. Your vendor's sub-processors have sub-processors, and each hop is a new place where data can be seen. And if the product uses AI, every model call is a data flow in its own right - the question is what the model receives, not where the datacenter sits. Residency theater is treating the region label as if it settled all of this. It settles none of it. A vendor can be perfectly resident and still leak identifiers through four side doors. ## The axis that decides European case law has started drawing the line in a more useful place. In [EDPS v SRB](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A62023CJ0413) (September 2025), the Court of Justice held that pseudonymized data is not automatically personal data for every party in the chain: for a recipient who has no reasonable means of re-identifying the individuals, it may fall outside the definition entirely. What a party can see and recover decides its status - not where it runs, and not who operates it. That flips the sovereignty question. Two components can run in the same AWS region and hold opposite positions in the processing chain, because one sees raw identifiers and the other sees only tokens it cannot reverse. Location tells you nothing about which is which. So the question for any AI vendor is not "which region?" It is "what does each component in your chain actually see?" ## How we build for it Here is how UNLESS answers that question, gap included. Personal data is filtered and tokenized at the gateway, before anything reaches a third-party generative model. The model sees safe placeholders, and the token vault stays with us, so the provider cannot reverse it. We do not claim that no third party ever touches personal data. The PII-detection step reads raw input before filtering, so it is a sub-processor, and it is listed as one. The honest claim is narrower and stronger: raw personal data never reaches the third-party generative models. And the infrastructure caveat, stated plainly: we run on AWS EU regions today, so we do not yet meet the European baseline we believe in. We intend to move to AWS European Sovereign Cloud once it supports the technology we depend on. That is a direction of travel, not a shipped fact. ## The steelman Is the EU region checkbox worthless, then? No - residency is necessary, just not sufficient. Keeping data at rest inside EU jurisdiction matters for legal process, latency, and the baseline goal of a European cloud stack, and we agree with the direction of that goal. The mistake is stopping there. A checkbox that is necessary but not sufficient becomes dangerous the moment it is treated as sufficient, because it closes the discussion exactly where the real questions begin. ## The checklist to run on any vendor Us included. Put these to every AI vendor on your shortlist: - Where do support engineers connect from, and what can they see when they do? - What telemetry, logs, and metadata leave the region, and where do they go? - List every sub-processor - and for each one, what data it can see, not just where it runs. - For every AI model call: what does the model receive? Raw identifiers, or tokens it cannot reverse? - Who holds the token vault or pseudonymization keys, and can the model provider re-identify anything? - If a customer invokes erasure, can you actually reach every copy - including whatever reached your models? A vendor with real data-flow control will answer these in writing without flinching. A vendor selling residency theater will steer you back to the checkbox. ## What changes if you accept this The region label stops being the finish line and becomes the starting point. Your questionnaire gets one column longer: not just "where does it run," but "what can it see." That single column is where sovereignty is actually decided - and it is a question every vendor should be glad to answer.