Sovereign AI Guide: Data Residency for AI Workloads

Choosing an in-region cloud is not enough to keep an AI workload sovereign, because prompts, logs, caches, fine-tuning data and human review each have their own location rules, and the defaults often route inference across borders. "Sovereign AI" is used for everything from national compute programmes to a marketing badge on a hosted model. For a security or privacy team it means one practical thing: knowing, and being able to prove, where each piece of AI data is processed and stored, who can access it, and under which law. This guide covers the AI specific layers: inference routing, abuse monitoring and logging, caching and stored state, fine-tuning and model weights, operator and support access, and agent tool calls. It is for architects, privacy leads and risk owners deploying LLMs under residency or sovereignty obligations. General cloud residency and the infrastructure options are covered in the Data Sovereignty and Residency Guide and the EU Sovereign Cloud Options Compared Guide; this page does not repeat them.

Key takeaways

Processing location and storage location are separate promises. All three major cloud AI platforms keep data at rest in the geography you choose while allowing inference to run elsewhere unless you pick a regional or zone-bound deployment type.
"Global" means global. Global deployment types and endpoints can process prompts in any region the provider operates, usually for better capacity or a lower price. They are the wrong default for regulated data.
Abuse monitoring is a second copy of your data. Providers may retain prompts and outputs, sometimes for up to 30 days, and may allow human review. Where that copy lives and who reads it matters as much as the inference location.
Agents leak residency through tools. Grounding with web search, third party tools and MCP servers send prompt content to services with their own retention and location, outside the model contract.
Sovereignty is measurable, not a label. The European Commission now scores cloud providers against eight sovereignty objectives with assurance levels; apply the same discipline to AI services with a per-workload control matrix and evidence.

What sovereign AI means in practice

Sovereignty and residency are related but not the same. Residency is where data physically sits and is processed. Sovereignty adds who controls it: which jurisdiction's law can compel access, whether the operator is subject to foreign law, and whether you can keep running if a supplier withdraws. For AI workloads, apply both questions to five assets, not one.

Asset	Examples	Residency question	Control question
Inference traffic	Prompts, retrieved context, completions, embeddings requests	Which regions can process each request?	Can the provider route it elsewhere without notice?
Provider-side copies	Abuse monitoring stores, caches, stored conversations and threads, batch queues	Where is each copy and for how long?	Who can read it, under what approval, from where?
Customisation data and weights	Fine-tuning datasets, fine-tuned models, adapters, evaluation sets	Where are training jobs run and outputs stored?	Can you export and delete them; are keys yours?
Your own AI data stores	Vector databases, RAG indexes, prompt and response logs, traces	Are they in the same jurisdiction as the source data?	Does your observability vendor copy them abroad?
Agent tool traffic	Web search grounding, SaaS APIs, MCP servers, code sandboxes	Where does each tool process the content it receives?	Is each tool covered by a contract and a transfer mechanism?

At national level, "sovereign AI" also refers to state-funded compute and domestically developed models. That policy debate is out of scope here; the controls below apply whichever model you use, including self-hosted open-weight models, which remove the provider but leave every other layer. See the Self-Hosted LLM Security Guide.

Inference routing: regional, zone and global deployments

Platforms are listed alphabetically. Each of the three largest cloud AI platforms documents the same three tiers under different names, and in each the data at rest stays put while inference location depends on the tier you select.

Tier	Amazon Bedrock	Google Cloud (Vertex AI generative AI)	Microsoft Azure (Foundry Models)
Single region or geography	In-Region invocation of a model in the Region you call	Regional endpoint (for example a single EU region); processing stays within that region's jurisdiction, and some European regions process certain models in-country	Standard and Regional Provisioned: processed within the customer-specified Azure geography, possibly between regions in it for operational purposes
Geographic zone	Geographic cross-Region inference profiles: processed in a Region within the geography (such as US, EU or APAC)	Multi-region endpoints (us, eu): processing within that jurisdiction; the eu endpoint covers EU member states only, excluding the UK and Switzerland	Data Zone types: processed only within the Microsoft-specified zone; the EU zone is the EU Data Boundary, which can include EFTA countries such as Norway and Switzerland
Global	Global cross-Region inference profiles: any supported commercial Region worldwide, at roughly 10% lower cost	Global endpoint: may process in any Google Cloud location, with no residency guarantee	Global types: may be processed in any Azure region
Storage and records	CloudTrail logs every cross-Region inference request in the source Region, with the processing Region in `additionalEventData.inferenceRegion`	Stays in the customer-selected location whichever endpoint is called	Stays in the designated Azure geography for every deployment type

Availability notes. Amazon Bedrock: geographic and global profiles depend on the model; the destination Region list for each profile is published separately and SCPs must allow every destination Region (global profiles need the aws:RequestedRegion value unspecified). Google Cloud: multi-region and in-country support differ by model, so check the model tables. Microsoft Azure: regions can be added to a data zone without prior notice, and the Developer deployment type for fine-tuned model evaluation offers no residency guarantee.

Three consequences follow. First, an "EU zone" is not the same territory on every platform: one excludes Switzerland and the UK, another can include EFTA countries. Map your legal requirement to the actual country list. Second, batch and discounted tiers are where global routing hides; check every SKU, not only the interactive one. Third, enforce the choice with policy rather than developer discipline: service control or organisation policies that deny global endpoints, and infrastructure as code that pins deployment types. Platform depth is in the Amazon Bedrock Security Guide, the Google Vertex AI Security Guide and the Azure OpenAI and Azure AI Foundry Security Guide.

Abuse monitoring, logging and human review

Every hosted model service screens for misuse, and screening can mean storing prompts and outputs. This is the layer most often missed in residency assessments because it sits in the provider's terms rather than in the deployment settings.

Question	Amazon Bedrock	Google Cloud	Microsoft Azure
Is content retained for abuse detection?	Depends on the model: for some third-party models only classifier-flagged traffic is kept, for others all traffic, for up to 30 days	Google may log prompts to detect abuse under its terms; some advanced models or features also log prompts and responses	A sample may be selected when abuse indicators are detected; automated review by default, data stored only for human review
Can it be turned off?	Zero data retention can be requested by eligible customers for some models through the account team	Zero retention may not be possible for some advanced models; check with the account team	Modified abuse monitoring for approved customers removes storage and human review; the `ContentLogging` capability shows `false` when off

Ask every provider two more questions: where the retained copy is stored, and who may review it from where. Documented answers differ: one platform stores retained content in the region that processed a cross-region request, so global routing spreads the abuse monitoring copy as well; another keeps it in the resource's geography and, for EEA deployments, uses reviewers located in the EEA. Get each answer in writing for the models you use. Your own logs matter as well: prompt and response logging in an observability or LLM gateway tool is often the largest store of AI content you hold, and it is frequently a SaaS outside your chosen jurisdiction. Apply the same location test (NIST SP 800-53 AU-11 Audit Record Retention). For the retention side in depth, see Zero Data Retention for AI.

Caching, stored state and grounding

Implicit caching: Google documents implicit caching on by default for supported Gemini models, with in-memory and durable cache deleted no later than 24 hours after writing; durable or all caching can be turned off per project. Amazon Bedrock caching is opt-in through cache checkpoints for most models, with a default time to live of five minutes (one hour on some models), though some models cache eligible prefixes automatically. Azure OpenAI enables prompt caching by default for supported models, typically clears caches within 5 to 10 minutes of inactivity and always within one hour, and offers 24-hour extended retention on some models. Ask every provider the same question for each model you use.
Stored conversations and files: Azure stores threads, Responses API history, stored completions, uploaded files and vector stores in the Foundry resource in the same geography, deletable by the customer. Server-side state is convenient for agents and is a persistent copy; treat it as a data store with its own retention policy.
Grounding with web search: Google stores Grounding with Google Search query logs for up to three days with no way to disable it, and Maps grounding content for 30 days. Any search tool an agent calls sends query text derived from the prompt to the search service, so it needs its own residency assessment.
Stored-by-default flags: some APIs default to storing interactions (Google's Interactions API store parameter defaults to true). Set storage flags explicitly in code and test them.

Fine-tuning, model weights and keys

Customisation creates the most sensitive and longest-lived AI data: curated training sets, and models that may memorise them. Provider documentation generally commits to storing fine-tuning data and fine-tuned models in the customer's chosen geography or location, encrypted at rest, with customer-managed keys as an option on many services. The training run itself may follow different rules from the stored artefact, so check both for the method you use.

Training job location: confirm where the training compute runs, not only where the output is stored. A residency guarantee on the artefact does not cover a job that ran elsewhere.
Customer-managed keys: use your own keys for datasets, fine-tuned models and stored state where the service supports it (SP 800-53 SC-12 and SC-28). Keys in an external or hold-your-own-key service add a technical control over provider access; see the Confidential Computing Guide for the stronger in-use protections.
Portability: check that you can export adapters or weights, or at least rebuild them from data you hold, so a supplier exit does not mean losing the model. The Cloud Sovereignty Framework treats supply chain and technological openness as sovereignty objectives in their own right.
Training on your data: each of the three platforms states that customer prompts and data are not used to train foundation models without permission; Bedrock additionally states model providers have no access to the model deployment accounts that hold prompts and completions. Put these statements into the contract, not just the architecture decision.

Operator access, jurisdiction and contracts

Residency answers "where"; sovereignty also asks "who can be compelled". A provider headquartered outside your jurisdiction may be subject to its home country's access laws for data it controls anywhere; see the CLOUD Act Guide. For personal data leaving the EEA, GDPR Chapter V (Articles 44 to 49) requires an adequacy decision, appropriate safeguards such as standard contractual clauses, or a listed derogation; see the International Data Transfers Map.

Control area	What to require	Evidence
Support and engineering access	Support staff location, just-in-time approval, customer approval for access to content (SP 800-53 PS-7)	Access transparency logs; contract clause
Human review location	Reviewers in-region or review disabled	Provider statement; configuration evidence such as a logging flag
Sub-processors	List of sub-processors and locations for the AI service, including model providers and safety vendors	Sub-processor list; change notification terms
Change notice	Notice before regions are added to a zone or routing changes	Contract term; note that some providers reserve the right to add regions without notice
Location of processing	Named processing and storage locations per service and SKU (SP 800-53 SA-9(5))	Data processing addendum; architecture record
Exit	Export of fine-tuned artefacts, stored state and logs; deletion certificate	Exit plan tested once

The European Commission's Cloud Sovereignty Framework, used in a cloud tender launched in October 2025 and awarded in April 2026, scores providers against eight objectives (strategic, legal, operational, environmental, supply chain transparency, technological openness, security, and compliance with EU law) using Sovereignty Effectiveness Assurance Levels. SEAL-2, data sovereignty, was the minimum for eligibility; SEAL-3 adds resilience to supply chain disruption by non-EU parties; SEAL-4 requires a fully EU supply chain from chips to software. The framework was not written for AI, but its objectives are a usable checklist for AI providers and a common vocabulary with procurement.

Agents, tools and MCP: the residency leak

An agent that keeps its model in-region can still send customer data abroad through its tools. Every tool call is a data transfer: the tool receives arguments derived from the prompt and often returns them to its own logs. MCP servers make this easy to miss because they are added by configuration rather than procurement.

Inventory tools per agent: list every tool, connector and MCP server, its operator, and its processing location.
Classify tool traffic: mark which tools may receive personal or regulated data, and block the rest from receiving it with input filtering or separate agents.
Pin tools to approved endpoints: allow-list egress from agent runtimes to approved, in-region tool endpoints only.
Treat agent credentials as residency controls: an agent's API keys and tokens decide which services it can reach; scope them per tool and region. See the Third-Party AI Risk Guide for supplier assessment.

Implementation: a phased approach

Classify workloads: for each AI use case record the data categories, the legal residency or sovereignty requirement and the countries allowed. Not every chatbot needs sovereign controls; regulated personal, health, financial and government data usually does.
Build the control matrix: for each workload, fill in the five assets (inference, provider copies, customisation, your stores, tools) with the chosen setting and evidence.
Choose the deployment tier: regional or zone-bound by default for regulated workloads; global only for non-regulated data and with a recorded decision.
Enforce with policy: organisation policies or SCPs that deny global endpoints and unapproved regions, and infrastructure as code that pins deployment types; test in a sandbox account first, since a deny policy can break batch jobs or tools that rely on global routing.
Close provider copies: request zero retention or modified abuse monitoring where justified; disable caching and stored state where policy requires; verify flags.
Pilot and verify: run a pilot with logging that records the processing region per request (for example the Bedrock inferenceRegion field) and compare with the matrix.
Roll back safely: keep the previous deployment configuration in code so a residency-breaking change, such as a model only available globally, can be reverted rather than tolerated.

Decision guidance: a small organisation using one provider should pick zone-bound deployment, turn off optional storage and record the provider statements; that covers most residency obligations. A large or public sector organisation with sovereignty (not only residency) requirements should add customer-managed keys, contract terms on operator access and change notice, an exit test, and consider sovereign cloud regions or self-hosted open-weight models for the most sensitive workloads, accepting a smaller model choice and more operating effort.

Detection and measurement

Processing region per request: alert on any AI request processed outside the allowed list, using provider audit logs.
Policy drift: alert on new deployments using global types or endpoints, and on changes to logging, caching or storage flags.
Unapproved tools: alert on agent egress to tool endpoints not on the allow list.

Metric	Target
Share of regulated AI workloads with a completed five-asset control matrix	100%
AI requests processed outside the approved region list	Zero for regulated workloads
Deployments using global types for regulated data	Zero, or each with a signed exception
Agent tools with documented processing location	100%
Provider sub-processor or region changes reviewed within 30 days	100%

Framework mapping

Framework	Reference	How it applies
NIST SP 800-53 Rev. 5	SA-9 External System Services; SA-9(5) Processing, Storage, and Service Location	Restrict where AI providers process and store data
NIST SP 800-53 Rev. 5	SC-12, SC-28; AU-11; PS-7	Customer keys, protection at rest, log retention, external personnel access
NIST CSF 2.0	GV.OC-03; GV.SC-05; PR.DS-01	Legal requirements understood, supplier contract requirements, data at rest protected
GDPR	Chapter V, Articles 44 to 49	Transfers of personal data in prompts, logs and tool calls
EU Cloud Sovereignty Framework	Eight objectives; SEAL-0 to SEAL-4	Procurement scoring of providers' sovereignty

Common failure patterns

Region chosen, tier ignored: the resource sits in an EU region but the deployment type is global, so prompts are processed anywhere.
Abuse monitoring overlooked: the assessment covers inference and storage but not the provider's retained copy and human review.
Logs abroad: prompts and responses are shipped to an observability SaaS in another jurisdiction, creating the largest copy of AI content outside the boundary. The DeepSeek Database Exposure 2025 shows what an unprotected AI log store holds: plaintext chat histories, API keys and backend details.
Staff use of public AI tools: sovereign controls on the approved platform do nothing if staff paste data into consumer tools. In the Samsung ChatGPT Source Code Leak 2023, engineers sent source code and meeting notes to an external service the company could not retrieve them from.
Agent tools unassessed: web search grounding or an MCP server sends prompt content to a service with fixed retention and no residency commitment.
Zone definitions assumed equal: a requirement for "EU only" met by a zone that can include non-EU EFTA countries, or a UK requirement met by an EU-only endpoint that excludes the UK.

Practitioner checklist

Classify each AI workload by data category and legal residency or sovereignty requirement, with the allowed country list.
Complete the five-asset control matrix (inference, provider copies, customisation, own stores, tools) per workload.
Use regional or zone-bound deployment types for regulated data and block global endpoints with organisation policy.
Confirm abuse monitoring retention, location and human review for each model, and request zero retention where justified.
Disable caching, stored state and optional logging where policy requires, and verify the flags.
Use customer-managed keys for fine-tuning data, models and stored state where supported.
Inventory agent tools and MCP servers with their processing locations and restrict egress.
Put processing location, sub-processors, operator access, change notice and exit terms into the contract.
Alert on requests processed outside the approved region list and on configuration drift.

Sovereign AI Guide: Data Residency and Control for AI Workloads