A Cloud Region Alone Does Not Prove AI Data Residency

An HR team creates a benefits assistant in a European cloud region. The documents sit in a regional bucket and the model endpoint has a European address. Yet a global deployment serves a prompt elsewhere, OCR takes another path, external search receives an employee question, and an engineer outside the region opens a support trace. The resource page still says “Europe.” The data path does not.

The practical decision is not whether a provider offers a region selector. It is whether this workload, with these enabled features and data classes, may use this exact execution route. A defensible answer must cover storage, processing, movement, derivatives, operational access, recovery, and fallback. If any required component has an unknown or disallowed location, the system should transform the request, choose another route, defer it, or reject it—not quietly relax the boundary.

This engineering and governance framework is not legal advice. Residency, privacy law, sector rules, government-access risk, and transfer mechanisms are related but not interchangeable; qualified counsel must interpret applicable duties.

The endpoint is only one stop on the journey

“Data residency” is often used for several different promises:

• storage residency: where customer content is persisted at rest;
• processing residency: where computation on that content occurs;
• transit boundary: which countries or networks data may cross;
• administrative-access boundary: where provider or customer personnel may view or manage it;
• jurisdictional exposure: which legal authorities and corporate entities may reach it;
• control residency: who holds keys, policies, logs, and the practical ability to change or suspend the system.

Name the promise precisely. “EU data residency” is incomplete. “Employee-identifiable request content and its derivatives remain stored and processed inside the approved EU boundary; no external tool receives them; support access follows the approved personnel rule” is testable.

What the verified sources establish

The UK National Cyber Security Centre's Cloud Security Principle 2, published in 2018 and reviewed in 2023, tells cloud customers to understand the countries where data is stored, processed, managed, and supported, including derivative data such as verbose logs and machine-learning models. It also separates physical location from legal jurisdiction and provider access rights.

The European Data Protection Board's final Guidelines 05/2021, adopted in February 2023, give three cumulative criteria for identifying a Chapter V transfer. They state that remote access from a third country—including support or administration that only displays personal data—can count as making data available when those criteria are met. This is a legal classification, not a geometry test based only on the server rack.

NIST's 2011 SP 800-144 is older than today's generative-AI services, but its lifecycle lesson remains useful: cloud arrangements must account for access, keys, backups, recovery copies, sanitization, termination, and continuous verification of controls. Modern AI adds more derivatives and more routing choices; it does not remove those obligations.

Current provider documentation demonstrates why scope must be read feature by feature. Amazon Bedrock's geographic cross-Region guidance says geography-bound profiles can process prompts and results in destination regions inside that geography, and notes that retained abuse-detection data may be stored in the destination region. Microsoft Foundry's data and privacy documentation, last updated 27 February 2026, distinguishes regional, Data Zone, and Global processing and documents stored features such as response history. Google's current Cloud data-residency terms list covered services and exclusions, including exclusions for some grounding, retrieval, agent-runtime, memory, session, and sandbox capabilities.

These sources do not create one universal standard. They require inspection of the actual service, deployment, features, actors, and contract. The architecture below is ZharfAI analysis built on that evidence.

Define the protected data before drawing a border

A boundary cannot protect an undefined object. Inventory data by sensitivity, subject, purpose, and form. For a document assistant, the list may include:

1. user identity, tenant, role, device, and network metadata;
2. typed prompts, uploaded files, images, and audio;
3. extracted text, thumbnails, OCR output, and document structure;
4. retrieved passages, query expansions, rankings, and citations;
5. prompts assembled by the application and model outputs;
6. embeddings, caches, conversation memory, and fine-tuning examples;
7. safety samples, abuse records, traces, logs, metrics, and support exports;
8. backups, replicas, disaster-recovery copies, and deletion records.

Assign each class an owner and allowed purpose. An embedding, trace, or support screenshot can remain sensitive even without the original text. If a class is unnecessary, remove it before the boundary.

Write a residency contract the router can evaluate

For each workload class, create a machine-readable contract with at least these fields:

Bind the contract to the complete deployed assembly described by the AI release-passport approach. A model alias, deployment type, logging mode, region list, or subprocessor change can alter the boundary without an application-code change.

Build a feature-and-route eligibility matrix

Make one row for every callable route: service, deployment type, model, possible processing regions, storage, retention, extensions, support regime, and evidence date. Evaluate online and batch inference, embeddings, fine-tuning, caching, file parsing, retrieval, grounding, code execution, agent memory, evaluation, and safety review separately; their guarantees may differ.

The matrix expires. Recheck it when a destination, deployment type, preview status, retention rule, or subprocessor changes. “Approved vendor” never means every future feature is approved; see the scoped diligence in our AI vendor-risk guide.

Enforce the boundary before sensitive content leaves

The residency decision belongs outside the model and before the network call. A practical request path is:

1. authenticate the actor and resolve tenant, purpose, and policy version;
2. classify data and consequence without sending protected content to an unapproved service;
3. minimize, tokenize, or redact fields where that preserves the task;
4. select only routes whose current manifest satisfies the contract;
5. verify that tools and retrieval destinations are eligible;
6. attach a short-lived policy decision to the request;
7. record the actual provider route and result class;
8. release the output only if its destination is also allowed.

Use organization policies, endpoint allowlists, private networking, egress controls, and deployment permissions to make disallowed routes unreachable. The policy engine normally needs class labels, tenant, purpose, route manifest, and destination—not raw content. Runtime enforcement must catch an SDK default, new tool, or emergency fallback.

Treat tools, people, and recovery as part of execution

An agent can keep inference regional and still export data through search, email, analytics, maps, or a remote browser. Each tool needs a destination, retention, identity, and purpose assessment. People are endpoints too: record where support staff operate, what they can see, how access is approved, and what evidence remains. Residency does not prove tenant isolation, or vice versa.

Backups, replicas, quarantine, failed-message queues, and forensic exports also need eligible locations and tested deletion. The contract must predefine stop, in-boundary failover, or a reduced non-sensitive service. The recovery-cut method keeps artifacts compatible; this contract decides where they may exist.

Worked example: a regional employee-benefits assistant

Suppose an employer wants an assistant to explain benefit policies and answer questions from employee records. The approved boundary is a named European data zone. Public policy documents may be processed globally; employee-identifiable content and its derivatives may not.

The first design places the database and vector index in a European region, then uses a global model deployment for capacity, a general OCR API for scanned claims, web search for policy context, and a global observability service with prompt capture. It fails before launch. The regional database covers only two artifacts; the model request, OCR derivative, search query, trace, and support access have unresolved or disallowed paths.

The revised design separates two lanes:

• A public lane answers only from approved public documents. It may use broader routes because no employee context is attached.
• A protected lane resolves identity, retrieves the minimum authorized fields, uses an eligible regional or data-zone deployment, disables unapproved grounding and content capture, sends scanned documents only to an approved parser, and stores protected traces inside the boundary with short retention.

The router never adds employee data to the public lane. If the protected model lacks capacity, the service shows verified public guidance or transfers the case to an approved human queue; it does not fail over globally. Support receives a synthetic reproduction by default. A break-glass access request is time-bound, approved, geographically eligible, and logged.

For each protected response, the application records a receipt: contract version, input classes, minimization performed, route and deployment identifiers, observed processing location where available, enabled features, tool destinations, retention mode, policy decision, and output destination. The receipt does not claim what the provider cannot evidence.

Choose among run, transform, defer, and reject

Do not reduce the outcome to allow or deny. Four dispositions preserve more useful work:

“Ask the user for consent” is not a universal fifth outcome. Consent may not be the applicable basis, may not cure a sector restriction, and may not be freely given in an employment relationship. Treat legal basis as a separate, qualified determination.

Build proof from independent layers

A console screenshot is weak evidence because it shows one moment and often one resource. Assemble proof from several layers:

• declared scope: approved contract, provider terms, subprocessor list, and feature documentation;
• preventive configuration: organization policies, route allowlists, regional resources, logging mode, key policy, and blocked global deployment types;
• deployed manifest: immutable identifiers for the application, model, tools, retrieval, storage, telemetry, and recovery services;
• runtime evidence: provider audit events, actual destination region where exposed, network-flow records, policy decisions, tool calls, support access, and blocked attempts;
• challenge tests: deliberately call a disallowed endpoint, enable a prohibited feature, trigger capacity loss, and verify a fail-closed outcome;
• lifecycle evidence: retention expiry, deletion test, backup inventory, access review, and provider-exit drill.

Protect the evidence itself: traces can become a second sensitive archive. Default content capture to off and separate metrics from restricted artifacts. Attested secret release can strengthen decryption control, but it does not decide jurisdiction or external paths.

Failure modes that survive a region checkbox

The most common failures are scope errors, not missing flags:

• At-rest substitution: a storage promise is presented as a processing promise.
• Source-region illusion: the API is called from an approved region, but a global or geography-wide profile chooses another processing location.
• Derivative amnesia: embeddings, caches, moderation samples, logs, screenshots, and exports disappear from the inventory.
• Feature inheritance: teams assume a model's guarantee automatically covers grounding, files, agents, code execution, or preview features.
• Helpful fallback: an outage silently routes protected work to a broader geography.
• Human blind spot: remote support or administration falls outside the personnel boundary.
• Contract-only control: policy language exists, but developers can still call the global endpoint.
• Encryption overclaim: encryption protects confidentiality in some threat models; it does not by itself prove location, prevent every operator access, or resolve transfer law.
• Stale approval: a route remains allowed after a documentation, model, destination-region, retention, or subprocessor change.

Test each failure as a system behavior. A review meeting cannot prove that the application rejects an ineligible route under load.

Residency has an availability price

The narrowest boundary can reduce capacity, model choice, throughput, and recovery options. Current AWS and Microsoft documentation both expose the trade-off through single-region, geography or data-zone, and global modes. The labels and guarantees are vendor-specific, but the decision pattern is general:

Do not disguise the price by adding an unsafe fallback. Define a minimum useful protected service, reserve capacity where justified, queue deferrable work, and keep public-content functions separate. A truthful refusal or delayed protected answer is better than an available service that breaks its stated boundary.

Measure boundary health, not deployment geography

Track metrics that can change a decision:

• percentage of protected requests with a complete, current route manifest;
• unknown-location dependencies and their age;
• protected requests blocked, transformed, deferred, and rejected by reason;
• attempted calls to global or unapproved endpoints;
• runtime destination evidence coverage;
• configuration drift from the approved manifest;
• external tool and support-access events by eligible geography;
• exceptions open, expired, or missing an owner;
• retention and deletion test success across primary, derivative, and backup stores;
• failover drills that preserved both service behavior and the boundary.

Set stop conditions. Suspend a route when its guarantee becomes ambiguous, a new feature bypasses controls, runtime evidence contradicts the manifest, or a provider change has not been reviewed. Reopen the decision when data classes, purpose, tools, deployment type, model, provider terms, regions, support arrangement, recovery design, or applicable law changes.

The decision in one sentence

Approve an AI execution route only when every protected input, output, derivative, tool call, operational access path, and recovery copy is confined to the declared boundary by current scope, enforceable configuration, and runtime evidence. Otherwise transform the request, defer it to an eligible path, or reject it.

The important artifact is not a screenshot of the region selector. It is a living contract that explains what is protected, where every part may operate, how the boundary is enforced, what happens when it cannot be honored, and what evidence proves the last request followed the rule.

Source notes — reviewed 4 September 2026

• UK National Cyber Security Centre, Cloud Security Principle 2: Asset protection and resilience, version 2.1, published 17 November 2018 and reviewed 7 June 2023.
• European Data Protection Board, Guidelines 05/2021, version 2.0, adopted 14 February 2023 and published as the final version on 24 February 2023.
• NIST, SP 800-144: Guidelines on Security and Privacy in Public Cloud Computing, December 2011; used here for durable lifecycle, backup, access, sanitization, and termination principles, not current product details.
• Amazon Web Services, Amazon Bedrock geographic cross-Region inference, current documentation checked 4 September 2026.
• Microsoft, Data, privacy, and security for models in Microsoft Foundry, last updated 27 February 2026 and checked 4 September 2026.
• Google Cloud, Cloud Platform Services Data Residency, current service-scope and exclusion list checked 4 September 2026.