What Data Residency Actually Requires
Data residency requirements specify where data must be stored at rest and where it may be processed. Storage at rest refers to where data is written to disk and persisted: database servers, object storage buckets, backup systems, and log archives. Processing in transit refers to where data passes through computational systems: API servers executing business logic, LLM inference services, data transformation pipelines, and analytics systems. Both aspects must comply with residency requirements, not just the primary database. This is where many teams get caught: they correctly host their database in a UK AWS region but inadvertently process data through US-based LLM APIs, log analytics to a US-based logging service, or trigger email notifications through a US-based email provider. Each of these represents a data transfer out of the residency zone and may require assessment under UK GDPR's international transfer provisions. A complete data residency implementation maps every data flow in the product and verifies that each step either stays within the required region or has appropriate legal safeguards for any necessary transfers.
GDPR and International Data Transfer Rules
GDPR restricts the transfer of personal data from the EEA to countries outside the EEA that do not provide an equivalent level of data protection. The EU maintains a list of adequate countries: transfers to these countries are permitted without additional safeguards. UK GDPR has its own equivalent list. For transfers to countries without adequacy decisions (primarily the US for EU GDPR purposes), appropriate safeguards must be in place: the EU Standard Contractual Clauses (for EU GDPR), the UK International Data Transfer Agreement (for UK GDPR), or other recognised mechanisms. The EU-US Data Privacy Framework and UK-US Data Bridge provide adequacy for transfers to certified US organisations, making LLM API transfers to certified providers (OpenAI, Anthropic, Google, Microsoft) legally permissible under these frameworks. Data residency requirements that go beyond GDPR (such as enterprise requirements to keep data physically within the UK) require architectural choices that GDPR transfer mechanisms alone do not satisfy: the data must literally not leave UK servers, regardless of what legal agreements say.
Sector-Specific Data Residency Requirements
Beyond GDPR, several UK sectors have specific data residency requirements that AI products serving those sectors must meet. NHS Digital requirements for health data specify that data processed within NHS systems must generally remain within NHS-approved infrastructure in England and Wales. NHS suppliers must meet the Data Security and Protection Toolkit requirements, which include controls on where data is processed and stored. The FCA does not specify strict data residency requirements, but regulated firms must demonstrate that outsourcing arrangements (including cloud and AI services) maintain adequate oversight and risk management. This effectively requires firms to know where their data is being processed and to be able to demonstrate control. HMRC data and government contract data often requires UK data processing under Crown Commercial Service framework agreements. For AI products targeting public sector and NHS customers, understanding these requirements before building is essential: retrofitting data residency support after deployment is costly and sometimes requires significant re-architecture.
Architectural Patterns for Data Residency
Supporting data residency requires deliberate architectural choices at multiple levels. At the infrastructure level, deploy in cloud regions that correspond to the required jurisdiction. For UK data residency, AWS eu-west-2 (London) and Azure UK South (London) are the standard choices. For EU data residency, AWS eu-west-1 (Ireland) and eu-central-1 (Frankfurt) are common. At the database level, confirm that your database service (Supabase, Neon, PlanetScale) supports region selection and offers data residency guarantees in their terms. Verify that automatic backups, read replicas, and disaster recovery data do not replicate to out-of-scope regions. At the LLM inference level, the major LLM providers offer EU-based endpoints. Azure OpenAI Service can be deployed in European regions. Google Vertex AI offers EU data residency options. Anthropic offers EU-region API processing for enterprise customers. If your AI product sends personal data to LLM APIs, using a provider that offers UK or EU data processing for inference is necessary for strict data residency compliance.
Multi-Region Architecture for Enterprise Customers
Enterprise customers in different geographies may have different data residency requirements: a UK enterprise customer requires UK data residency, an EU customer requires EEA data residency, a US customer has different requirements. Satisfying all of these requires a multi-region architecture where each customer's data is stored and processed in the region appropriate to their requirements. Multi-region architecture in a SaaS product means maintaining separate database instances in each required region, routing customer traffic to the correct regional deployment, and ensuring that data for one region does not cross into another region's infrastructure. This is substantially more complex than a single-region deployment and is typically not justified at MVP stage. The practical approach is to build your MVP in the region that satisfies your most immediate customer requirements (UK data residency for a UK-focused product), document your data residency commitments clearly, and design the data model with clean per-customer data boundaries so that migrating a customer to a regional deployment later is achievable without a full data migration exercise.
Data Residency in AI Products: LLM and Vector Database Considerations
AI products using LLMs and vector databases have data residency challenges that standard SaaS products do not. When your product generates embeddings from user documents and stores them in a vector database, that vector database must also satisfy data residency requirements. Pinecone offers EU-region deployments. Weaviate Cloud offers EU-region options. pgvector (PostgreSQL extension) inherits the data residency of your PostgreSQL deployment. When your product calls an LLM API to process user data, the inference must occur within the residency zone or be covered by appropriate transfer mechanisms. Azure OpenAI in EU regions satisfies EU data residency for inference. Using OpenAI's standard API (US-hosted) for EU data requires the EU SCCs and is permitted under the EU-US Data Privacy Framework for certified organisations, but is not the same as data physically staying in the EU. For enterprise customers who require strict data residency (data must not leave UK/EU even with appropriate contracts), using only UK/EU-hosted infrastructure for every component of the AI pipeline is required.