OpenAI adds regional data residency for API, Enterprise, and Edu customers across ten markets

What OpenAI actually turned on

OpenAI now lets eligible business customers store customer content at rest in a chosen region. The list covers Europe, the United Kingdom, the United States, Canada, Japan, South Korea, Singapore, India, Australia, and the United Arab Emirates, with more regions promised over time.

The feature applies to three products: ChatGPT Enterprise, ChatGPT Edu, and the API Platform. The company frames this against a base of over 1 million business customers using OpenAI directly.

For ChatGPT Enterprise and Edu, residency is set at workspace creation. Stored content includes conversations, uploaded files, custom GPTs, and image generation artifacts. That breadth matters because these products accumulate content that lives on OpenAI's side by design.

The API path is a per-project decision, not an account setting

For frontend and application teams, the API mechanics are the important detail. Residency isn't a global toggle. A customer approved for advanced data controls enables it by creating a new Project in the API dashboard and selecting a region. Requests through that Project are handled in-region.

This project-scoped model shapes how you architect. If a single application serves users in multiple regulated regions, you're looking at multiple Projects — and therefore multiple API keys, separate routing logic, and a mapping from user jurisdiction to the correct project endpoint. That logic has to live somewhere in your stack, and it has to be right before a request is sent.

OpenAI also states that for these API Projects, model requests and responses are not stored at rest on its servers. That is a stronger claim than in-region storage: for the stateless API case, there is no persisted content to reside anywhere. The residency selection governs how the request is handled, not where a stored copy sits.

Residency sits on top of existing controls, not instead of them

OpenAI positions residency as an addition to controls it already offers rather than a replacement. Those include AES-256 for data at rest, TLS 1.2+ in transit, and Enterprise Key Management for customers who bring their own encryption keys.

The company also restates that models are not trained on business-plan or API data unless a customer opts in, and lists GDPR, CCPA, SOC 2 Type 2, ISO/IEC 27001, 27017, 27018, 27701 and CSA STAR alongside a Data Processing Addendum.

For the API Platform and ChatGPT business products, data remains confidential, secure, and entirely owned by you. Data residency further enhances data control for business customers.Montana Labs

The practical reading: residency answers a location question that encryption, opt-out training, and a DPA don't. For teams whose blocker was purely where data physically rests, this fills the last gap. It does not change ownership or training posture — those were already in place.

The implication: region becomes a first-class field in your request routing

The concrete consequence of this release is that a user's jurisdiction now needs to be resolved before an OpenAI call is made, and mapped to a specific Project. Residency is decided at project or workspace creation, so it can't be patched in as a per-request header after the fact.

That pushes work into the frontend and API-gateway layers: capturing or inferring region at signup, provisioning users into the correct workspace or Project, and preventing cross-region leakage when someone travels or an account spans jurisdictions.

None of this is exotic, but it is real engineering that the announcement implies without spelling out. The offer is available in ten markets today; the integration cost of using it correctly lands on the teams building the applications on top.