AI Data Residency Controls: Enforcing the Region Boundary at the Gateway
AI data residency requirements show up under GDPR, the EU AI Act, sector regulations like DORA and HIPAA, and national rules such as the Reserve Bank of India circulars. The control that survives audit binds the residency rule to the request at the gateway, routes the call to a region-resident model endpoint, and records the region of decision in the per-decision audit log. This walkthrough covers the three residency conditions, the routing patterns that enforce them, and the audit-record fields that survive a regulator request.
A bank in Frankfurt, a hospital in Toronto, and a payments processor in Mumbai run the same enterprise AI use case and hit three different residency regimes. GDPR Article 44 governs the Frankfurt case. PIPEDA and the Office of the Privacy Commissioner of Canada guidance on generative AI govern the Toronto case. The Reserve Bank of India's data localization circulars govern the Mumbai case. The control that survives audit binds the residency rule to the request at the gateway, routes the call to a region-resident model endpoint, and records the region of decision in the per-decision audit log. The control that fails ships everything to us-east-1 and writes "data is encrypted" on the audit certificate.
I want to walk through the three residency conditions, the routing patterns that enforce them, and the audit-record fields that survive a regulator request.
The three residency conditions
AI data residency rules vary by regime, but the requirements collapse into three conditions.
Condition 1: where the inference runs
Most residency regimes require that personal data be processed in a defined geography. For an AI deployment, processing means inference: the model receives the prompt and produces the response. The condition is that the model endpoint sits in an approved region. AWS Bedrock supports region selection. OpenAI and Anthropic publish residency variants. A deployment that routes EU personal data to a us-east-1 endpoint violates the condition regardless of how the data is encrypted in transit.
Condition 2: where the audit record lives
A regulator's right of access usually extends to the audit record. GDPR Article 15 (right of access by the data subject) and EU AI Act Article 12 (record-keeping over the lifetime of the system) presume that the record is reachable to the regulator. A record stored only in an out-of-region object store fails Condition 2 even if the inference satisfied Condition 1.
Condition 3: where the policy decision is made
The policy decision combines the prompt, the caller's identity, the data classification, and the policy in force. The combination contains personal data (the prompt) and identity metadata (the caller). Some regimes treat the policy decision as a processing operation in its own right. The gateway that makes the decision should sit in the same region as the inference and the audit record, or the deployment risks Condition 3 by exporting the decision metadata across the boundary.
The routing patterns that enforce the conditions
Three patterns hold up under audit.
Pattern 1: region-bound gateway per residency regime
Run one gateway per region. The EU gateway routes only to EU-resident model endpoints and writes audit records to EU storage. The Canada gateway routes to Canada-resident endpoints. The India gateway routes to India-resident endpoints. The agent identity is bound to the region by the workload identity assigned at deployment.
The pattern is the simplest to defend at audit and the most expensive to operate. Each region runs its own gateway with its own policy registry and its own audit store. The platform team maintains parity across regions through policy code and deployment automation.
Pattern 2: single global gateway with region-aware routing
Run one gateway that resolves the residency rule per request. The natural-person identity carries a region attribute from the identity provider; the gateway routes to the region-resident model endpoint and writes the audit record to the regional store.
The pattern requires the gateway to be available in every region where requests originate and the audit-store layer to be partitioned by region. The benefit is one policy plane to operate; the cost is a more complex gateway and more careful failure-domain analysis.
Pattern 3: hybrid for migration
A common migration pattern starts as Pattern 2 (global with region-aware routing) and migrates to Pattern 1 (per-region gateway) when the workload reaches a regional scale that justifies the operational cost. The transition produces an interim period where the audit records are partitioned but the policy plane is shared.
The audit record fields that prove the routing
The audit record must show the region of inference, the region of audit storage, and the region of policy decision. The fields below survive a regulator request.
The data_subject_region field is the one most deployments fail. The natural-person identity carries the region attribute from the identity provider, but the audit record often loses it because the application that wrote the record never received it. The gateway is the layer that has both the verified identity and the policy plane; the gateway is the layer that writes the record correctly.
Where the residency rules sit by regime
A short map across the regimes most enterprise AI deployments hit.
EU: GDPR Articles 44 to 49 govern cross-border transfers. The EU AI Act adds Article 12 record-keeping requirements that operate alongside GDPR. EU-resident inference and EU-resident audit storage are the floor.
UK: UK GDPR mirrors the EU rules; the International Data Transfer Agreement (IDTA) is the transfer mechanism.
Switzerland: The Federal Act on Data Protection (revFADP) sets equivalent requirements to GDPR.
Canada: PIPEDA governs the federal layer; provincial laws (Quebec Law 25) add additional requirements. The OPC's generative-AI principles describe expectations on transparency and on records.
India: The Reserve Bank of India circulars on payment data and the Digital Personal Data Protection Act 2023 govern data localization for financial-services and personal data respectively.
US: Sector-specific (HIPAA for health, GLBA for finance, FERPA for education). HIPAA requires Business Associate Agreements (BAAs) with model providers and does not yet require residency in the same way GDPR does; state laws (California CPRA, Colorado AI Act) add layers.
How residency interacts with model availability
Not every model is available in every region. The gateway is the layer that mediates the gap.
When the EU-resident user requests a model that is only available in us-east-1, the gateway refuses the request and writes the refusal to the EU-resident audit store. When the model is available in an EU region (Bedrock in eu-west-1, Azure OpenAI in West Europe), the gateway routes the request to the regional endpoint. The platform team's job is to keep the routing table current as model availability changes; the policy plane treats the table as policy code.
DeepInspect
DeepInspect implements region-bound routing and region-bound audit storage at the gateway. The policy decision binds to the natural-person region attribute from the verified identity, the gateway routes to the region-resident model endpoint, and the audit record is written to the regional audit store. The fields in the audit record include the data_subject_region, the gateway_region, the model_endpoint, and the audit_storage_region.
Each region's policy plane is operated by the same control plane and the policy code is the same across regions, which is what allows the platform team to satisfy GDPR Article 44, EU AI Act Article 12, and the RBI circulars from one operational posture. Book a mapping session at deepinspect.ai to walk through your residency regimes against the routing patterns.
Frequently asked questions
- Does the gateway need to be physically in the region?
Yes. The policy decision touches the personal data and the natural-person identity; the gateway processes both. For GDPR and similar regimes, the gateway has to sit in the region or in an approved adequacy jurisdiction. A gateway that lives in us-east-1 and processes EU personal data triggers the cross-border-transfer rules even when the inference itself is in eu-west-1.
- What about backup and disaster recovery?
The audit-store backup should stay in the region or in an approved adequacy jurisdiction. Cross-region replication for DR triggers the same transfer rules as the inference path. Most deployments operate the DR copy in a second region within the same adequacy jurisdiction (eu-west-1 primary and eu-central-1 DR for the EU).
- How does the gateway know the natural person's region?
The identity provider attaches a region attribute (or country attribute) to the verified token. The attribute comes from the user's directory record. The gateway resolves the attribute on every request and binds it to the policy decision. Deployments that do not yet have the attribute in the identity provider need to add it before the residency controls produce a defensible audit record.
- What happens if a user travels across regions?
The data-subject region is the residency-relevant attribute, not the request-origin region. A German employee using the corporate AI tool from a New York hotel still has data_subject_region = EU. The gateway routes accordingly. The request-origin region is recorded for observability but does not change the policy.
- How does this interact with model providers' own residency commitments?
Model providers publish residency variants of their endpoints (Bedrock regional endpoints, Azure OpenAI regional deployments, OpenAI EU residency). The gateway resolves the model-endpoint URL from the regional routing table. The provider's residency commitment is necessary but not sufficient; the gateway is the layer that ensures the right endpoint is selected for the right request.