EAAPL-CMP007 — Data Residency for AI Architecture

Status: Proven
Tags: privacy-act gdpr apra-cps234 data-isolation medium-complexity
Version: 1.1
Last Updated: 2026-06-12
Author: Enterprise AI Architecture Pattern Library

1. Executive Summary

AI systems introduce new vectors for cross-border data transfer that existing data residency controls were not designed to address. When a user query is sent to a cloud LLM API, it crosses borders. When documents are indexed into a vector store for RAG, embeddings are computed and stored somewhere. When a model is fine-tuned on enterprise data, training data is processed in a cloud provider's data centre. Each of these AI-specific flows must be assessed against applicable data residency obligations: GDPR Article 46 (cross-border transfers from the EU), Australian Privacy Act APP 8 (cross-border disclosure from Australia), and APRA CPS234 offshore risk notification requirements.

This pattern provides a reference architecture that ensures AI training, inference, and storage remain within required geographic boundaries. It covers: regional model deployment strategy; data sovereignty controls for RAG pipelines; technical controls preventing prohibited cross-border data transfer; audit evidence generation for regulators; APRA offshore risk notification obligations; GDPR Article 46 transfer mechanisms; and APP 8 accountability mechanisms. Cloud provider-specific architectures for AWS, Azure, and GCP regional isolation are included, along with on-premises sovereign deployment guidance.

2. Problem Statement

Business Problem

Organisations operating in Australia and/or the EU face legal obligations to keep personal data within jurisdiction or to ensure equivalent protection for cross-border transfers. Cloud AI services—especially managed LLM APIs—are predominantly operated from US data centres. The business pressure to use the most capable AI models conflicts directly with data sovereignty obligations, and many organisations are unaware of the extent to which AI operations transfer personal data across borders.

Technical Problem

Cloud LLM API calls, by default, route to the provider's nearest or lowest-latency endpoint—which is often not in the user's jurisdiction. RAG pipelines embed documents in vector representations and store them in managed vector stores that may be located in any region the provider offers. Fine-tuning jobs are submitted to cloud compute that may span multiple regions. Network traffic inspection is insufficient to detect these flows because they appear as HTTPS calls to legitimate cloud provider APIs.

Symptoms

• No documented mapping of which AI inference calls send data to which geographic regions
• Cloud LLM API contracts do not specify Australian or EU data processing locations
• Vector stores are created in default provider regions (us-east-1, eastus) regardless of data classification
• No audit evidence exists demonstrating that personal data remained in-jurisdiction during AI processing
• APRA or privacy regulator enquiry reveals organisation cannot confirm where regulated data was processed

Cost of Inaction

3. Context

When to Apply

• AI systems processing personal data subject to GDPR, Privacy Act, or other data residency regulation
• APRA-regulated entities using cloud AI services to process customer financial data
• Government agencies with Australian Signals Directorate (ASD) data classification requirements
• Healthcare organisations processing patient data with contractual or regulatory in-country requirements
• Any organisation with contractual data residency commitments to customers

When NOT to Apply

• AI systems processing exclusively synthetic or fully anonymised data with no re-identification risk
• AI systems processing publicly available, non-personal data only
• Research AI systems with explicit data sovereignty exemptions

Prerequisites

Industry Applicability

4. Architecture Overview

The Data Residency for AI Architecture implements geographic isolation at four layers: compute, storage, network, and audit.

Layer 1 — Regional Inference Endpoint Strategy Instead of sending AI inference requests to globally routed LLM API endpoints, the architecture deploys dedicated regional inference endpoints for each required jurisdiction. For Australian data: inference is routed to AWS Sydney (ap-southeast-2), Azure Australia East, or GCP Australia Southeast 1—regions that offer both the cloud provider's contractual commitment to keep data within Australia and the physical infrastructure to fulfil that commitment. For EU data: inference is routed to EU-region endpoints (AWS eu-central-1 Frankfurt, Azure West Europe Amsterdam, GCP europe-west1 Belgium) with GDPR-compliant Data Processing Agreements in place. The inference routing layer inspects each request's data residency tag and routes to the appropriate regional endpoint. Requests tagged as Australian personal data are never routed to US or EU endpoints; EU personal data is never routed to non-adequate-country endpoints.

Layer 2 — Data Sovereignty Controls for RAG Pipelines RAG pipelines introduce residency risk at three points: document embedding (compute); vector storage (storage); and retrieval (read access from inference context). The architecture addresses each: embedding computation runs in regional AI compute resources (the embedding model runs in-region, not as an API call to a cross-border endpoint); vector storage is created in a regionally isolated managed service (AWS OpenSearch in Sydney, Azure AI Search in Australia East, or a self-hosted pgvector instance on Australian infrastructure); and retrieval queries are routed only to the in-region vector store. Documents tagged as Australian personal data never leave the Australian region during the embed-store-retrieve cycle.

Layer 3 — Technical Controls Preventing Cross-Border Transfer Technical controls enforce residency at the network level, not just through application-level routing (which can be misconfigured). Controls include: VPC/VNet Service Endpoints that prevent traffic from leaving the regional cloud environment; egress firewall rules blocking outbound HTTPS to non-permitted AI API endpoints; Service Control Policies (AWS) or Azure Policy / GCP Organisation Policies that prohibit resource creation outside permitted regions; data loss prevention (DLP) policies that inspect outbound API calls and block calls containing personal data to non-permitted endpoints; and cloud-native geo-restriction on storage buckets and databases.

Layer 4 — Audit Evidence Generation Regulators require evidence, not assertions. The audit layer generates continuous audit evidence: cloud-native flow logs (AWS VPC Flow Logs, Azure Network Watcher, GCP VPC Flow Logs) recording all outbound traffic with destination IPs and geolocation tags; API Gateway access logs recording which AI endpoint each inference request was routed to; a Data Residency Compliance Report generated monthly that summarises: total inference requests by source jurisdiction and destination region, number of DLP blocks (cross-border attempts prevented), and any exceptions (requests requiring manual review). This report is retained as regulatory evidence.

APRA Offshore Risk Notification Where APRA-regulated entities use cloud AI services that process regulated data offshore (e.g., using an EU-region Azure OpenAI endpoint for non-Australian data), CPS234 ¶20 requires the entity to assess and manage the offshore risk. Where the processing is material, the entity must notify APRA under the offshore outsourcing notification regime. The architecture includes a materiality assessment workflow that evaluates whether planned offshore AI processing meets APRA notification thresholds, and a notification record if the threshold is met.

5. Architecture Diagram

6. Components

7. Data Flow

Primary Flow

Error Flow

8. Security Considerations

Security and Residency Controls

OWASP LLM Top 10 — Residency Controls

9. Governance Considerations

Residency Governance

Governance Artefacts

10. Operational Considerations

Monitoring and SLOs

Disaster Recovery

11. Cost Considerations

Cost Drivers

Indicative Cost Range

12. Trade-Off Analysis

Architecture Options

Architectural Tensions

13. Failure Modes

Cascading Failure Scenario

An organisation's AI inference routing system is refactored for performance. A change is made to the routing logic that removes the residency tag check, routing all inferences to the global endpoint (us-east-1) for lower latency. The DLP policy was not tested on the new routing path. Over three weeks, all AU personal data inference requests are routed through the US endpoint. A monthly compliance report (the only detective control) identifies the anomaly at week four. The privacy officer investigates and finds AU customer data—including health information—was processed in the US by a provider without Australian-jurisdiction contractual commitments. The organisation must notify the OAIC and conduct a data exposure assessment. APRA is notified under CPS234 ¶24 of a material information security incident. The root cause: no automated, real-time residency verification control—only monthly batch reporting.

14. Regulatory Considerations

15. Reference Implementations

AWS

Azure

GCP

On-Premises / Sovereign Cloud

16. Related Patterns

17. Maturity Assessment

Overall Maturity Label: Proven

18. Revision History