Skip to main content
Guide4 min read

Agent data residency rules: where the prompts, tools, and memory must live

Procurement teams now ask 'where does the data live?' for every agent. EU Schrems III, India's DPDP, China's data laws, and 30+ jurisdictional rules. The architecture that satisfies them without 30 deployments.

"Where does the data live?" is the procurement question that kills more agent deals than any other in 2026. The honest answer "in a US data centre" loses contracts in Europe, India, China, the Gulf, and increasingly Brazil. Here is the architecture that scales without standing up 30 deployments.

What "data residency" actually requires

Three layers, all in scope:

  • Prompt and response data — anything the user sent or the agent returned.
  • Tool inputs and outputs — what the agent passed to MCP servers.
  • Memory — anything persisted between sessions.

Different regulators care about different layers. EU AI Act covers all three; sectoral rules (banking, healthcare) often add operational metadata.

The jurisdictional landscape

Roughly four tiers in 2026:

Strict-pin

Data must stay within national borders. Examples: China (PIPL), Russia (152-FZ), India (DPDP for sensitive categories), Saudi Arabia (PDPL).

Region-pin

Data must stay within an economic region. Examples: EU (GDPR + Schrems case law), UAE federal.

Vendor-controlled with SCCs

Cross-border allowed if the vendor signs Standard Contractual Clauses or equivalent. Default for most multinational SaaS.

Free

No specific residency rule. US federal (sectoral exceptions apply), most of LATAM today.

Most agents need to support tier 1 + tier 2 to be enterprise-viable.

The architecture

Three deployment shapes that survive scrutiny:

Single-region per tenant

Each tenant pinned to one region. Their data never leaves. Easy to explain; hard to support globally without N deployments.

Multi-region with routing

Tenant requests route to the right region. Auth and routing layer global; storage and inference regional. Most enterprise SaaS lands here.

Federated

Per-region deployments share metadata only; data is genuinely siloed. The strongest claim; the highest cost.

For most products, multi-region with routing is the right answer. Federated only where regulator pressure demands.

What to pin per region

Five components that must be regional for tier-1 / tier-2 jurisdictions:

  • Inference endpoints — model lives in the region.
  • Memory storage — vector store, semantic store, episodic log all per region.
  • Audit logs — see audit trails. Often residency-bound.
  • Key management — KMS or HSM in the region.
  • MCP servers handling user data — proxied or hosted in region.

What can be global: identity (with regional sub-accounts), product config, billing.

Cross-border fallbacks

When a user crosses borders mid-session, three patterns:

  • Pin by user origin — the user's home jurisdiction sets the region; all requests route there.
  • Pin by current location — risky; users do not understand it.
  • Pin by data sensitivity — sensitive data per home region; non-sensitive global.

Pin-by-origin is the safest default.

Vendor stack residency

Every layer below your agent has its own residency story. Verify:

  • Model vendor — Anthropic, OpenAI, Google all offer EU and emerging India residency.
  • Hosting — AWS, GCP, Azure regional availability matrix.
  • Memory — pgvector regional; Pinecone regions; Qdrant on your infra.
  • Observability — most major vendors offer regional ingestion.
  • MCP server vendors — many do not yet; this is the most common gap.

A single vendor breaking the chain breaks the residency claim.

Documentation auditors expect

Three artefacts:

  • Data flow diagram per region, showing every component the data touches.
  • Vendor matrix — what each subprocessor does, where it stores, what BAA / DPA is in place.
  • Cross-border evidence — explicit evidence that data does not cross borders even on retry, error, or backup.

The third is the most-failed in audits.

What does NOT count as residency

  • "Most of our data is in EU" — must be all of it, all the time.
  • Backups in a different region — counts as a transfer; document it.
  • Vendor processing transiently — even transient processing counts in some jurisdictions.
  • CDN caches outside the region — yes, even those.

Cost model

Multi-region adds:

  • 2–4x infrastructure cost for the same workload.
  • Operations overhead — monitoring across regions.
  • Data sync complexity — anything global needs careful design.

Pricing accordingly is essential; the contracts you win pay for it.

Common mistakes

  • Auditing only your code — vendor stack is in scope.
  • No periodic audit — vendor regions change; refresh quarterly.
  • Soft-pinning via routing logic — must be hard-pinned at storage.
  • Forgetting backups and DR — most violations happen here.

Where this is heading

Three trends by 2027: more strict-pin jurisdictions (Brazil, Indonesia, Vietnam likely candidates), standardised "residency manifests" in MCP, and certifications (SOC2-style) specifically for residency claims. Build the multi-region pattern now.

Loadout

Build your AI agent loadout

The directory of MCP servers and AI agents that actually work. Pick the right loadout for Slack, Postgres, GitHub, Figma and 20+ integrations — with install commands ready to paste into Claude Desktop, Cursor or your own stack.

© 2026 Loadout. Built on Angular 21 SSR.