Data residency explained — why “not sent abroad” is two promises

Glossary entry 11. After entry 10 on training restrictions, this entry drills into requirement ④ of the four data-protection requirements: data residency — not sent abroad. “We don't use overseas regions, so the data never leaves the country” and “we can pick a region, so we're covered” are both only half true. The reason is that residency is two separate questions: where data is stored at rest, and where inference is processed. This page builds a table that keeps those two columns apart across AWS Bedrock, Microsoft Foundry, Google Cloud, OpenAI and Anthropic, and quotes their own wording — including who fixes which setting, and when.

“Not sent abroad” is really two promises: where data is stored, and where it is processed.

OpenAI publishes data residency as separate Storage and Processing columns per region, and Japan is storage-capable but processing-incapable — i.e. stored in country, inferenced elsewhere. AWS decides with inference profiles, Google with endpoints, Microsoft with deployment types, Anthropic with inference geo plus workspace geo. In all five, storage and processing are separate items to check (the mechanism differs by provider). Checking one and concluding “it never leaves” is the most common mistake.

● Last updated:  |  Policy: only content we could confirm verbatim in each vendor's official documents. Settings we could not confirm are marked unverified

Why “not sent abroad” splits into two questions

Even for the same prompt, the place it is kept and the place it is computed are different. There are four branches.

Branch ①

Where data is stored at rest

Which region's facilities hold the data written to disk. Most providers state this is pinned to the region you designate. This is usually the easier half to secure.

Branch ②

Where inference is processed

Which region's compute actually runs the request. “Anywhere (global)” is the default in several configurations, so a misconfigured setting means processing abroad.

Branch ③

“Available” versus “pinned”

Having a region option is not the same as running there. The pinning unit differs: deployment type / profile / endpoint / project setting / workspace setting.

Prerequisite

④ satisfied does not satisfy ①–③

Residency (not sent abroad) is a different promise from retention (not stored), access (not seen) and training (not learned from). → four requirements

“Not sent abroad” splits into storage and processing The same prompt and response have two separate promises: storage at rest is where the data is kept, processing is where inference runs. Pinning storage to a region does not pin processing. All five providers publish storage and processing separately. “Not sent abroad” is two promises Same data — but where it is kept and where it is computed are set separately. Your prompts and responses Identical content, two different promises ① Storage (at rest) — where data is kept Switched by region or data zone. Usually pinned to the location you choose This is the half that country requirements ask about first ② Processing (inference) — where it runs Switched by endpoint, inference profile or a setting Often defaults to “anywhere / global” — this is what gets missed Pinning storage in country does not pin processing. OpenAI Japan: storage yes, processing no. All five providers publish the two as separate items. So record which layer and which setting you pinned, or you cannot answer an audit.

Figure: storage and processing are separate promises. Pinning one leaves the other on its default (created by LLM Data Hub).

The answer up front: five providers split by storage and processing

Confirmed from official documentation as of 2026-10-05. The key point is that storage and processing sit in separate columns.

Data residency compared across five providers, split into storage and processing
Provider① Storage (at rest)② Processing (inference)
Microsoft
Azure / Foundry		 For all deployment types, “Data stored at rest remains in the designated Azure geography.” Three layers. Global = may be processed in any Azure region / Data Zone = within the data zone (US, EU, APAC) / Standard & Regional = within the customer-specified geography, and may move between regions inside it. The Developer tier carries no data-residency guarantee
AWS
Amazon Bedrock		 Stored at rest in the AWS Region where you use Bedrock (with cross-Region inference, in the destination Region) Chosen by inference profile. Geographic = within US / EU / APAC boundaries; Global = any supported AWS commercial Region worldwide. AWS itself recommends Geographic for compliance
Google Cloud Pinned to the location you chose — “independent of the Agent Platform endpoint called” Chosen by endpoint. Jurisdictional multi-region = inside that region (US, EU); global = “they don't provide regional isolation or data residency guarantees”
OpenAI
first-party API		 A per-project setting. With supported endpoints, customer content is stored at rest in the selected region Storage and Processing are decided separately per region. Japan, UK, Canada and others are storage yes / processing no. Non-US regions need approval for abuse monitoring controls plus a Modified Retention amendment (UAE needs extra approval)
Anthropic
first-party API		 Workspace geo — set when the workspace is created, cannot be changed afterwards; currently "us" only Inference geo — defaults to "global", can be set to "us" per request or as a workspace default. US-only inference is priced at 1.1x (Claude 4.6 and later models)

← Scroll horizontally. “Unverified” means we could not confirm it in primary sources — not that the guarantee is absent.

Branch ① Where a provider publishes the two separately (OpenAI)

This is the clearest example. OpenAI lists Storage and Processing as separate columns per region, which means “stored in country, processed abroad” is an officially documented combination.

“If you select a region that supports regional processing, as specifically identified below, the services will perform inference for your Customer Content in the selected region as well.” — OpenAI, “Data controls in the OpenAI platform” (retrieved 2026-10-05)
“Support for regional storage does not imply support for regional processing.” — Same document (retrieved 2026-10-05)
  • Some regions you can pay for are storage-only. In the official table, the United States, Europe (EEA + Switzerland) and the UAE are storage and processing, while Japan (jp.api.openai.com), the UK, Canada, Australia, India, Singapore and South Korea are storage yes / processing no. “There is a Japan region” does not mean “inference happens in Japan”.
  • Non-US regions require approval. Verbatim: “To use data residency with any region other than the United States, you must be approved for abuse monitoring controls, and execute a Modified Retention amendment.” Residency here is not a self-service toggle.
  • Selecting the UAE requires additional approval — conditions differ by region, so a list of supported regions is not enough on its own.
  • The unit of configuration is the project. “To configure data residency for regional storage, select the appropriate region from the dropdown when creating a new project.” It is chosen at creation, not retrofitted, so you have to record who created which project where.

Branch ② In the clouds, the setting decides between three layers (Microsoft / AWS / Google)

Cloud providers share a shape — storage pinned, processing selectable — but the unit and the number of layers differ.

“Data residency for all deployment types: Data stored at rest remains in the designated Azure geography. However, inferencing data is processed as follows: Global types: May be processed in any Azure region / Standard and Regional Provisioned types: Prompts and responses are processed within the customer-specified Azure geography and might be processed between regions within that geography for operational purposes.” — Microsoft Learn, “Understanding deployment types in Microsoft Foundry Models” (retrieved 2026-10-05)
  • Microsoft splits processing three ways by deployment type: Global (any Azure region), Data Zone (inside the US / EU / APAC data zone) and Standard or Regional (inside the customer-specified geography). The choice is made by the customer and it also changes the price, so the same model has three price points.
  • “Between regions within that geography” survives. The wording says processing “might be processed between regions within that geography for operational purposes”, so a geography-level pin may not satisfy a country-level requirement. The EU follows the Azure EU Data Boundary, which can include EFTA countries such as Norway and Switzerland.
  • AWS decides with the inference profile. Its table gives Data residency as Geographic = “Within geographic boundaries (such as US, EU, and APAC)” and Global = “Any supported AWS commercial Region worldwide”, with the recommendation “Choose Geographic for compliance requirements”. It also states that data in cross-Region operations stays on the AWS network and does not traverse the public internet.
  • Google Cloud decides with the endpoint. At rest, “Data stored at rest in the customer selected location remains at rest in that location, independent of the … endpoint called.” For processing, jurisdictional multi-region endpoints keep ML processing inside that region, while global endpoints “route and process data anywhere globally” and “don't provide regional isolation or data residency guarantees”. Checking that you are not on a global endpoint is the practical test.
  • There are exclusions. Google's data residency terms list services outside the commitment, including Grounding with Google Search, Web Grounding for Enterprise, Grounding with Google Maps and RAG Engine. Being in the same project does not put every feature inside the commitment.

Branch ③ On a first-party API the menu can be shorter (Anthropic)

Anthropic manages this with two independent settings, and it is the clearest example that “pick your region” is not unlimited.

“Two independent settings govern this: Inference geo: Controls where model inference runs, on a per-request basis. Set through the inference_geo API parameter or as a workspace default. Workspace geo: Controls where data is stored at rest and where endpoint processing (such as image transcoding and code execution) happens. Configured at the workspace level in the Claude Console” — Claude Platform Docs, “Data residency” (retrieved 2026-10-05)
  • The only values are "us" and "global". Inference geo defaults to "global" (“Inference may run in any available geography”) and "us" restricts inference to US-based infrastructure. There is no EU option on the first-party API, so EU requirements are met through partner platforms instead.
  • Workspace geo is fixed at creation and cannot be changed. “Workspace geo is set when you create a workspace and can't be changed afterward. Currently, "us" is the only available workspace geo.” Some settings cannot be switched later, which is exactly why they belong in contract review.
  • US-only inference costs 1.1x (Claude 4.6 and later models). “Claude 4.6 and later models: US-only inference (inference_geo: "us") is priced at 1.1x the standard rate across all token pricing categories”, while global routing uses standard pricing. Where data lives shows up on the bill.
  • Partner platforms are handled separately. “On Claude in Microsoft Foundry, the same 1.1x multiplier applies to deployments hosted on Azure that use the US Data Zone Standard deployment type. Partner-operated platforms (Bedrock and Google Cloud) have their own regional pricing.” The same model therefore has different regional options and prices depending on the path you use. Regional data residency is offered across Europe, the United States, Canada and Asia-Pacific (including Japan, South Korea, Singapore, India and Australia) — on the partner platforms.

“Not sent abroad” is a different promise from not stored, not seen and not trained on

  • Pinning storage in country is not “not used for training”. OpenAI's residency page governs where data is stored and processed; training terms live in a different document — and non-US regions additionally require a Modified Retention amendment. Check it together with no-training.
  • Pinning storage is not “staff cannot see it”. Approval workflows and key management (CMK / BYOK / HYOK) are separate mechanisms. → ZOA (not seen)
  • Pinning processing is not “nothing is retained”. A guarantee about where processing happens says nothing about how long data is kept. → ZDR (not stored)
  • Read them side by side: the four requirements, ZDR, ZOA, no-training.

A four-step check

  1. Ask storage and processing as two questions. “Where is data stored?” is not enough. Ask “in which region is inference executed?” separately. Splitting the question changes the answer at several providers.
  2. Identify the setting that pins it. Deployment type, inference profile, endpoint, project setting, workspace setting — the unit differs by provider, and naming the unit also names who configured it.
  3. Check whether “anywhere” is still in play. Global endpoints, global profiles, Global deployments, a default of "global" — the default can be the anywhere option, so confirm that a region was explicitly selected.
  4. Confirm it in the contract and write it down. A settings page is not a clause. Record which layer, which setting and which region, together with the clause you verified. That record is what disappears when people change teams.

Four common misconceptions

Misconception 1

“You can pick a region, so nothing leaves the country”

Available is not the same as pinned. Defaults are frequently “anywhere / global”, and only an explicit selection pins them.

Misconception 2

“Storage in country means processing in country”

OpenAI's Japan region is storage yes / processing no, and Microsoft's Global deployment type “may be processed in any Azure region”. Processing has its own setting.

Misconception 3

“Residency support means no training”

Location and training are governed by different documents. Meeting residency does not meet the training requirement. → no-training

Misconception 4

“A Japan region means processing happens in Japan”

First-party API regions are sometimes storage-only. On Anthropic's first-party API you cannot even select the EU.

Questions

Is data residency the same as data sovereignty?
This page keeps them apart. Residency is the promise about where data is stored and processed; sovereignty is the wider question of which country's law applies to it. Keeping data in country does not, by itself, tell you the reach of the provider's home jurisdiction.
Is “we selected a region” enough to tell an auditor?
No. Say which of the two you pinned — storage, processing, or both. On cloud platforms processing can extend “between regions within the geography”, so a country-level requirement may need a different configuration entirely.
Does residency change the price?
It can. Anthropic prices US-only inference at 1.1x (Claude 4.6 and later models), and Microsoft prices deployment types differently (Global, Data Zone, Standard). Residency is a configuration choice and a pricing choice.
When a row says “unverified”, does that mean there is no guarantee?
No — it means we could not confirm it in primary sources. Where we could confirm only part of a picture (for example Google's list of excluded services), we publish only what we verified. Always check the provider's current documentation before you commit.

Sources