Data Residency Architectures for AI: Where Personal Data May and May Not Flow

Overview

Residency architecture starts from an often-misstated legal baseline: the DPDP Act permits transfer of personal data outside India except to countries the Central Government restricts, so a blanket keep-everything-in-India rule is rarely a legal requirement. The binding residency duties come from overlays – the RBI’s 2018 direction that payment system data be stored only in India, government and PSU contract terms, possible localisation of notified data categories for Significant Data Fiduciaries, and customer contracts. The architectural task is therefore selective: classify data flows, decide which subset genuinely must stay, and build one of three patterns – full in-country, split control and data plane, or selective cross-border – while closing the telemetry and support channels that leak residency quietly. This is general planning information, not legal advice.

The legal baseline, stated precisely

Rule 15 of the DPDP Rules 2025 permits transfer of personal data to any country not restricted by the Central Government, subject to conditions it may notify, as published by MeitY. On top of that baseline sit the overlays that do bind: the RBI’s Storage of Payment System Data direction (2018) for payment system operators and participants; expectations attached to government and PSU workloads, typically through contract and empanelment terms rather than statute; health-sector guidance under the ABDM ecosystem; and the DPDP provision allowing the Government to notify categories of data that Significant Data Fiduciaries must not transfer outside India. The interplay for banking is detailed in Where BFSI AI Compute Must Sit.

Classify flows before drawing boxes

An AI platform moves at least six distinct artefact classes, and they do not carry equal residency weight:

• Raw personal data – source-of-truth records, documents, images. The class regulators care about most.
• De-identified or anonymised derivatives – outside DPDP if genuinely non-re-identifiable; the anonymisation claim must survive scrutiny.
• Model weights – generally not personal data, but weights fine-tuned on identifiable records deserve a documented position, since memorisation research shows extraction is sometimes possible.
• Embeddings and RAG indexes – derived from source text and often reversible enough to treat as personal data.
• Prompts and inference logs – live personal data in most enterprise assistants, and the class most often shipped abroad accidentally via SaaS APIs.
• Operational telemetry – metrics and crash dumps that can embed identifiers.

Pattern 1: everything in-country

All six classes stay on Indian soil: training, inference, storage, backups and DR all run in owned or colocated Indian facilities. This is the simplest position to defend and the natural fit for payment-data workloads, defence-adjacent programmes and PSU contracts – the model described in Sovereign AI Pods and Government & PSU AI. Its costs are capacity planning without a burst valve and full responsibility for the operational stack. It is worth being honest that this pattern is chosen for assurance simplicity as often as for strict legal necessity.

Pattern 2: India data plane, global control plane

Personal data, indexes, prompts and logs remain on GPU infrastructure in India, while non-data-bearing coordination – identity federation, CI/CD, fleet monitoring dashboards, license servers – may run globally. This suits multinationals standardising tooling across regions. The discipline is proving the control plane is genuinely data-free: dashboards must not ingest payloads, traces must be scrubbed of prompts, and crash dumps must stay local. Document the boundary as a data-flow diagram with named egress points, because an auditor will ask for exactly that.

Pattern 3: selective cross-border

Most data stays in India; specific, classified flows cross the border deliberately – for example, de-identified datasets sent to a global research hub, or non-sensitive workloads using an offshore inference API. Each flow needs an entry in a transfer register: what class, what destination, what legal basis, what contract clause. This pattern extracts the most value from the DPDP negative-list model but carries the highest ongoing review burden, and it collapses if the classification step was optimistic. Federated approaches, where models move and data does not, are a further variant covered in Federated Learning Across Hospitals.

Where residency quietly leaks

Residency claims usually fail at the edges, not the core:

• Vendor telemetry and call-home – cluster managers, storage arrays and observability agents defaulting to offshore endpoints.
• Support tunnels – remote vendor sessions that expose consoles and data paths across the border during incidents.
• Log and trace shipping – SaaS APM and SIEM tiers hosted abroad receiving prompts or identifiers inside spans.
• Backups and DR – replication targets or backup SaaS in foreign regions, including deleted-data retention.
• Model and dataset artefacts – checkpoints synced to global registries or shared drives by developer habit.

Each is fixable – regional endpoints, supervised support sessions, scrubbing pipelines, in-country DR – but only if listed and owned.

Choosing a pattern

Frequently asked questions