Data Residency for AI Deployments

Why data residency matters for AI

AI applications process customer data — names, accounts, conversations, documents, medical records, financial transactions. Three forces push data residency to the top of every AI architecture decision:

• Regulation — GDPR (EU), UK GDPR, UAE PDPL, Saudi PDPL, India DPDP, HIPAA, RBI guidance for BFSI, healthcare data laws by state/country
• Sovereign LLM concerns — passing data to US-hosted LLM APIs (OpenAI, Anthropic) creates cross-border transfer and potential surveillance exposure
• Customer expectations — enterprise customers, especially in regulated industries, increasingly require contractual data-residency commitments from their vendors

Residency options Iedeo supports

Pick the region that fits your regulatory and customer requirements:

• United States — AWS us-east-1 / us-west-2, Azure US, GCP US. HIPAA-eligible services for healthcare. See HIPAA architecture.
• European Union — Frankfurt (eu-central-1), Ireland (eu-west-1), Paris (eu-west-3). GDPR + EU AI Act aligned. See GDPR page.
• United Kingdom — London (eu-west-2). UK GDPR + DPA 2018 aligned.
• United Arab Emirates — UAE region (me-central-1) or Bahrain (me-south-1). UAE PDPL aligned, DIFC/ADGM-friendly.
• India — Mumbai (ap-south-1), Hyderabad (ap-south-2). DPDP-aligned, RBI-friendly for BFSI workloads.
• Singapore / APAC — Singapore (ap-southeast-1) for regional clients.
• On-premises — fully air-gapped deployments on client hardware. Suitable for defence, government, and ultra-sensitive workloads.
• Hybrid — some components in client region, others (e.g., aggregated analytics) in Iedeo cloud.

LLM provider choice by residency

Where the LLM lives affects residency. Our defaults by region:

• US-residency: Azure OpenAI Service (HIPAA-eligible), AWS Bedrock (Claude, Llama 3), or self-hosted Llama 3 / Mistral in client VPC
• EU-residency: Azure OpenAI Sweden / France region, AWS Bedrock EU regions, or self-hosted in EU
• UK-residency: Azure UK South, self-hosted in London region
• UAE-residency: Azure UAE North, AWS me-central-1, or self-hosted
• India-residency (DPDP/RBI): self-hosted Llama 3 / Mistral / Mixtral in Mumbai or Hyderabad. No external API calls.
• Sovereign / air-gapped: self-hosted only. Sarvam AI / BharatGPT / Krutrim for Indic workloads if available regionally.

Self-hosted open-source LLMs

For workloads where external LLM providers cannot be used, we deploy open-source models in your tenancy:

• Llama 3 (8B, 70B, 405B) — Meta's open-weight models, strong general-purpose
• Mistral / Mixtral 8x22B — efficient and high-quality, popular in EU
• Qwen / DeepSeek — strong reasoning, lower cost
• Sarvam / Krutrim / BharatGPT — Indic-language tuned for India workloads
• Falcon / OpenAssistant — for specific use cases

Trade-offs: self-hosted gives full data control and predictable cost, but requires GPU infrastructure (A100 / H100 / L40S) and ops capacity. We design the right trade-off per use case.

Cross-border data transfer mechanisms

When data must transit borders (e.g., Iedeo personnel in India accessing EU client systems for development), we use:

• Standard Contractual Clauses (SCCs) for EU-to-India transfer per EU Commission 2021/914
• UK Addendum to the EU SCCs for UK transfers
• Transfer Impact Assessments (TIA) per engagement, documented and available
• BAA flow-down for HIPAA workloads (US healthcare)
• Bastion-host / screen-share-only access — for high-sensitivity workloads, Iedeo personnel never receive a local copy of identifiable data
• De-identification before transit — wherever the use case permits, we de-identify data before transit out of the residency region

Decision framework

Use this to choose the right residency:

• Regulated industry (BFSI, healthcare, defence)? → Client region + self-hosted LLM, possibly air-gapped
• EU customer base? → EU residency, GDPR DPA, SCCs for Iedeo access
• UK customer base, FCA-regulated? → UK residency, FCA-aware architecture
• UAE / GCC customer base? → UAE residency, UAE PDPL DPA
• India customer base, BFSI? → India residency, RBI-aligned, DPDP-aware
• SMB / startup, low sensitivity? → Standard cloud region near customer base, hosted LLM provider with DPA
• Building for global customers? → Region-routing architecture — store EU customer data in EU, US in US, etc.

Cost implications

Honest trade-offs:

• Hosted LLM APIs (OpenAI, Anthropic) are typically 30-60% cheaper at low scale but have residency limits
• Self-hosted LLMs cost more in GPU infrastructure but become cheaper at high scale (typically >1M tokens/day)
• EU / UAE / India regions are typically 10-25% more expensive than US AWS regions
• On-prem deployment has highest upfront cost but no ongoing cloud fees

We model these trade-offs in our scoping proposals — you see real cost projections by residency option before deciding.

What we commit to

• Documented data flow diagram for every engagement, listing every system touching customer data
• Sub-processor list maintained, updated 30 days before changes
• Data residency commitment in the contract (MSA / SOW / DPA / BAA)
• Audit rights — client can inspect data flow, logs, controls at any time
• Return / destruction of customer data at contract end