> For the complete documentation index, see [llms.txt](https://handbook.harmonic.security/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://handbook.harmonic.security/handbook/4.-data-protection-and-residency/4.3-data-residency-and-regional-inference.md).

# 4.3 Data residency and regional inference

How to keep AI processing in-region using cloud model hosting and vendor-specific regional controls rather than assuming a plan setting solves residency.

*Last reviewed: August 18, 2026*

{% hint style="info" %}
Residency is a data-flow question. A region setting helps only if processing, storage, logs, support access, and subprocessors match the requirement.
{% endhint %}

## Data residency and regional inference: what security teams need to know

AI residency requirements often come from customer contracts, regulated industries, or local law. The model provider, cloud host, logging pipeline, and retrieval store may each have a different location story.

The safest way to document residency is a data-flow map. Show where prompts, files, embeddings, tool outputs, logs, eval data, and human support access go.

## Common data residency and regional inference security failures

* A team assumes an enterprise plan keeps inference in-region without checking endpoint behavior.
* Logs or telemetry leave the approved region.
* Files are stored in one region while inference occurs in another.
* A third-party connector moves data across borders.
* Support access and subprocessors are not included in the evidence pack.

## Data residency and regional inference security controls checklist

* Map processing, storage, logs, telemetry, support, and subprocessors separately.
* Prefer regional cloud endpoints when residency is a hard requirement.
* Document cross-border transfers and legal basis with counsel.
* Keep retrieval stores and vector databases in the same approved region where required.
* Review vendor retention and support-access terms before regulated rollout.

## Anthropic

### Overview

As of the last review date, Anthropic's first-party residency controls work at two levels. A per-request `inference_geo` parameter selects where inference runs — `global` by default, or `us` — and workspace-level `allowed_inference_geos` and `default_inference_geo` settings constrain what requests in a workspace may choose. Workspace geo, which governs where data is stored at rest and where endpoint processing happens, currently supports only `us` and cannot be changed after workspace creation, so check the current documentation before committing to storage in any other region.

The deployment route changes the mechanism: on Amazon Bedrock and Google Cloud Vertex AI, the inference region is determined by the endpoint URL or inference profile rather than the `inference_geo` parameter. Map Managed Agents separately because sessions persist state server-side. Map Cowork separately too: remote sessions and their files live on Anthropic's servers, and local files opened through Claude Desktop are processed there. Do not assume a Claude workspace region setting covers Cowork until the current documentation and contract say so.

### Anthropic documentation

* [Data residency (Claude Platform)](https://platform.claude.com/docs/en/manage-claude/data-residency)
* [Claude Managed Agents overview](https://platform.claude.com/docs/en/managed-agents/overview)
* [Claude Code data usage](https://code.claude.com/docs/en/data-usage)
* [Claude Cowork architecture overview](https://support.claude.com/en/articles/14479288-claude-cowork-architecture-overview)

### Applicable Harmonic guides for Anthropic

* [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide)

## OpenAI

### Overview

As of the last review date, ChatGPT Enterprise and Edu offer data residency — storage at rest — in Australia, Canada, Europe (EEA plus Switzerland), India, Japan, Singapore, South Korea, the UAE, the UK, and the US. Inference residency, meaning in-region GPU execution on customer content, is narrower: it is available only in Europe, the US, and the UAE, and requires data residency enabled in the same region. Even then, workspace metadata, billing information, and user logins may be stored outside the selected region, so the setting is not a complete data-flow answer on its own.

The API Platform is a separate control plane with its own residency model. ChatGPT Work also needs feature-level checking: OpenAI says Work inherits workspace protections, but residency and inference coverage varies by plan, region, surface, and capability. ChatGPT Sites is explicitly outside data residency at launch, including deployed sites, code, storage, generated artifacts, and related logs. Region and feature lists change, so verify them before making contract commitments.

### OpenAI documentation

* [Data residency and inference residency for ChatGPT](https://help.openai.com/en/articles/9903489-data-residency-and-inference-residency-for-chatgpt)
* [Data controls in the OpenAI platform](https://developers.openai.com/api/docs/guides/your-data)
* [ChatGPT Work Admin FAQ](https://learn.chatgpt.com/docs/enterprise/work-admin-faq)
* [Creating and managing ChatGPT Sites](https://help.openai.com/en/articles/20001339)

### Applicable Harmonic guides for OpenAI

* [Securing ChatGPT Enterprise Guide](https://www.harmonic.security/resources/securing-chatgpt-enterprise-guide)

## Frequently asked questions about data residency and regional inference

### What is data residency for AI?

It is the requirement that certain data is processed or stored only in approved regions, usually driven by customer contracts, sector regulation, or local law. For AI systems it splits into at least two questions: where inference runs on your content, and where prompts, files, and session state are stored at rest. Vendors document and sell these separately — OpenAI, for example, distinguishes data residency from inference residency — so treat them as separate controls.

### Does a regional endpoint solve residency?

Only for the inference leg of the flow. Logs, telemetry, retrieval stores, support access, and subprocessors can still cross borders, and vendor exceptions apply even inside the residency feature — ChatGPT data-residency workspaces may still store workspace metadata, billing information, and user logins outside the selected region. Map the full flow and get the exceptions in writing before certifying a deployment as in-region.

### What should a residency evidence pack include?

Include a data-flow diagram covering prompts, files, embeddings, logs, and support access; the vendor's residency documentation with capture dates; screenshots of the configured regions and settings; the subprocessor list; retention terms; and named control owners. Contract language and technical settings should point at each other. Refresh the pack when the vendor updates its region lists, which happens regularly.

### Are embeddings part of residency review?

Yes. Embeddings are derived from source content and can often be matched or partially reconstructed back to it, so regulators and customers generally treat them as the same data class as the source. Keep vector stores and retrieval indexes in the approved region and include them in the data-flow map.

### Who should approve residency decisions?

Hard residency requirements need security, legal, compliance, data governance, and the business owner in the same review, because the trade-offs cross all of them — a region constraint can rule out features or require contract amendments such as a ZDR addendum. Record the decision and its assumptions so it can be re-checked when vendor region support changes.

## Applicable regulations and frameworks

| Governance page                                  | Relationship to this article                                                                                                                 |
| ------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------- |
| G.1 Map your controls to NIST AI RMF and CSF 2.0 | This article supplies implementation evidence for the NIST AI RMF and matching NIST CSF 2.0 outcomes.                                        |
| G.3 DORA and AI resilience in financial services | Conditional: for a DORA-regulated workflow, this supports data protection, integrity, and third-party service review.                        |
| G.5 SANS Critical AI Security Guidelines mapping | This article implements relevant SANS Data Protection guidance.                                                                              |
| G.9 HIPAA controls for AI systems handling PHI   | Conditional: for ePHI, regional and subprocessor mapping supports risk and contract review; HIPAA does not itself require US data residency. |

*G.2, G.3, G.4, and G.9 are conditional mappings. They apply only when the deployment is within the legal or regulatory scope described on the linked governance page.*

## Related handbook guidance

* [4. Data Protection & Residency](/handbook/4.-data-protection-and-residency.md)
* [4.4 Retention and Zero Data Retention](/handbook/4.-data-protection-and-residency/4.4-retention-and-zero-data-retention.md)
* [G.3 DORA and AI resilience in financial services](/reference/governance-and-frameworks/g.3-dora-and-ai-resilience-in-financial-services.md)
* [G.9 HIPAA controls for AI systems handling PHI](/reference/governance-and-frameworks/g.9-hipaa-controls-for-ai-systems-handling-phi.md)
* [6.3 Compliance APIs by platform](/handbook/6.-observability-audit-and-evidence/6.3-compliance-apis-by-platform.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://handbook.harmonic.security/handbook/4.-data-protection-and-residency/4.3-data-residency-and-regional-inference.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.