LLM data residency: what to configure and what to verify

Residency is a configuration you set, not a property you inherit, and the defaults differ per vendor and change without notice. Establish four things in writing for each provider, then enforce the rest at your own gateway, because that is the only layer you control.

JarvisBitz

Teams tend to treat data residency as a property they inherit by picking a vendor, when it is a configuration somebody has to set, on a specific account, before the first request. The engineering work is small and the failure mode is not: nobody discovers a wrong region by watching it fail, because nothing fails. Requests succeed, answers come back, and the setting is only examined when someone asks a question you cannot answer.

Four things are worth establishing in writing per provider, each with the date you checked it, because all four move.

1. Is the data used for training by default?

For the major API products, the answer is currently no, and the wording matters more than the summary. OpenAI's documentation states that "data sent to the OpenAI API is not used to train or improve OpenAI models (unless you explicitly opt in to share data with us)", which is a default with an opt in rather than a guarantee, and consumer products are governed separately.

Two practical notes. This is a per product answer, not a per company one, so a team using a consumer tier alongside the API has a different answer for each. And it is worth recording as a dated fact in your own documentation rather than as a belief, because the person who needs it in eighteen months will not be the person who read the page.

2. What is retained, for how long, and can it be turned off?

Retention is separate from training and gets conflated with it constantly. Both major providers currently sit around a thirty day window for API traffic. Anthropic's documentation states that "we automatically delete inputs and outputs on our backend within 30 days of receipt or generation". OpenAI describes abuse monitoring logs held "up to 30 days, unless longer retention is required by law, or is reasonably necessary to protect our services".

Zero retention exists and is not simply a checkbox. OpenAI's zero data retention controls are, in their words, "subject to prior approval". Plan for a procurement conversation rather than a settings toggle, and start it earlier than feels necessary if your architecture assumes the answer is yes.

3. Which regions are actually available, and at what cost

Regional processing is offered and it is neither universal nor free. OpenAI currently lists regional infrastructure across eleven locations including the United States, Europe covering the EEA and Switzerland, the United Kingdom, Canada, Japan, India, Singapore, South Korea, Australia and the United Arab Emirates. The region is set per project at creation, non US regions require approval, and they typically carry a ten percent cost uplift.

The engineering consequence people miss is that region is fixed at project creation. If your provisioning script creates projects, the region belongs in that script, reviewed like any other infrastructure default. Retrofitting it means new projects and a migration.

4. Where does the data go that is not the model call?

This is the one that gets missed, and it is usually the largest surface. A single AI feature commonly touches a model API, an embedding API, a vector database, an observability platform, an error tracker and a transcript store. Configuring the model call correctly while your traces stream to a logging vendor on another continent is a common and entirely invisible outcome.

Enumerate every hop that sees content, not every vendor you pay. Our piece on what to log in an LLM system goes into the redaction side, which is the other half of this problem.

What your gateway has to enforce

Vendor settings are necessary and not sufficient, because they are configured once and trusted forever by people who did not configure them. The layer you actually control is your own gateway, and it should enforce the following regardless of what any provider promises.

• One egress point. All model traffic through a service you own, so there is a single place to change providers, regions or policy. Direct SDK calls scattered through application code make every later question unanswerable.
• Redaction before the boundary. Strip or tokenise what does not need to leave. The cheapest data to govern is the data you never sent.
• Provider and region pinned in config, asserted at runtime. If a call is about to go somewhere unexpected, fail it rather than log it. A warning in a dashboard nobody reads is not a control.
• A record of which provider and region served each request. When someone asks where a specific conversation went, the honest answer should not require reasoning about deployment history.
• Your own retention clock. Whatever the provider deletes on their side, you are holding transcripts and traces on yours, and that copy is the one you control.

What to do this week

• List every service that sees user content, including logging and error tracking.
• For each, record the training default, the retention window, the region, and the date you checked. Diarise a recheck.
• Move all model traffic behind one gateway if it is not already.
• Set region in provisioning config, not in a runbook.
• Give your counsel that inventory. They cannot advise on a system nobody has described.

If you want that inventory built and the gateway designed around it, our free AI audit maps where content currently flows, and how we handle data governance covers how we build the enforcement layer.

Related reading

LLM spend: attribution before optimisation

You cannot cut what you cannot see. Most teams optimise models and prompts before they can attribute a single dollar to a team, feature or customer, which means they are guessing. Meter at the gateway first, then cache, route and cap in that order.

What to log in an LLM system so you can debug it later

A 200 response tells you almost nothing about an AI system, because the failure you care about is a confident wrong answer that returned successfully. Log the inputs, the retrieved context, every tool call and the guardrail outcomes, or you will be debugging from screenshots.

Your model is being retired. How to move without regressions

The API call will port in an afternoon. What breaks is behaviour: the same prompts producing subtly different output, and you cannot tell without something to compare against. The migration is a measurement problem, and the teams that find it easy built the measurement before the email arrived.