Auditing Data Residency Requirements Before a Provider Migration

A region selector on a signup page tells you where an endpoint is. It does not tell you where the request content ends up, and the gap between those two is where residency audits fail.

Residency is three questions

Teams ask one question and need three answers. Keep them separate on the page you write up, because a provider can satisfy one and not the others:

• Where is the inference performed? Which region’s hardware runs the forward pass. This is what a region-scoped endpoint usually promises.
• Where is content stored, and for how long? Logs, retained request bodies, cached prefixes, batch job inputs and outputs, uploaded files, and fine-tuning datasets. Storage is frequently a different system from inference with a different regional footprint.
• Who else touches it? Sub-processors — a cloud provider, a logging vendor, a support tooling vendor, a content-safety classifier — each with their own location. A request can be inferred in-region and screened out-of-region.

There is a fourth question that is not about location but is always asked alongside: who can access it, from where. A dataset that never leaves a region but is administered by staff elsewhere may or may not satisfy your obligation, depending on which obligation it is.

Mapping your own flows first

The audit is cheaper and far more accurate if you know what you are sending before you ask where it goes. Most residency scope explosions come from the sending side, not the provider side.

1. List every call site from the hardcoded-name inventory and, for each, write down what personal or regulated data can appear in the prompt. Include the retrieval context, not just the user message — a RAG pipeline can put anything from the index into the request.
2. Mark which call sites can be routed by tenant. If a subset of customers carries the residency requirement and the rest do not, per-tenant routing turns a global constraint into a local one and can change which providers are viable.
3. Identify what leaves the model call and lands elsewhere: your own request logs, your traces, your evaluation datasets, your prompt registry. Your observability stack is a data store with a region of its own, and it is inside the scope of the same question.
4. Note anything that is transferred asynchronously — batch submissions, file uploads, fine-tuning jobs. Asynchronous surfaces often have different regional guarantees from the synchronous endpoint, because they involve storage by construction.

Verifying a claim rather than reading one

Marketing pages describe intent; contracts describe obligation; system behaviour describes reality. Get all three to agree before the cutover.

• Resolve the endpoint. A regional hostname that resolves through an anycast network tells you where the edge is, not where inference happens. Useful as a sanity check, not as evidence — do not conclude from a traceroute that data is processed where the first hop is.
• Ask for the sub-processor list. Providers who take this seriously publish one with locations and a change-notification mechanism. Absence of a list is itself a finding.
• Read the audit report, not the badge. A SOC 2 report has a scope section that names the systems covered and a period it applies to. A logo does not. Ask which services are in scope and whether the regional deployment you are buying is one of them — regional variants are sometimes outside the scope of the report covering the flagship service.
• Get the answer in the contract. A product page can change on a Tuesday. A commitment in the agreement, with a notification obligation attached to changes, is the only version that is still true next quarter.

The stores nobody puts on the diagram

These are the components that repeatedly turn up after the architecture review, and each is worth asking about by name:

• Abuse and safety logs. Retained content held for misuse investigation, often outside the retention window the product documentation quotes and sometimes outside the region, because the team that reviews it is centralised.
• Prompt caches. A cached prefix is stored request content by definition. Ask where it is held, for how long, and whether the cache is scoped to your account.
• Support and debugging paths. When you open a ticket and attach a failing request, that content has left every control you configured. Have a policy for what may be attached to a ticket, and enforce it in the redaction layer rather than in a wiki page.
• Evaluation and quality tooling. Sampled traffic used to score output quality is a second copy in a second system, and it is usually built by a different team from the one that built the inference path.
• Your own stack. Traces, error trackers, and log aggregation frequently default to a region chosen years ago by whoever set them up. Redacting before the log line is written is the control that makes the rest of this smaller — see what to log.

The audit, in order

1. Write down the requirement in one sentence, naming the obligation it comes from. “Content from EU customers is processed and stored in the EU” and “we must be able to evidence where content was processed” are different requirements with different evidence, and conflating them wastes weeks.
2. Complete the flow map above. Scope is what makes this tractable — if only one route carries regulated data, the audit is about one route.
3. Send the sub-processor, storage-location and abuse-log questions in writing, jointly with the training and retention questions from the terms-of-service reading. One email, one set of answers, one document.
4. Reconcile the three sources — documentation, contract, answers — and list every disagreement. A disagreement is not necessarily a disqualification; an unexplained one is.
5. Decide the routing before you build it. If a residency-constrained tenant must stay on the incumbent, the migration is a per-tenant routing change and the model registry needs a residency attribute alongside the capability flags — centralising model configuration is where that attribute lives.
6. Record the evidence with dates and the name of who answered, and put a review date on it. Regional offerings expand and sub-processor lists change; an audit with no expiry is an audit that will be wrong without anyone noticing.