AI data residency means everything an AI system handles stays stored and processed inside approved jurisdictions. Everything is the load-bearing word: prompts, outputs, retrieved documents, embeddings, logs, fine-tuning data. Most teams end up asking three questions about all of those: where the data is physically stored, where the model processes the prompt, and who can reach it remotely.
For example, a vendor can store chat history in Frankfurt while the GPUs that answer each prompt run somewhere else. The model itself can run in four places: behind a public API, as a managed model in your cloud region, as an open-weight model in your VPC, or on-premises. Choose per data class, then check the paths beyond the model. Residency usually breaks there.
An auditor asks which region processed last Tuesday’s prompts. The vendor deck says EU-hosted. Further down, the contract allows processing to occur elsewhere, so the only thing that could settle the question is a log, and often there isn’t one.
Gaps like that are why security now limits how far AI programs can go. In McKinsey’s 2026 AI Trust Maturity Survey, nearly two-thirds of respondents named security and risk concerns as the top barrier to fully scaling agentic AI, ahead of regulatory uncertainty and technical limitations. Once regulated data enters a prompt, the model call is a data transfer and carries the same regulatory exposure as any other.
This guide works through the problem in the order an architecture review does. It separates storage, inference, and operational access, compares the deployment options, and covers where AI data leaves the boundary, what the main data laws require, and when to self-host an LLM instead.
Why Is “Where Does the Model Run?” the First Question in an AI Security Review?
The location of inference determines which laws apply to your data, who can access it, and which controls you can enforce, so it’s the starting point for any serious enterprise AI security review. Every API call to an LLM ships the full context to wherever the model runs, including system instructions, user input, retrieved documents, and tool results. For a regulated workload, the call is a processing operation, and an endpoint in another jurisdiction can turn it into a cross-border data transfer.
Storage location, processing location, and remote access all follow from the region on the contract. That region comes with an attached legal regime and an operator whose support staff can access your data wherever they’re based. Network isolation, the keys, and the logs you keep are the only things standing in the way. The legal side stacks up separately. Transfer rules under the General Data Protection Regulation (GDPR) apply, sector rules apply on top, and foreign access laws such as the US CLOUD Act can reach the operator wherever the servers are.
Traditional SaaS answers this question once. A CRM stores a customer record, leaves it there, and that is the end of the matter. An AI system re-sends sensitive data on every call and keeps producing more of it along the way, in embeddings, traces, and eval scores. Both behaviors trace back to how LLMs differ from deterministic software, and a security review written for stateless APIs won’t look for either.
More copies in more places widen what AI data security and LLM security reviews have to cover. Residency is a property of each workload, and no single vendor-level answer can cover them all.
What Is AI Data Residency?
AI data residency is the requirement that the data an AI system handles stays stored and processed inside approved jurisdictions. The scope goes beyond stored data in a database, because an AI system keeps producing fresh copies of the same information as it works.
AI data governance starts with an inventory of what the system produces. For a live system, that means prompts and system instructions, outputs, uploaded files, and retrieved chunks with their embeddings. It also means conversation history, agent memory, logs, traces, fine-tuning and eval datasets, and cached prompts. Each of these artifacts inherits the classification of its source, so data governance and residency cover the same ground.
Storage residency is about where the data rests, which covers data storage of every kind, from a database or object store to a vector index or a backup. Inference residency concerns the place where the model processes the prompt and generates the output. Operational access covers remote data access for support, abuse monitoring, or a legal order, including which legal entity employs the people involved and which country they work from.
Each of these is usually recorded somewhere different. Storage tends to be a console setting and inference a request parameter, so both are quick to check. Operational access is normally defined only in the contract, which is why teams often find out about it late.
Most vendor claims cover the storage question and say little about the other two. That becomes a problem once an auditor asks about the request path, because a map that names only the data location cannot answer it. It helps to keep all three answers in one document, each next to the setting or clause that backs it.
What Is the Difference Between Storage Residency and Inference Residency?
Storage residency and inference residency answer different questions, and they are configured separately. Data can sit in one region while the model that reads it runs in another.
Picture a chat product that keeps conversation history in a Frankfurt database while the model handling each inference request runs on capacity somewhere else. The vendor calls it EU-hosted. That is true of the storage and nothing else.
Major providers now expose the two as separate controls. Anthropic’s documentation separates a per-request inference geography from a workspace storage geography, and OpenAI separates at-rest residency from in-region processing. A data residency commitment has to name both, since a contract naming only storage leaves inference unconstrained.
Data Sovereignty vs. Data Residency vs. Data Localization
Data residency describes where data sits and where it runs. Data sovereignty is about jurisdictional control, meaning whose law reaches that data and who can compel access to it. Data localization goes further, as a statutory requirement that data stay within a border, with no copies leaving.
Term | Question It Answers | Typical Source | AI Example |
|---|---|---|---|
Data residency | Where is the data stored and processed? | Policy, contract, regulation | Prompts processed only on EU endpoints |
Data sovereignty | Whose laws govern the data and who can compel access? | National law, operator’s jurisdiction | EU region of a provider headquartered elsewhere may still face foreign legal orders |
Data localization | Must the data stay inside the border, with no copies leaving? | Statute (e.g., some financial, payment or national data rules) | In-country inference only, often on-prem or a domestic cloud |
Term
Data residency
Data sovereignty
Data localization
Question It Answers
Where is the data stored and processed?
Whose laws govern the data and who can compel access?
Must the data stay inside the border, with no copies leaving?
Typical Source
Policy, contract, regulation
National law, operator’s jurisdiction
Statute (e.g., some financial, payment or national data rules)
AI Example
Prompts processed only on EU endpoints
EU region of a provider headquartered elsewhere may still face foreign legal orders
In-country inference only, often on-prem or a domestic cloud
Where Can Your AI Model Run? Four Deployment Options Compared
A model can run in four places, and each one moves the residency boundary to a different operator. Each step along that line hands you one more layer of the stack to control and one more layer to pay for and operate.
Option | Where Inference Runs | Who Operates It | Residency Control | Typical Fit | Main Trade-Off |
|---|---|---|---|---|---|
Public model API (OpenAI, Anthropic, Google, Mistral) | Provider data centers; regional endpoint if offered and enabled | Model provider | Contractual + per-project/per-request settings | Public and internal data; confidential data with zero data retention (ZDR) and regional processing | Least control over sub-processors and abuse-monitoring copies; settings often fixed at project creation |
Managed model in your cloud region (Bedrock, Vertex AI, Azure / Foundry) | Cloud provider region you select; cross-region profiles may span several regions | Cloud provider (and sometimes the model vendor) | Region selection + identity and access management (IAM) policy + cloud data processing agreement (DPA) | Confidential and many regulated workloads already on that cloud | Must pin single-region vs geographic routing; not every model in every region; regional pricing premium |
Open-weight model in your VPC | Your GPUs in your cloud account | You | Full: network, keys, logs | Regulated data, strict residency, predictable volume | GPU cost, MLOps burden, model quality gap on some tasks |
On-prem / air-gapped (sovereign AI) | Your data center or a sovereign cloud | You or a domestic operator | Absolute, including operator jurisdiction | Localization mandates, defense, critical infrastructure | Highest cost and lead time; slowest model refresh |
Option
Public model API (OpenAI, Anthropic, Google, Mistral)
Managed model in your cloud region (Bedrock, Vertex AI, Azure / Foundry)
Open-weight model in your VPC
On-prem / air-gapped (sovereign AI)
Where Inference Runs
Provider data centers; regional endpoint if offered and enabled
Cloud provider region you select; cross-region profiles may span several regions
Your GPUs in your cloud account
Your data center or a sovereign cloud
Who Operates It
Model provider
Cloud provider (and sometimes the model vendor)
You
You or a domestic operator
Residency Control
Contractual + per-project/per-request settings
Region selection + identity and access management (IAM) policy + cloud data processing agreement (DPA)
Full: network, keys, logs
Absolute, including operator jurisdiction
Typical Fit
Public and internal data; confidential data with zero data retention (ZDR) and regional processing
Confidential and many regulated workloads already on that cloud
Regulated data, strict residency, predictable volume
Localization mandates, defense, critical infrastructure
Main Trade-Off
Least control over sub-processors and abuse-monitoring copies; settings often fixed at project creation
Must pin single-region vs geographic routing; not every model in every region; regional pricing premium
GPU cost, MLOps burden, model quality gap on some tasks
Highest cost and lead time; slowest model refresh
Last verified: November 2026. Provider terms and regional availability change; check the current documentation before you commit.
Public Model APIs: Regional Endpoints and Zero Data Retention
A regional endpoint holds the request in one place. A global endpoint lets the provider send it wherever capacity is free. Training opt-out and zero data retention are separate switches again, and ZDR only governs how long content is kept. It says nothing about the region that handled it. Abuse-monitoring retention can outlive it too, along with human review from another country.
Timing catches people out. OpenAI’s European data residency is set on new API Projects, and an existing project cannot be converted. Anthropic fixes workspace geography when the workspace is created. Either way, the decision is made once, when someone clicks create, usually well before compliance has seen the account.
As of November 2026, the first-party Anthropic API offered global or US inference only, with US-only workspace storage, and EU processing for Claude ran through AWS Bedrock or Google Vertex AI. OpenAI’s Europe region supports in-region processing for eligible endpoints on new Projects. Regional or US-only processing can carry a price multiplier. Where a model was built matters to some buyers too, which is a separate comparison of Chinese and Western open-weight models.
Managed Models in Your Cloud Region: When Is Your Cloud Account Enough?
Running Claude or GPT through your own cloud account keeps data in the region when the inference profile is pinned to a single region. A cross-region inference profile spreads requests across several regions within a geography. This resilience feature quietly widens the residency boundary.
The region is enforced by two things. Identity and access management (IAM) conditions list the model identifiers and regions your workloads may call, and the cloud provider’s data processing agreement (DPA) governs the processing itself. Where sovereignty concerns extend to the operator, confidential computing is available on some instance families.
A managed service also works for a model you trained yourself. SPD Technology built a lightweight domain-specific LLM for children aged 9 to 12 for a US EdTech company, fine-tuned with LoRA and served through AWS Bedrock. A smaller, purpose-built model on a managed service in your own cloud account keeps the region a configuration choice rather than a contract negotiation.
Model availability by region changes from month to month, so check it on a schedule. For teams already moving AI workloads into a compliant cloud region, the residency work is usually part of the migration.
Open-Weight Models in Your VPC: When Does Self-Hosting Win on Residency?
Self-hosting wins on control of location, keys, and logs, which makes residency straightforward to prove. The weights come from an open-weight model, and the open-weight vs. open-source distinction matters here, because access to the weights says nothing about the license.
Security becomes a separate question. Patching, access control, network isolation, and logging hygiene become your responsibility, and the operational load of running a self-hosted LLM is the real price of this row. With a model on your own infrastructure, residency becomes a deployment decision and no longer depends on a contract negotiation.
On-Prem and Air-Gapped: What Does Sovereign AI Require?
Sovereign AI asks for more than a region. The model, the infrastructure, the operator, and the legal jurisdiction must all sit under one national or regional authority. Run an EU region operated by a company headquartered elsewhere and your data stays in the EU, while the company running it can still be handed a foreign legal order. Cloud sovereignty is the name for that gap. On-premises or air-gapped deployment is what closes it.
Localization statutes and national-security work make this option mandatory, usually by requiring local data centers. The cost comes in two stages. Hardware and facilities are paid for first, and each new model generation then brings new GPUs and a fresh validation cycle. Any budget built on owned hardware has to include that refresh alongside the first install, which is part of the AI software development cost most plans undercount.
Where Does AI Data Leak Beyond the Model?
Residency usually breaks outside the model call. The vector database, the tracing tool, the eval pipeline, the agent’s tools and memory, and any unpinned fallback route all move data across the boundary. The model endpoint setting controls none of them, and the cost of missing one is rising. IBM’s Cost of a Data Breach 2026 put the global average breach cost at a record $4.99 million, up 12%, with AI-driven attacks rising 56% year over year and adding roughly $1 million per breach.
Mapping these data flows is routine AI data security work, although many residency programs leave it out.
Data Path | What Leaves the Boundary | Why Teams Miss It | Control |
|---|---|---|---|
Vector database and embeddings | Document chunks and vectors derived from them | Managed vector DB defaults to another region; embeddings are treated as anonymous | Pin region; treat embeddings as derived personal or confidential data |
Observability and tracing | Full prompts, tool results and outputs | SaaS tracing tool hosted elsewhere; payload logging on by default | Self-host or region-pin traces; redact at source; retention limits |
Evals and LLM-as-judge | Production samples sent to a second model for scoring | Eval data is seen as “test data”; judge model sits on a different provider | Run judges on the same approved endpoint; synthetic or masked eval sets |
Agent tool calls and MCP servers | Whatever the agent passes to a tool: queries, records, files | Each MCP server or API is a separate service with its own location and operator | Tool allow-list by region; scoped permissions; log every call |
Agent memory | Long-lived summaries of past sessions | Stored by the platform, not where inference runs | Memory store in region; expiry; no regulated data in memory by default |
Model routing and fallback | Requests rerouted on outage or rate limit | Gateway falls back to a global endpoint or another provider | Region allow-list enforced in the gateway; fail closed, not open |
Provider abuse monitoring and support | Retained copies; human review from another country | Covered in the data processing agreement, not in the product settings | ZDR where eligible; check who can access and from where |
Sub-processors | Data handed to the provider’s own vendors | The AI feature inside a SaaS tool calls a model provider you never contracted | Sub-processor list with locations; change notification rights |
Caches, backups and disaster recovery replicas | Prompt caches, snapshots, replicas | Disaster recovery region chosen for resilience, not compliance | Disaster recovery inside the approved geography; documented |
Data Path
Vector database and embeddings
Observability and tracing
Evals and LLM-as-judge
Agent tool calls and MCP servers
Agent memory
Model routing and fallback
Provider abuse monitoring and support
Sub-processors
Caches, backups and disaster recovery replicas
What Leaves the Boundary
Document chunks and vectors derived from them
Full prompts, tool results and outputs
Production samples sent to a second model for scoring
Whatever the agent passes to a tool: queries, records, files
Long-lived summaries of past sessions
Requests rerouted on outage or rate limit
Retained copies; human review from another country
Data handed to the provider’s own vendors
Prompt caches, snapshots, replicas
Why Teams Miss It
Managed vector DB defaults to another region; embeddings are treated as anonymous
SaaS tracing tool hosted elsewhere; payload logging on by default
Eval data is seen as “test data”; judge model sits on a different provider
Each MCP server or API is a separate service with its own location and operator
Stored by the platform, not where inference runs
Gateway falls back to a global endpoint or another provider
Covered in the data processing agreement, not in the product settings
The AI feature inside a SaaS tool calls a model provider you never contracted
Disaster recovery region chosen for resilience, not compliance
Control
Pin region; treat embeddings as derived personal or confidential data
Self-host or region-pin traces; redact at source; retention limits
Run judges on the same approved endpoint; synthetic or masked eval sets
Tool allow-list by region; scoped permissions; log every call
Memory store in region; expiry; no regulated data in memory by default
Region allow-list enforced in the gateway; fail closed, not open
ZDR where eligible; check who can access and from where
Sub-processor list with locations; change notification rights
Disaster recovery inside the approved geography; documented
Every processing stage adds a row to that map. A B2B financial intelligence publisher working across France, the UK, and the USA needed to extract structured data from unstructured financial documents at scale. SPD Technology built an extraction pipeline on NLP, YOLO, Camelot, AWS Textract, and GPT, scaling it from 25 to more than 50 source document structures and running document processing 3x faster at 5x lower cost. Every stage in a pipeline like that writes another artifact, and each artifact has its own storage location, operator, and retention clock.
Agents make this harder, because an agent decides at runtime which tools to call and which context to pull. The data map is no longer fixed at design time, and residency has to be enforced in the agent harness, which consists of the gateway, the tool allow-lists, and the guardrails around the model.
With guardrails for AI engineering in place, a region rule can fail closed when the pinned endpoint is unavailable. Logging every call at that layer also builds the audit trails a reviewer will ask for. A judge model scoring production samples is a second provider seeing real customer data, which belongs in the checks you run to evaluate AI agents before production.
Retrieval is the most common second store. SPD Technology built a RAG architecture on AWS with LangChain and a Mistral LLM for a French B2C fashion retailer, and it held 100% uptime at 30 requests per second. Every retrieval layer like that creates a second store derived from the first, with its own region to pin.
“Pinning the model endpoint is the easy part, and it is where most residency work stops. Everything that decides at run time which tool to call or which document to retrieve sits outside that boundary, so the region rule has to live in the gateway and the tool allow-list, where it can fail closed. A policy document cannot fail closed.” — Serhii Leleko, AI & ML Engineer at SPD Technology
Code, configuration, and secrets sent to cloud coding agents are data too. Scope the repositories those agents can read and strip secrets from the context, which is data minimization applied to code. The agent’s provider is another processor on the map, and another source of security risks in AI-generated code.
In most LLM data leakage incidents, the cause is a copy stored somewhere nobody mapped, and a model memorizing training data is much rarer. Mapping the paths is the main control, and the table above is a practical place to start.
Residency is only one of the gates a system has to pass before release, and the full AI production-ready checklist covers the others.
What Do GDPR, the EU AI Act, DORA, and HIPAA Require for AI Data?
Most legal requirements stop short of forcing AI data to stay in one country. They mainly regulate transfers and expect you to know where processing happens and to prove it. For an AI system, that is what data residency requirements amount to in practice. Localization laws are the exception, although they apply only to narrowly defined categories of data.
Regulation | Mandates Localization? | What It Means for an AI System | Verify |
|---|---|---|---|
GDPR / UK GDPR | No; restricts transfers outside the European Economic Area (EEA) / UK (adequacy, standard contractual clauses (SCCs), EU-US Data Privacy Framework) | A prompt with personal data sent to an out-of-region endpoint is a transfer; remote access can count as one too | Chapter V articles; EDPB guidance on transfers; ICO guidance for UK |
EU AI Act | No | Data governance and logging duties for high-risk systems; logs and datasets must live somewhere you can govern | Current application dates; see the Digital Omnibus note below this table |
DORA (EU financial entities) | No | ICT third-party risk: contracts must state where data is processed and stored; AI providers go in the register of information | Article references on contractual provisions and the register |
HIPAA (US health) | No | Any vendor touching protected health information (PHI), model provider included, needs a business associate agreement (BAA); ZDR is often a condition | Provider BAA scope by product |
National localization and sector rules (e.g., China PIPL, India RBI payment-data rules) | Yes, for defined data | Inference must run in country; usually means in-country cloud or on-prem | Current texts; scope of “important” or payment data |
Regulation
GDPR / UK GDPR
EU AI Act
DORA (EU financial entities)
HIPAA (US health)
National localization and sector rules (e.g., China PIPL, India RBI payment-data rules)
Mandates Localization?
No; restricts transfers outside the European Economic Area (EEA) / UK (adequacy, standard contractual clauses (SCCs), EU-US Data Privacy Framework)
No
No
No
Yes, for defined data
What It Means for an AI System
A prompt with personal data sent to an out-of-region endpoint is a transfer; remote access can count as one too
Data governance and logging duties for high-risk systems; logs and datasets must live somewhere you can govern
ICT third-party risk: contracts must state where data is processed and stored; AI providers go in the register of information
Any vendor touching protected health information (PHI), model provider included, needs a business associate agreement (BAA); ZDR is often a condition
Inference must run in country; usually means in-country cloud or on-prem
Verify
Chapter V articles; EDPB guidance on transfers; ICO guidance for UK
Current application dates; see the Digital Omnibus note below this table
Article references on contractual provisions and the register
Provider BAA scope by product
Current texts; scope of “important” or payment data
Last verified: November 2026. This is not legal advice; confirm the current texts with counsel.
The EU AI Act timeline changed in 2026, when the Digital Omnibus on AI, Regulation (EU) 2026/1744, entered into force on 27 July. It moved the obligations for stand-alone high-risk AI systems under Annex III from 2 August 2026 to 2 December 2027. Annex I systems embedded in regulated products moved to 2 August 2028. Obligations for general-purpose AI models and the transparency standards in Article 50 stayed on their original dates.
These dates can change again, so this section reflects the position as of November 2026, and counsel should be involved for any specific regime.
Contracts close the gap the law leaves open. Enterprise customers write residency clauses into their own agreements, which turns data residency requirements into a sales question for any B2B vendor shipping an AI feature. DORA sharpens it for firms answerable to financial regulators, since an AI provider inside fintech software development belongs in the register of information like any other. GDPR adds a step of its own, because a transfer that relies on standard contractual clauses also calls for impact assessments of the destination country’s laws.
Under HIPAA, the key document is the BAA, and any vendor that touches PHI needs one signed before a prompt carries patient data. Teams building for health and life sciences usually find that zero retention is a requirement. In one such project, SPD Technology’s engineers remediated the compliance gaps in an FSA/HSA payments platform and rebuilt its delivery pipeline on AWS ECS with Terraform and GitHub Actions. Release cycles dropped to under a day after the team closed the platform’s HIPAA and SOC 2 gaps, and an AI classification layer kept more than 200,000 eligible healthcare products in sync.
What Should You Ask an AI Vendor About Data Residency?
Start by asking where each copy of your data is processed, stored, and accessible from. For every answer, ask which setting or contract clause proves it. An AI vendor risk assessment that ends at a compliance badge tells you little about the request path, and enterprise AI security reviews tend to find that gap late. The questions below cover the data residency commitments worth getting in writing.
-
Where does inference run for our account, and is it pinned per request, per project, or per contract?
-
Is the regional setting on by default, and can it be changed after the project or workspace is created?
-
Where are prompts, outputs, files, embeddings, and history stored at rest, and for how long?
-
Is zero data retention available for our tier and endpoints, and which features are excluded?
-
Is our data used for training or product improvement, and is the opt-out contractual?
-
Which sub-processors touch our data, where are they, and how are we notified of changes?
-
Who can access our data for support or abuse monitoring, and from which countries?
-
What happens during an outage: does traffic fail over to another region or provider?
-
Do tool calls, web search, or connectors run outside the chosen region?
-
Can we see, per request, where it was processed (response metadata, logs, audit export)?
-
Which certifications (ISO 27001, SOC 2) cover the AI service itself, not just the data center?
-
For PHI or payment data: is a BAA or PCI scope available for this product?
Trustworthy answers come with a setting you can screenshot or a clause you can cite. If a vendor handles the first three questions and then goes quiet on sub-processors, failover, and per-request evidence, you have found the gaps while the contract is still open.
The same questions apply to the team that builds your AI system. Here is what to check when choosing an AI development partner.
Which Deployment Option Fits Which Data? A Decision Matrix
Classify the data first, then pick the least expensive option that the classification allows, and never work the other way around. An AI data residency decision that starts from a preferred vendor pays sovereign AI prices for public data, or puts regulated records on a global endpoint. Both failures come from the same reversed order.
Data Class | Public API (Regional, ZDR) | Managed Model in Your Region | Open-Weight in Your VPC | On-Prem / Air-Gapped | Minimum Controls |
|---|---|---|---|---|---|
Public | Yes | Yes | Yes | Overkill | Standard terms |
Internal | Yes, training opt-out | Yes | Yes | Overkill | DPA, opt-out, single sign-on |
Confidential (IP, contracts, material non-public information) | Conditional: regional + ZDR | Yes, single-region | Yes | Optional | Region-pinned traces and vector store, redaction |
Regulated personal / financial / health | Conditional: only with in-region processing, ZDR and BAA/DPA scope | Yes, with IAM-enforced region | Yes | Optional | Residency map, fail-closed routing, per-request evidence |
Localization-mandated | No | Only in-country region | Only in-country | Yes | In-country operator, local keys |
Data Class
Public
Internal
Confidential (IP, contracts, material non-public information)
Regulated personal / financial / health
Localization-mandated
Public API (Regional, ZDR)
Yes
Yes, training opt-out
Conditional: regional + ZDR
Conditional: only with in-region processing, ZDR and BAA/DPA scope
No
Managed Model in Your Region
Yes
Yes
Yes, single-region
Yes, with IAM-enforced region
Only in-country region
Open-Weight in Your VPC
Yes
Yes
Yes
Yes
Only in-country
On-Prem / Air-Gapped
Overkill
Overkill
Optional
Optional
Yes
Minimum Controls
Standard terms
DPA, opt-out, single sign-on
Region-pinned traces and vector store, redaction
Residency map, fail-closed routing, per-request evidence
In-country operator, local keys
Most enterprises run several of these rows at once, which makes the matrix part of a wider AI infrastructure strategy. One gateway that routes by data class keeps a public FAQ assistant and a claims file off the same path. The same gateway pattern comes up when building production AI with Claude, where model routing and residency become one piece of engineering.
Cost is the main reason to use the matrix. Regional processing carries a premium at several providers, and self-hosting brings GPU and MLOps costs that you pay whether the system is busy or idle. Apply the strictest row to every workload, and a compliance decision becomes a budget problem.
Moving a prototype built on a public API into a regulated deployment? Here is a 90-day path from MVP to production.
Why Teams Choose SPD Technology for Enterprise AI
SPD Technology treats residency as an engineering property of the system. Our engineers trace every path AI data takes: from the model call and retrieval through traces, evals, tool calls, memory, and fallbacks. We then enforce the region rules in the harness and the gateway and keep the evidence. On regulated workloads, this makes residency part of our agentic AI engineering from the first design review.
We work from either starting point. Some teams need us to define the residency model with them; others already have an architecture their data protection officer approved and need it delivered to a standard an auditor can check.
We also match autonomy to risk. Decisions about money, personal data, and architecture stay with people, a named senior engineer approves every release, and any change touching payments or PII passes a dedicated security review first. Our MLOps work follows the same discipline, because AI data governance is applied in the pipeline that ships the model.
Each release comes with an evidence package covering the change, the tests, the security checks, the sign-off, and the rollback, so an auditor or data protection officer can inspect it directly. The configuration stays with you, too. Routing rules, region allow-lists, eval suites, and agent configuration live in your repository, so the residency controls survive a change of partner.
Our Claude-certified architects already run Claude Code in production. SPD Technology also delivered an embedded SMB lending platform for a fintech lender from scratch in 18 months, built to PCI DSS, GDPR, and KYC/KYB requirements. It has since funded more than 4,000 businesses and facilitated over $350 million in financing.
SPD Technology is an AWS Select Tier Services Partner, an Adyen service partner, and a Select-tier member of the Claude Partner Network (Services Track), with an ISO/IEC 27001:2022-certified information security management system.
Key Takeaways
- The inference location determines which laws, operators, and controls apply, because an AI system re-sends its full context on every call.
- Storage residency and inference residency are separate settings, so data stored in the EU can still be processed elsewhere unless processing is pinned too.
- Zero data retention only limits how long a provider keeps prompts. Where the prompts ran is a separate question, so ZDR and regional processing each need their own check.
- A pinned endpoint proves very little on its own, since residency typically breaks in vector stores, tracing tools, LLM-as-judge evals, agent tool calls, and fallback routes.
- Agents choose tools and context at runtime, so residency must be enforced in the harness and the gateway through allow-lists and fail-closed routing.
- Most regulations restrict transfers and stop short of mandating localization, so the practical requirement is to know, control, and evidence where each request ran.
- Matching the deployment option to the data class keeps strict workloads compliant while public data avoids sovereign-AI costs.
In short: your model runs wherever the endpoint, the retrieval store, the traces, and the fallback route resolve at runtime. The setup is compliant only when each of those is pinned to an approved region and evidenced per request.
FAQ
What is the difference between data residency and inference residency?
Data residency usually refers to where data is stored at rest, and inference residency refers to where the model processes the prompt and produces the output. The two can differ, because a provider may keep history in one region while the GPUs that answer each request run in another. OpenAI and Anthropic both offer them as separate settings. For regulated data, check both and get both in writing.
Do the OpenAI and Anthropic APIs keep data in the EU?
They keep data in the EU only on certain routes. As of November 2026, OpenAI offered European residency with in-region processing for eligible new API Projects. Anthropic’s first-party API offered US or global inference, so EU processing for Claude was available through AWS Bedrock or Google Vertex AI. These settings are often fixed when a project or workspace is created, so the provider’s current documentation should be checked first.
Is a self-hosted LLM always more secure than an API?
Self-hosting is not automatically more secure. It gives you full control of location, keys, and logs, which makes residency easier to prove to an auditor. Security still depends on patching, access control, network isolation, and logging hygiene, and all of that becomes your job. As a result, a well-configured regional API with zero retention can carry less risk than a poorly run self-hosted model, and LLM security depends on how well the stack is operated.
What are data residency requirements in financial services?
In the EU, DORA requires financial entities to manage ICT third-party risk. That includes contract terms on where data is processed and stored, along with a register of providers. GDPR rules on cross-border data also apply to any personal data in a prompt, and some jurisdictions add payment-data localization. Auditors and customers will usually ask for evidence of where processing took place, so counsel should confirm which regime applies.
What does zero data retention mean for LLMs?
Zero data retention means the provider does not store request and response content at rest after the response is returned. This reduces exposure from stored copies and from abuse-monitoring retention, although it has no bearing on where the request ran. Some features fall outside it, and eligibility often depends on plan and endpoint. At some providers, it also requires prior approval.
Does GDPR require AI data to stay in the EU?
No. GDPR restricts transfers of personal data outside the EEA rather than requiring it to stay there. A transfer is lawful with an adequacy decision, standard contractual clauses plus a transfer impact assessment, or the EU-US Data Privacy Framework for certified US recipients. In practice, a prompt with personal data sent to an out-of-region endpoint is a transfer, so you need one of those grounds and a record of where each request ran.
Is sovereign AI the same as using an EU region?
No. An EU region settles where the data sits and where inference runs. Sovereign AI also requires that the operator, the keys, and the legal jurisdiction sit under the same authority, so a foreign parent company cannot be ordered to hand the data over. That usually means an on-prem deployment, an air-gapped environment, or a sovereign cloud run by a domestic operator.
Do embeddings in a vector database count as personal data?
They can. Embeddings are derived from source documents and may allow content or individuals to be inferred, particularly when they sit beside the stored chunks and metadata they came from. Treat the vector store with the same classification as its source, and pin its region and retention like any other copy.
How much does an AI data residency review cost?
The cost mostly follows the scope of the review. A focused review of one AI workload on a single provider typically costs $15,000 to $40,000 and takes two to four weeks. A full estate review typically runs $60,000 to $150,000 over six to twelve weeks, since it spans several clouds, multiple model providers, retrieval, tracing, evals, and agent tooling.
Several factors move the price within those ranges. They include the number of AI workloads, the data classes they touch, and the model providers and clouds in the path. Scope also grows when retrieval, tracing, evals, agent tools, and memory are included, or when the output has to include per-request evidence on top of a documented map. A scoping call settles these points before any number is quoted.
How long does it take to map and fix AI data residency?
Mapping and remediation follow different timelines. Mapping a single AI workload typically takes two to four weeks, and a multi-workload estate takes six to twelve. The duration depends on how many AI data paths exist, whether configuration lives in a repository or in provider consoles, and whether a gateway already sits in front of model calls.
Remediation then depends on what the mapping finds. A region setting or a gateway allow-list can usually be changed within a sprint. Migrating a tracing stack or a vector store tends to take four to eight weeks, and replacing a vendor whose contract cannot support residency can take one to two quarters.