6.3.2. Data Residency and Movement Compliance
💡 First Principle: Data residency compliance governs not just where data is stored, but where it is processed, where it moves during transit, and where AI models were trained. A customer record stored in the EU that gets processed by a model hosted in the US has crossed a regulatory boundary — even if the record itself never left its EU storage location.
Data Movement in AI Architectures:
| Data Movement Type | When It Happens | Compliance Risk |
|---|---|---|
| Storage at rest | Data in databases, blob storage, document libraries | Governed by data residency laws (GDPR Article 44+) |
| Processing location | AI model inference, data transformation, indexing | Must comply with processing location requirements |
| Transit | Data moving between services, regions, or providers | Encryption requirements, cross-border transfer rules |
| Model training data | Data used to train or fine-tune AI models | Training data jurisdiction affects model classification |
| Inference output | AI-generated responses containing derived information | Output may inherit classification of input data |
Architect's Compliance Design Decisions:
| Decision | Options | Trade-off |
|---|---|---|
| Model hosting region | Same region as data vs. optimal performance region | Compliance vs. latency |
| Knowledge source location | Co-located with model vs. centralized | Compliance vs. operational simplicity |
| Cross-border data flow | Prohibited, allowed with safeguards, or allowed freely | Compliance vs. global functionality |
| Model provider | Microsoft-hosted vs. third-party model | Control vs. capability |
Residency Design Patterns:
- Verify regional availability first. Models, Foundry Tools and agent services are not offered in every Azure region (see the region-support tables on Microsoft Learn). A design that depends on a service available only outside the required geography fails compliance before it is built, so check availability before choosing the architecture.
- Same design, regional deployment. For one agent serving EU, US and APAC customers, deploy the same agent configuration in each region with region-specific knowledge bases and model endpoints, so each customer's data is processed in-region. A single global knowledge base lets data cross borders; letting each region build its own agent gives up consistency and multiplies maintenance.
- Tools and partner APIs are processing locations too. Any call that carries personal data to an out-of-region Foundry Tool or partner API (for example, a Singapore-hosted API called from an EU model) is a cross-border transfer, even if nothing is stored there. Resolve it in this order: use an in-region deployment of the service; anonymize the data before it leaves (pseudonymized data is still personal data); only as a last resort rely on legal safeguards such as Standard Contractual Clauses. A compliance team cannot simply waive the requirement, Private Link secures the transport but does not change where processing happens, and both the sender and the partner carry compliance obligations.
- Outputs inherit classification. An AI response carries at least the classification of the data it was built from (a summary of Confidential data is Confidential), and aggregating several sensitive sources can raise it further. Classification follows content sensitivity, not the recipient or the fact that an AI generated the text.
⚠️ Common Misconception: Data residency compliance is only about where data is stored at rest. It encompasses data at rest, in transit, processing location, model training data jurisdiction, and cross-border data movement during AI inference.
Troubleshooting Scenario: A European company uses Azure OpenAI to process customer support queries. The model is hosted in the US East region. A GDPR audit flags that European customer data is being processed outside the EU — even though the Dataverse data stays in the EU datacenter. The issue: AI inference sends data to the model's processing location, which constitutes cross-border data movement even if no data is stored there. Data residency compliance encompasses five dimensions: data at rest (storage location), data in transit (encryption and routing), processing location (where inference occurs), model training data jurisdiction (where training happened), and cross-border data movement during AI inference.
⚠️ Exam Trap: Data residency isn't just about storage. AI inference creates data movement to the model's processing location — this counts as cross-border transfer under GDPR, even for real-time processing with no persistence.
Reflection Question: A European company uses Microsoft Foundry to deploy a custom model for customer support. The model is hosted in West Europe, but one of the Foundry Tools it calls for document processing is only available in East US. Customer data from EU citizens passes through this tool during processing. Design the compliant architecture.
