AI Data Residency: Prove the Whole Execution Path

Selecting “Europe” in a cloud console can create a reassuring screenshot while prompts still pass through a global endpoint, an optional grounding service, an abuse-monitoring store, a support workflow or a fallback region. Storage may be regional while inference is not. A model may stay inside a zone while the retrieval index, traces or human support route does not.

The operating decision is which execution path may handle this workload, for which data, under which failure conditions, and what evidence proves the claim. The answer should be specific enough for software to enforce. “EU hosted” or “UK data” is too vague to decide whether a request may run.

The regulator and provider documentation linked below supplies the source facts. The execution-path map, residency contract, route classes and worked example are AIEngine's engineering synthesis. This is not legal advice, and technical location controls do not by themselves establish a lawful international transfer.

Define the claim before choosing the region

Data residency is often used as if it described one property. In practice, a useful claim names the data state, allowed place, actors and time. Separate at least these questions:

This prevents a category error: regional storage is not evidence of regional processing, and regional inference is not evidence that every derivative stays there. OpenAI's current API data-controls documentation explicitly separates regional storage from regional processing and excludes system data from its customer-content residency claim. It also lists feature-specific limits; for example, Realtime tracing is not currently compliant with EU data residency. Treat such a limitation as a route constraint, not a footnote.

Start with the actual information rather than the provider. Classify the prompt, attachments, retrieved records, output and likely telemetry. Identify personal, confidential, regulated, export-controlled and client-restricted material. Then write the narrowest location claim the use case requires: one country, a named cloud region, a defined geography such as the EU data boundary, or no external processing.

Draw the complete execution path

Trace one request from the user boundary to its last derivative. Include the client, API gateway, content filter, model endpoint, cache, retrieval service, tool calls, application database, logs, analytics, backup, support and incident-response path. Add each controller, processor and subprocessor rather than drawing one vendor box.

The AI dependency inventory provides the component-and-relationship structure. Extend it with four location fields: permitted processing area, permitted storage area, permitted support-access area and permitted failover area. Record feature flags because enabling background work, tracing, web grounding, session resumption or a hosted vector store can change the path without changing the model name.

Map derived data as carefully as the initial prompt. Embeddings, cached prefixes, safety classifications, evaluation samples, summaries and support attachments may no longer look like the source but can preserve sensitive information. The erasure-propagation guide explains why each derivative needs its own owner, deadline and completion evidence.

Do not infer location from latency, a billing address or the hostname alone. Resolve the configured product semantics and obtain runtime evidence where the service exposes it. AWS, for example, says geographic cross-Region inference keeps processing inside the selected geography while prompts and outputs may move among its member regions; abuse-detection data may be stored in the destination region. Its permissions must allow every destination region in the profile. That is a different contract from single-region inference.

Choose a route class, not a marketing label

Use a small set of route classes that the application can enforce. The names below are an operating model, not legal categories.

Microsoft's Foundry deployment documentation makes the trade-off concrete: global deployments can process prompts and responses in any geography where the model is available; data-zone deployments stay inside the selected zone; single-region deployments keep processing in the deployment geography. Microsoft also notes that global options generally receive models and features first. Residency therefore constrains the model catalogue and capacity plan; it cannot be added after procurement as a label.

Google's current data-residency service list is similarly feature-specific. It lists generative AI services that can be configured for AI/ML data location while excluding named capabilities such as some grounding, RAG, agent runtime, memory and evaluation features. Google's zero-retention documentation separately explains temporary caches and features that retain session or grounding data. Check the exact feature, not merely the product family.

Keep transfer law separate from routing evidence

For UK personal information, a server map is not the legal test. The ICO's guidance says a transfer can mean sending personal information or making it accessible to a separate organisation outside the UK. Remote support access can therefore matter even when the data remains on a UK server. The ICO's updated three-step approach asks whether UK GDPR applies, whether the organisation initiates the transfer to an organisation outside the UK, and whether the receiver is a separate legal entity.

If a restricted transfer is made, the ICO describes routes including adequacy regulations, appropriate safeguards or an exception. Where safeguards are used, its transfer risk assessment guidance asks whether protection would be materially lower after transfer and whether the safeguard can be enforced. The European Data Protection Board's final Guidelines 05/2021 address the EU GDPR boundary, while the European Commission publishes the 2021 Standard Contractual Clauses as one transfer tool.

Legal, privacy, security and service owners should therefore approve two joined records: the lawful-transfer analysis and the technical execution path. A contract cannot stop a globally configured endpoint. A regional endpoint cannot answer whether the receiver, onward transfers, access rights and safeguards are lawful.

Turn the map into a residency contract

Create one versioned contract per workload, not one generic cloud questionnaire. It should state:

• workload and data classes, including derived data likely to appear;
• allowed processing, storage, support-access and recovery locations;
• provider project, endpoint, deployment type, model snapshot and routing profile;
• enabled caches, logs, grounding, tools, batch jobs and background features;
• approved processors, subprocessors and support entities;
• retention and deletion rules for each stored state;
• permitted fallback, including the explicit no-route condition; and
• evidence owner, approval, last verification and dated recheck trigger.

Store the enforceable parts in configuration or policy code. Allow only approved regional endpoints at the network layer. Bind workload identities to the permitted deployment or inference profile. Reject a request whose data class does not match the route. Prevent a client library from silently selecting a global endpoint. Keep the human-readable assessment beside the machine rule so reviewers can see why the restriction exists.

The evidence packet should prove both configuration and behaviour: exported deployment settings, contract and subprocessor versions, policy tests, sample request traces without sensitive content, destination-region fields where available, and a negative test showing that an unapproved route is blocked. Use the minimum joined identifiers described in privacy-safe incident replay, rather than copying full prompts into a permanent audit store.

Work a customer-support summarisation example

Consider a hypothetical UK service that summarises customer cases containing names, contact details and complaint history. The organisation decides that managed inference may run only inside one approved European geography, the source case stays in its UK system of record, and support access outside approved entities is not allowed. This example illustrates the framework; it does not decide the organisation's legal obligations.

The request gateway replaces direct identifiers with short-lived references, retrieves only the case fields needed for the summary and calls a pinned geography endpoint. Prompt storage, background jobs, external web grounding and provider-side conversation state are disabled. The application stores the approved summary in the UK case system and retains only a trace identifier, route class, endpoint, model, policy decision and output hash in its operational log.

The important test happens during failure. If geography capacity or the approved model is unavailable, the client must not fall back to a global endpoint. It saves a review task or uses a deterministic template. A support engineer can diagnose the route and identifiers without attaching the customer's prompt to an unrestricted ticket. If temporary content access is necessary, it follows a separately approved, time-bounded process.

The test suite then asserts that restricted fixtures reach only approved endpoints, global hostnames are denied, optional features remain off, the route identity cannot invoke another profile, and the final record contains no raw prompt. A benign non-sensitive fixture also proves that the global route still works for workloads explicitly assigned to it. This mirrors the output-validation principle: the model cannot grant itself a wider sink or route.

Test the failures that move data

Residency failures are often configuration successes. The request returns 200, but the path changed. Exercise at least these cases:

• the regional model is unavailable and an SDK proposes a global fallback;
• a new model is offered only through a broader deployment type;
• a tracing, session, grounding, file or batch feature has different location semantics;
• a support ticket or incident export includes customer content;
• the vector store, object store, analytics destination or backup sits elsewhere;
• a subprocessor or destination-region set changes; and
• a mobile client or overseas system calls the provider directly, bypassing the approved gateway.

Fail according to the contract: block, queue, redact, switch to an approved local model or provide a non-AI service. Do not retry across geography until something works. The graceful-degradation ladder helps preserve useful service without silently weakening the data boundary.

Measure proof, exceptions and drift

Track the share of eligible requests that carry a route decision, calls with an observed processing region where the platform exposes one, policy-denied misroutes, fallback attempts, features without reviewed location semantics, support accesses, unapproved derivatives and deletion misses. Count contracts past their recheck date and provider changes awaiting assessment.

Revisit the route when the model, endpoint, deployment type, feature flags, data classes, subprocessors, support model, recovery design or law changes. Provider documentation is live configuration input: retain the page and review date that supported the decision, but verify the current service before every material release.

The practical rule is to follow the data, not the region label. Name the claim, map every processing and storage state, pin a permitted route, prove that the unapproved route fails and design a useful fallback that keeps the boundary intact.