UK or EU data residency for AI: what actually changes

For UK GDPR purposes, EU hosting is usually fine. A UK to EEA transfer is a restricted transfer, but UK adequacy regulations cover it, so no transfer risk assessment is needed. The UK/EU distinction bites in procurement, not in law: public sector OFFICIAL work, financial services security reviews, and client contracts that specify the UK.

We sell UK residency, so read the rest of this with appropriate suspicion. The reason we are writing it anyway is that the alternative — implying EU hosting is unlawful — is both false and easy for any competent DPO to dismantle in about ninety seconds. Better to be precise about the narrow band where the distinction genuinely earns its price.

What changed at Brexit, in plain terms

Before 2021, moving personal data from Manchester to Frankfurt was an internal EU movement. It was not a transfer in the restricted sense at all, because both ends sat inside the same regulatory perimeter.

After Brexit, the UK became a third country from the EU's perspective, and the EEA became a third country from the UK's. Every UK to EU data movement is now, technically, a restricted transfer. That sounds alarming and mostly isn't, because the UK government made adequacy regulations covering the EEA. The transfer is restricted; it is also adequate. Adequacy is a complete answer to the transfer question.

The practical consequence for anyone assessing an AI vendor:

• UK to EEA — restricted transfer, covered by adequacy regulations, no Article 46 safeguard needed, no transfer risk assessment needed.
• UK to UK — not a transfer at all. Nothing to assess, because there is nothing to assess.
• UK to US on standard contractual clauses — restricted transfer, Article 46 safeguard, and the ICO expects the exporter to complete a transfer risk assessment. The exporter is you, not the vendor.

Note the shape of that list. The gap between UK and EU hosting is the difference between "no assessment required" and "no assessment required". The gap between either of them and an SCC-backed US API is where the paperwork actually lives.

The bit most buyers miss: EU residency is still a cross-border transfer

Here is the nuance that almost nobody puts in writing. When a vendor offers you "EU data residency", they are offering an adequate transfer, not the absence of a transfer.

That distinction is invisible in your risk register and highly visible in three places:

1. Your record of processing activities. ROPAs typically carry a field for country or countries of processing. "Ireland, Germany, France" is a legitimate entry. It is also an entry a reviewer will read, and reading it costs someone time.
2. Adequacy is a political instrument, not a physical fact. UK adequacy regulations for the EEA exist because the government decided they should. Nothing here is currently broken, but "our compliance position depends on an adequacy finding remaining in place" is a materially different sentence from "the data does not leave the jurisdiction".
3. Sub-processor mapping. An EU region is one country. An EU inference profile on AWS Bedrock is not — more on that below.

None of this makes EU hosting wrong. It makes "EU residency" and "UK residency" two genuinely different statements, which is the thing that gets flattened in most vendor marketing.

Does the distinction actually matter? A scenario table

The pattern: every "yes" in that table is procurement, sector policy or contract. Not one of them is UK GDPR itself.

The procurement reality

Compliance teams do not optimise for what the law strictly permits. They optimise for the number of questions they have to answer, and for how defensible the answer looks eighteen months later to someone who was not in the room.

That is why the UK answer wins deals it does not legally need to win.

Questionnaire friction. A security questionnaire is a sequence of gates. "United Kingdom" passes the location gate silently. "European Union" passes it too, and then generates supplementary questions about member state, sub-processor list, adequacy status and onward transfer. Both outcomes are lawful; only one of them is finished on Tuesday.

Requirement inheritance. If you serve a bank, a council or an NHS trust, your obligations are largely inherited from their policies rather than derived from statute. Arguing that UK GDPR permits Dublin is correct and useless when the buyer's third-party policy says UK.

Documentary asymmetry. For UK processing you can produce a processing location attestation naming the region and the sites, and there is nothing further to explain. For EU processing you produce the same attestation plus an adequacy explanation. Reviewers are not hostile to the second document. They are just slower with it.

If you are evaluating Bedrock specifically, ask this one question

Whoever your AI vendor is, ask whether they invoke a bare model id or a cross-region inference profile, and get the answer in writing.

A bare Bedrock model id is served in the region you addressed. A cross-region inference profile prefixed eu. may be served by any region in that geography — AWS documents the EU profile as spanning Dublin, London, Paris, Frankfurt, Stockholm, Milan and Madrid. A global profile may be served anywhere AWS operates, including the United States.

So "we use EU Bedrock" can mean a single named region, or it can mean seven countries with routing decided by capacity. Both are lawful under UK adequacy. Only one of them is a sentence you can put in a ROPA without a footnote. And a global profile is not an EU residency claim at all, whatever the marketing page says.

For our own UK tier we use bare model ids only. Requests are invoked in-region against bedrock-runtime.eu-west-2 in AWS Europe (London), and the inference does not leave the UK. Our route resolver throws rather than downgrading, so a UK-tier request that cannot be served in London fails closed instead of quietly routing elsewhere. Verified by live one-token probe on every configured route on 3 August 2026, covering Claude Sonnet 4.6 and Claude Opus 4.6.

You can also do this yourself. Bedrock in London is self-serve and standing it up is roughly an afternoon's work for a platform engineer. What sits on top — pseudonymisation before the prompt leaves your estate, per-client metering, an audit log in a form you can hand to a client, GBP invoicing, an attestation naming your sites — is the part we actually sell.

The honest close

Work down this list. If you answer no to all of it, buy on price, latency and engineering quality rather than on residency:

• Do you handle public sector data at OFFICIAL, or bid for work that does?
• Does a regulated client's security review ask specifically for a UK answer?
• Does any contract you have signed specify UK processing?
• Do your supply-chain questionnaires stall when the answer is "EU"?
• Are you currently calling a US API under standard contractual clauses without a completed TRA?

If none of those apply, EU hosting is a reasonable and lawful choice, and we will tell you so on a call. The residency argument is narrow. Pretending it is broad is how vendors hand their best objection to the next supplier in the room.

dijitul Ltd is not a law firm and this is not legal advice. Documents we provide are drafts for your own adviser to review and adopt.

This is general information about how the rules work, not legal advice about your circumstances. If a decision turns on it, take advice.