Claude data residency for UK organisations: what you can and cannot keep in region

Provider terminology checked 14 October 2026: Anthropic now calls Google Cloud's service Agent Platform (formerly Vertex AI). Existing API identifiers and some source URLs retain the earlier name.

The first-party Claude API cannot keep your data in the UK or the EU. Anthropic's own documentation limits inference geography to us or global, and workspace geography, which governs data at rest, to the United States only. UK organisations that need in-region processing have to reach Claude through a partner cloud instead: AWS Bedrock or Google Cloud Agent Platform. Both carry a pricing premium, both drop a substantial list of features, and availability depends on the model and endpoint. The AWS table below was checked on 14 October 2026.

This guide is for the people who have to sign that decision off: compliance leads, data protection officers, IT directors and managing partners at UK firms in regulated sectors. Every product claim below is taken from Anthropic's, Amazon's, Google's or Microsoft's own published documentation and is dated, because this area is moving quickly.

It also sets out the point that saves most of the work: UK GDPR does not require personal data to be stored in the UK. Several residency requirements we are asked to design around turn out, on inspection, to be transfer-risk requirements wearing a residency costume.

Data residency and inference residency are not the same thing

Anthropic separates the two concepts, and conflating them is the most common error in this area. Data residency controls where prompts, outputs and conversation history are stored. Inference residency controls where Claude actually processes the request and generates the response. A deployment can satisfy one and not the other, and a procurement question that asks only about storage will miss half the picture.

Anthropic states that regional endpoints on the partner clouds guarantee that both data storage and model processing remain within the specified geographic region. That is the property regulated buyers are actually purchasing, and it is only available on the partner-cloud routes.

What the first-party Claude API offers, and what it does not

On the Claude API bought directly from Anthropic, the inference_geo parameter accepts two values: global, meaning the request may run in any available geography, and us. Anthropic's documentation is explicit under its current limitations: "Inference geo: Only 'us' and 'global' are available." There is no EU value and no UK value.

Workspace geography is more restrictive still. It governs data at rest and endpoint-side processing such as image transcoding and code execution, and Anthropic states that it "is set when you create a workspace and can't be changed afterwards. Currently, 'us' is the only available workspace geo." So even a US-pinned first-party deployment stores data in the United States, and the decision cannot be reversed later without a new workspace.

US-only inference also costs more. Anthropic prices it at 1.1 times the standard rate across every token category: input tokens, output tokens, cache writes and cache reads. Under a Priority Tier commitment, each such token draws down 1.1 tokens from committed throughput rather than one.

Three further constraints matter at implementation time. The parameter returns a 400 error on Claude Opus 4.5, Sonnet 4.5, Haiku 4.5 and earlier models. It is unavailable through the OpenAI SDK compatibility endpoint. And rate limits are shared across geographies, so pinning buys you no additional capacity. Workspace-level controls (allowed_inference_geos and default_inference_geo) can be set in the Console or through the Admin API, which is the practical way to stop a developer defaulting a workload back to global.

Claude Managed Agents supports an agent-level inference_geo setting and per-session overrides. As checked on 14 October 2026, the first-party options remain us or global, with US-only workspace storage. Managed Agents is unsupported on Bedrock and Google Cloud, so it has no UK or EU inference-pinning option on those routes.

The partner-cloud routes: what each one actually gives you

AWS Bedrock and Google Cloud Agent Platform are the two routes to genuine in-region deployment. Microsoft Foundry is a third platform but has no European option yet.

Route	UK or EU option	Premium	Key limitation
Claude API, first party	None. Inference us or global; storage US only	1.1x standard rates for US-only inference	Workspace geography is immutable once set
AWS Bedrock	Model- and endpoint-specific; see the dated table below	Anthropic states 10% over global rates for regional endpoints; confirm the selected model and route	Regional tables and programmatic endpoint details can conflict; confirm account access
Google Cloud Agent Platform	Yes. EU multi-region endpoint; single-region only up to Sonnet 4.6	10% over global endpoints	Newest models cannot be pinned to one region; EU multi-region excludes the UK
Microsoft Foundry	Not yet. The published options checked on 14 October 2026 do not commit to UK or EU inference	Not applicable	Global Standard, or US Data Zone Standard for eligible models hosted on Azure; Sonnet 5.5 is listed Global

Note that the premiums sit on different bases and should never be combined into a single figure. The 1.1x applies to first-party US-only inference. The 10% applies to regional endpoints on the partner clouds. What they have in common is the underlying point: on every route currently available, keeping Claude in a region costs more than letting it run globally.

AWS model and endpoint table, checked 14 October 2026

This table records the in-region availability symbols in AWS's model cards, linked by model. It is a documentation check, not an account-level deployment test. London means eu-west-2, Ireland eu-west-1 and Stockholm eu-north-1. A listing is not a guarantee about every data flow, storage, retention or support access.

Model and AWS source	bedrock-runtime: London	bedrock-runtime: Ireland / Stockholm	bedrock-mantle: Ireland / Stockholm
Claude Opus 5.5	Listed available; endpoint detail says N/A	Not listed	Not listed
Claude Sonnet 5.5	Not listed	Not listed	Not listed
Claude Haiku 5.5	Not listed	Not listed	Not listed
Claude Opus 5	Not listed	Not listed	Listed available
Claude Sonnet 5	Listed available; endpoint detail says N/A	Not listed	Listed available
Claude Opus 4.8	Not listed	Not listed	Listed available
Claude Opus 4.7	Not listed	Not listed	Listed available
Claude Sonnet 4.6	Listed available; endpoint detail says N/A	Not listed	Not listed
Claude Opus 4.6	Listed available; endpoint detail says N/A	Not listed	Not listed
Claude Haiku 4.5	Not listed	Not listed	Listed available
Claude Fable 5.1	Not listed	Not listed	Not listed
Claude Fable 5	Not listed	Not listed	Not listed

Documentation conflicts. Anthropic's Bedrock guide, read on the same date, lists London as Global and EU, while Ireland and Stockholm list Global, EU and In-region only. These are several route types, not a statement that those regions exclusively support in-region inference. AWS distinguishes bedrock-runtime from bedrock-mantle and lists London in-region availability for four models above. Opus 5.5, Sonnet 5, Sonnet 4.6 and Opus 4.6 all have an internal AWS conflict on bedrock-runtime: their regional tables mark London available while the programmatic in-region endpoint field says N/A. Obtain confirmation for the exact account and route before relying on any of these entries.

An EU profile is not a universal EU-only promise. AWS's destination lists depend on the source region. For the Claude Sonnet 5 geographic profile checked on 14 October 2026, a London source includes London and a Zurich source includes Zurich; Ireland and Stockholm source rows list EU destinations. Retrieve the current destination set with GetInferenceProfile from the intended source region. The prefix alone does not settle the transfer assessment.

On Google Cloud, which Anthropic's documentation now calls Google Cloud's Agent Platform, the constraint is different but no less awkward: Anthropic states that specific regional endpoints support Claude Sonnet 4.6 and earlier, while newer models use the global or multi-region endpoints. If you want a current model such as Claude Opus 5.5 or Sonnet 5.5, single-region pinning is not available to you. The strictest option is the EU multi-region endpoint, and the EU multi-region does not include the United Kingdom.

What in-region deployment costs you in features

The premium is the visible cost. The feature losses are the one that derails projects after the contract is signed, because they are usually discovered during build rather than during procurement.

Feature support checked 14 October 2026: Anthropic lists structured outputs, Files API and URL inputs, server-side tools, Agent Skills, the MCP connector, programmatic tool calling, Message Batches, Models, Admin, Compliance, Usage and Cost APIs, Managed Agents and server-side fallback as unsupported on Bedrock. Google Cloud supports web search and structured outputs, but lists the other named features as unsupported. Check each platform's current feature list for the model and API you intend to use.

Read that list against your intended architecture before you choose a route. A workflow designed around the MCP connector and Agent Skills, which is a common shape for internal knowledge assistants, does not survive a move to Bedrock without redesign. If connecting Claude to business systems is central to your plan, our guide to connecting Claude to business systems sets out what that layer normally involves.

There is a compensating benefit worth naming, because it is the substantive thing regulated buyers are buying. Anthropic states that Claude on Bedrock "runs on AWS-managed infrastructure with zero operator access", meaning Anthropic personnel have no access to the inference infrastructure. For a firm whose concern is third-party operator access rather than geography as such, that property may matter more than the region label.

What UK GDPR actually requires, which is not what most briefs assume

UK GDPR does not require personal data to be stored in the United Kingdom. It regulates restricted transfers, which the ICO defines as making personal information accessible to a separate organisation outside the UK. A restricted transfer is lawful where it rests on adequacy regulations, on appropriate safeguards such as the UK International Data Transfer Agreement or the Addendum to the EU Standard Contractual Clauses, or on a derogation. Where a safeguard is relied on, a transfer risk assessment is required.

This distinction is worth several weeks of project time. A requirement expressed as "our data must stay in the UK" is frequently, on examination, a requirement that the transfer be properly assessed and contractually covered. That is a different and usually cheaper problem, and it does not necessarily push you onto a partner cloud at a 10% premium with a truncated feature set.

On the contractual side, Anthropic's Data Processing Addendum contains a dedicated UK Addendum at Schedule 3, Part B, applying to processing subject to UK GDPR and layered on the EU Standard Contractual Clauses, with reasonable advance notification of new sub-processors and a 15-day objection period. That is the instrument a UK transfer risk assessment would be built around. Our guide to whether Claude is GDPR compliant covers the wider retention and training position plan by plan, and the briefing on the Data (Use and Access) Act 2025 covers the automated-decision rules that sit alongside.

How to decide, in practice

A workable sequence for a UK firm, in the order that saves the most wasted effort:

• Establish whether you have a residency requirement or a transfer requirement. Ask what the requirement is protecting against and where it came from. If it originates in a client contract, read the clause: many specify safeguards rather than geography. This one question decides the rest.
• If it is genuinely residency, decide between storage and processing. The partner-cloud regional endpoints cover both. Nothing else does.
• Check your model requirement against the route before you commit. If you need the newest Opus or Sonnet models on Google Cloud, single-region pinning is off the table.
• Check your feature requirement against the unsupported list. Do this before contract, not during build. The MCP connector, Agent Skills and the Files API are the ones that most often turn out to be load-bearing.
• Price the premium honestly. Add 10% to the token line for regional endpoints, or 1.1x for first-party US-only, and carry it into the business case rather than discovering it in month two.
• Write the transfer risk assessment against the actual region list. For a Bedrock cross-region profile, retrieve the destination set from the intended source region; do not infer it from the EU prefix.

What not to do: do not specify "AWS London" without the model, endpoint and verified routing configuration. Do not assume the EU multi-region endpoint covers the UK, because it does not. And do not let a residency requirement be adopted into a project charter without anyone checking whether UK GDPR actually imposes it, because more often than not it does not.

Where The AI Consultancy fits

Establishing whether a stated residency requirement is real, choosing between the routes, and pricing the premium and the feature losses honestly is the analysis stage of our Claude implementation engagements. For firms in regulated sectors the same question usually arrives alongside a wider governance review, which our AI readiness assessment covers, and our guide to Claude for UK financial services sets out how it lands under FCA expectations. Where the answer is that no cloud route satisfies the requirement, the private AI concierge service covers on-premises deployment instead.

The AWS model and endpoint table and Anthropic Bedrock guide were checked on 14 October 2026. Other provider options must be confirmed for the named model, endpoint and contract before procurement. The table records published availability, not a live deployment test. This article is general information; confirm the legal position for your processing with a qualified adviser.