Data Residency for AI Apps: DPDP and GDPR Routing Guide

What builders need to know before touching the router

• India's DPDP Act does not mandate blanket localisation. Section 16 is a negative list — transfers are allowed to every country except those the Central Government blacklists by notification, and as of July 2026 no such list has been notified. The sharp edges are elsewhere: sectoral rules (the RBI's payment-data directive) and a DPDP Rules, 2025 power to pin specified data categories inside India for Significant Data Fiduciaries.
• UK GDPR and EU GDPR care about the mechanism, not the postcode. Neither requires data to stay home; both require a lawful transfer route — adequacy, SCCs (plus the UK Addendum) or the ICO's IDTA, or BCRs — and evidence that the destination actually matches the paperwork.
• At-rest residency and in-region inference are different products. Several providers will store your data in your region while processing it somewhere else. Your architecture must be built around where inference runs, not where logs sleep.
• The gateway is the enforcement point. Classify each request's data origin, route it to an approved endpoint, and log the decision. If routing lives in application code scattered across services, you cannot prove compliance and you will eventually mis-route.
• Masking PII at the perimeter shrinks the problem but doesn't erase it. Pseudonymised tokens are still personal data under GDPR-family law; masking is data minimisation and breach-blast-radius control, not a legal teleporter.

The three forces pushing residency into your architecture

Data residency stopped being a legal-team problem the day LLM inference became the most data-hungry component in the stack. Three forces now land on the infrastructure roadmap at once.

Regulation. India's Digital Personal Data Protection Act, 2023 finally got its operating manual when the DPDP Rules, 2025 were notified on 14 November 2025, with obligations phasing in over roughly eighteen months into 2027. The UK continues under UK GDPR as amended by the Data (Use and Access) Act 2025, with the ICO's international-transfer regime governing anything leaving the country. The EU adds the AI Act on top of GDPR: its general application date is 2 August 2026, although the Digital Omnibus agreement reached provisionally in May 2026 — pending formal adoption — defers the stand-alone high-risk (Annex III) obligations to 2 December 2027. Penalties under the AI Act have applied since 2 August 2025, and for prohibited practices under Article 5 they reach €35 million or 7% of total worldwide annual turnover, whichever is higher, per Article 99. The AI Act is not a residency law — but it is the reason EU customers now audit where your model inference physically happens.

Sovereignty politics. Governments increasingly treat inference location as leverage. Section 16's blacklist power means the Indian government can switch off a destination country with a notification; the DPDP Rules give it a second lever aimed specifically at large platforms. Betting your architecture on "no list exists today" without a routing layer that could honour one tomorrow is a bet against a stroke of a pen.

Customer contracts. In practice this force bites first. UK enterprise buyers write "no processing outside the UK/EEA" into DPAs; Indian BFSI customers inherit the RBI's localisation posture and push it downstream to every vendor. If you sell into both markets — the normal condition for builders on this site — you will end up with contractual residency obligations stricter than any statute, and you need one architecture that satisfies all of them simultaneously.

What DPDP, UK GDPR and EU rules actually require of an LLM app

The table below is deliberately narrow: it answers only "what does this regime demand of a team routing personal data through LLMs?", as of July 2026. For the broader Indian compliance picture — consent, notices, grievance mechanisms — see our DPDP Phase 2 compliance playbook and the companion consent-manager checklist; this guide stays on the infrastructure side of the line.

Two asymmetries are worth internalising. First, India is currently the most permissive of the three on transfers and simultaneously the one whose posture can change fastest — a notification, not new legislation, flips it. Second, the UK and EU regimes look similar but diverge in the paperwork: since the European Commission renewed the UK's adequacy decisions on 19 December 2025 (valid to 27 December 2031), EEA-to-UK flows are frictionless, but UK-to-elsewhere transfers follow the ICO's own instruments, not Brussels'. A dual-market app therefore carries at least three distinct transfer-evidence bundles.

The region-routing gateway: classify, route, log

The pattern that makes all of this operable is boring on purpose: a single LLM gateway that every service calls, which (1) classifies the data origin of each request, (2) selects an endpoint from an allow-list for that origin, and (3) writes an immutable log of the decision. If you already run a gateway for failover and cost reasons — see our comparison of LiteLLM, OpenRouter and Portkey — residency routing is an extension of it, not a new tier.

The classification step is where teams go wrong first. Data origin is a property of the data subject and tenant contract, not of the caller's IP address. A London employee of an Indian bank querying customer records is processing Indian-regulated data from a UK IP; geo-IP routing would send it precisely the wrong way. Derive origin from the tenant record and the dataset's classification, set at onboarding, exactly as you would derive a tenant ID — the same fail-closed discipline described in our multi-tenant isolation guide.

# Residency policy — the only place routing rules live.
# Origin comes from the tenant contract, never from geo-IP.

RESIDENCY_POLICY = {
    "IN-REGULATED": {                # RBI-scope or SDF-notified categories
        "allowed": ["vllm-mumbai"],  # in-country inference only
        "mask_pii": False,           # nothing leaves, masking optional
    },
    "IN-GENERAL": {                  # DPDP-scope, no sectoral pin
        "allowed": ["vllm-mumbai", "openai-global"],
        "mask_pii": True,            # mask before any non-IN endpoint
    },
    "UK": {
        "allowed": ["bedrock-london", "openai-uk"],
        "mask_pii": False,
    },
    "EU": {
        "allowed": ["bedrock-frankfurt", "vertex-eu", "openai-eu"],
        "mask_pii": False,
    },
    "US-ROW": {
        "allowed": ["openai-global", "bedrock-us"],
        "mask_pii": False,
    },
}

def route(tenant, dataset):
    origin = dataset.residency_class or tenant.residency_class
    policy = RESIDENCY_POLICY.get(origin)
    if policy is None:
        # Fail closed: unclassified data gets no LLM call,
        # never a default region.
        raise ResidencyError(f"No residency class for tenant {tenant.id}")
    endpoint = pick_healthy(policy["allowed"])   # failover stays inside
    audit_log.write(                             # the allow-list
        tenant=tenant.id, origin=origin,
        endpoint=endpoint, masked=policy["mask_pii"],
    )
    return endpoint, policy["mask_pii"]

Note what the policy table encodes: failover must stay inside the origin's allow-list. A resilience layer that helpfully retries a failed Frankfurt call against a US endpoint has just converted an outage into a reportable transfer. Health-based fallback is fine; cross-region fallback is a policy decision that belongs in the residency table, nowhere else.

Hybrid serving: a local model for regulated data, APIs for the rest

Once routing is centralised, the natural cost structure is a hybrid: a self-hosted open-weight model in the regulated perimeter for the small fraction of traffic that genuinely cannot leave, and frontier APIs for everything else. The trade-offs of running your own inference are covered in our self-host or API guide; the short version for residency work is that a vLLM deployment in Mumbai or London is the only option whose residency guarantee you can verify with a traceroute rather than a contract clause.

Here is the same policy expressed as a LiteLLM proxy config using its documented tag-based routing. Three deployments share one public model name; the tag on the request — set by your gateway from the tenant's residency class, never by the end client — decides which is eligible.

# litellm config.yaml — one model name, three residency-pinned backends
model_list:
  - model_name: chat
    litellm_params:
      model: hosted_vllm/meta-llama/Llama-3.3-70B-Instruct
      api_base: https://inference.in-mumbai.internal/v1   # self-hosted, in-country
      tags: ["region:in"]

  - model_name: chat
    litellm_params:
      model: bedrock/anthropic.claude-sonnet-4-6
      aws_region_name: eu-central-1                       # Frankfurt, EU-pinned
      tags: ["region:eu"]

  - model_name: chat
    litellm_params:
      model: openai/gpt-5.2
      api_key: os.environ/OPENAI_API_KEY                  # global endpoint
      tags: ["region:global"]

router_settings:
  enable_tag_filtering: true       # requests only match deployments
                                   # sharing at least one tag

# Gateway-side call — tag derived from the tenant, not the caller
from openai import OpenAI

client = OpenAI(base_url="https://llm-gateway.internal/v1", api_key=GATEWAY_KEY)

response = client.chat.completions.create(
    model="chat",
    messages=[{"role": "user", "content": masked_prompt}],
    extra_body={"tags": ["region:in"]},   # resolved by route() above
)

This traces end to end: the application asks for chat, the gateway stamps the residency tag, LiteLLM's tag filter narrows the candidate pool to deployments carrying that tag, and ordinary load-balancing and retries operate only within that pool. Adding a new compliant backend is a config change; adding a new jurisdiction is one more tag. The application layer never learns geography exists.

PII masking at the perimeter

For the middle tier of traffic — data that is DPDP- or GDPR-scoped but not sector-pinned — the highest-leverage control is masking personal identifiers before the request crosses the residency boundary, and re-hydrating them after the response returns. The provider sees structure ("customer [PERSON_7f3a] with account [ACCT_91c2] disputes a charge"), never identity. The mapping table lives inside the perimeter, in your key-management scope, and nothing downstream can reverse it.

# Perimeter masking with Microsoft Presidio (open source).
# Mapping store stays inside the regulated boundary.
from presidio_analyzer import AnalyzerEngine
from presidio_anonymizer import AnonymizerEngine
from presidio_anonymizer.entities import OperatorConfig
import secrets

analyzer = AnalyzerEngine()
anonymizer = AnonymizerEngine()

def mask(text: str, vault: dict) -> str:
    findings = analyzer.analyze(
        text=text, language="en",
        entities=["PERSON", "EMAIL_ADDRESS", "PHONE_NUMBER",
                  "IN_PAN", "IN_AADHAAR", "UK_NHS", "CREDIT_CARD"],
    )
    def tokenise(original: str) -> str:
        token = f"[PII_{secrets.token_hex(4)}]"
        vault[token] = original          # in-perimeter store only
        return token
    result = anonymizer.anonymize(
        text=text, analyzer_results=findings,
        operators={"DEFAULT": OperatorConfig("custom", {"lambda": tokenise})},
    )
    return result.text

def unmask(text: str, vault: dict) -> str:
    for token, original in vault.items():
        text = text.replace(token, original)
    return text

# usage: masked = mask(prompt, vault) -> LLM -> unmask(reply, vault)

Three engineering realities keep this honest. Recall is imperfect — Presidio's built-in recognisers cover Indian PAN and Aadhaar formats and UK NHS numbers, but free-text identifiers ("my neighbour the Wembley dentist") slip through, so treat masking as risk reduction layered on top of a lawful transfer mechanism, not instead of one. Latency is real but small — a perimeter masking pass typically adds tens of milliseconds, trivial against LLM inference. And legally, masked-but-relinkable data is pseudonymised, not anonymised: it remains personal data under UK and EU GDPR, and prudent reading says the same under DPDP. The pattern's genuine wins are data minimisation, a dramatically smaller breach blast radius, and the ability to tell a regulator that no raw identifier ever left the perimeter — which is a very different conversation from "we sent everything and trusted the DPA".

Choosing providers: regional endpoints, retention terms, audit evidence

Provider residency claims deserve the same scepticism as benchmark claims. The table below reflects publicly documented positions as of July 2026 — verify against the provider's current documentation before signing anything, because this surface moves quarterly.

The procurement question that separates serious providers from the rest is the audit-evidence one: what artefact do I show a regulator? Useful answers include a DPF or Data Bridge certification entry, signed SCCs/IDTA with a named processing location, a region-pinned endpoint in the API contract, and SOC 2 / ISO 27001 reports whose scope covers the regional deployment. "Our infrastructure is compliant" on a sales slide is not an artefact.

Common pitfalls

Routing on geo-IP instead of data classification. The caller's location and the data's legal home are independent variables. Classify tenants and datasets at onboarding; treat IP only as a fraud signal.

Letting failover cross the residency boundary. Retry logic that falls back to another region under load is the single most common way a clean architecture silently violates its own DPA. Keep fallback pools inside each origin's allow-list.

Confusing at-rest residency with in-region inference. Storage location is the easy half and the one providers advertise. If the contract says "data stored in India/UK", ask the follow-up question about where the GPUs are.

Forgetting the ancillary data flows. Prompts are only one flow. Embeddings shipped to a US vector-search SaaS, observability traces in a US APM tool, and evaluation datasets exported to a labelling vendor are all transfers of the same personal data. The residency table must govern every downstream sink, not just the completion endpoint.

Assuming masking equals anonymisation. Relinkable tokens are pseudonymised personal data. Claiming otherwise in a DPIA is how a good engineering control becomes a compliance finding.

Treating RBI scope as DPDP scope. The RBI's April 2018 directive on payment-system data is stricter than DPDP and does not care about DPDP's permissive transfer default. If payment flows touch your LLM features — dispute summarisation is the classic case — that data is in-India-only regardless of what the DPDP Rules eventually say.

Next steps

A workable rollout order, drawn from teams shipping this today: first, classify tenants and datasets into residency classes and get them into the tenant record — nothing else works without it. Second, centralise every LLM call behind one gateway and add the tag-routing table, with fail-closed behaviour for unclassified traffic. Third, stand up one in-perimeter model for the genuinely pinned tier and wire the perimeter masker for the middle tier. Fourth, chase the paperwork: SCCs or IDTA per destination, ZDR terms per provider org, routing-mode confirmations per cloud endpoint. Fifth, turn on decision logging and rehearse the audit query before a customer asks it. As of July 2026 the regulatory floor is still moving — India's blacklist and SDF category powers are dormant but loaded, and the EU AI Act's general application lands on 2 August 2026 — but a gateway that routes on data origin absorbs any of those changes as a config edit rather than a re-architecture. That is the whole point of building it now.