> Bron: https://neuralex.nl/en/blog/data-residency-eu-regio > An EU cloud region does not automatically mean European control. What data storage location, access, the US CLOUD Act and cloud sovereignty really mean for your AI project. [Back to insights](/en/blog) GDPR ·September 13, 2026 ·7 min read # Data residency: what does an 'EU region' really mean with a US cloud provider? An EU cloud region does not automatically mean European control. What data storage location, access, the US CLOUD Act and cloud sovereignty really mean for your AI project. An "EU region" with a US cloud provider usually means that certain categories of customer data can be stored in data centres located within a selected European region or geographic boundary. That is useful for data residency, but it does not automatically mean that the entire service is under European legal, operational or technical control. Physical storage location is only one part of the picture. Processing, backups, logging, technical support, administrator access, encryption keys and legal access all matter as well. A US-based provider may still be subject to US law even when the servers holding your data are physically located in the Netherlands, Germany or Ireland. An "EU region" should therefore not be treated as the same thing as "EU sovereign". ## What does an EU region mean technically? Large cloud platforms divide their infrastructure into geographic regions. A region typically consists of multiple data centres or availability zones within a defined area. Customers may choose a European region for services such as databases, object storage, virtual machines or AI workloads. For services that explicitly support data residency, choosing an EU region generally means that primary customer data is stored within that region or within an agreed European geographic boundary. Providers may also replicate data within that boundary for availability, resilience and disaster recovery. The exact guarantee, however, depends on the individual service: major providers let customers choose a region for their content while specifying per service where data "at rest" is stored — and draw a distinction between a service's availability and its actual data residency. For that reason, saying that "our cloud runs in Europe" is not a sufficient technical specification. You need to know exactly which components of the service are covered by the residency commitment. ## Is data storage location the same as where data is processed? No. Data residency usually focuses primarily on where data is stored. It does not automatically determine where every operation involving that data takes place. An application may keep its main database in Frankfurt while some telemetry, account information, security logs or support data is processed through systems elsewhere. Some cloud services may also perform parts of their processing across multiple locations. This distinction is particularly important for AI services: you may need to establish separately where prompts, uploaded documents, embeddings, generated responses, temporary caches, logs and vector databases are processed and retained. Access is another separate issue. Data can physically remain in Europe while employees or technical systems located outside Europe may still be able to access it under certain circumstances. Cloud providers increasingly offer mechanisms to reduce that risk, such as stricter administrator controls, customer-controlled encryption keys and approval processes for support access — but those measures need to be assessed individually. A practical review should therefore separate at least three questions: where is the data stored, where is it processed, and who can access it? ## Why does the US CLOUD Act still matter? The US CLOUD Act remains relevant because, under certain conditions, US authorities can require service providers subject to US jurisdiction to produce data that is within their possession, custody or control. That means the physical location of the server is not necessarily decisive: a US provider may in some situations be legally required to produce data even when that data is stored in Europe. This does not mean that US authorities have unrestricted access to European cloud servers, nor does it mean that US cloud providers routinely hand over customer data. Government access is subject to legal processes and specific conditions. The important point is narrower: storing data in an EU data centre does not by itself eliminate the possibility of overlapping or conflicting jurisdictions. For organisations handling personal data, legal files, trade secrets, healthcare information or other sensitive material, that distinction may matter significantly. The relevant question is not only where the hardware is located, but also which entity controls the service and which legal regimes apply to that entity — much like the combination of data, purpose, scale and possible impact that a [DPIA](/en/blog/dpia-voor-ai) is built to weigh. ## Does using a European subsidiary solve the problem? Not automatically. A European legal entity can help structure contracts, staffing, operations and data management within the EU. It may also strengthen the organisation's position in areas such as local governance, operational control and contractual accountability. But having a European subsidiary or registered European office does not automatically make a cloud service sovereign. You still need to understand whether a non-European parent company can exercise control, who manages the encryption keys, where administrators are located and which entity ultimately controls the infrastructure. The question is therefore not only: "Which company signs the contract?" Ownership structure, technical architecture and operational authority matter as well. ## What do sovereign cloud initiatives solve, and what do they not solve? Sovereign cloud models aim to go further than ordinary data residency. They may introduce requirements around European storage and processing, local operational personnel, encryption key ownership, legal control, administrator access and the ability to move workloads between providers. The European Commission itself now uses a Cloud Sovereignty Framework that assesses not only data location, but also legal and jurisdictional aspects, operational control, technology, supply chain, security, and data and AI sovereignty — which illustrates why cloud sovereignty is broader than simply the location of a server. A sovereign cloud architecture may reduce certain jurisdictional and operational risks, but the word "sovereign" is not a technical guarantee in itself; the actual architecture and contractual commitments still need to be examined. A service may, for example, use technology developed by a US company but be operated by a separate European entity under stricter access and governance controls — offering substantially more local control than a standard public cloud environment. At the same time, dependencies may remain: the service may still rely on foreign software, intellectual property, updates or supply-chain components. Cloud sovereignty is therefore better evaluated as a set of properties rather than as a simple yes-or-no label. ## What should an SME ask its cloud provider? Ask for specific answers for each service and workload rather than relying on a general statement that the platform is "GDPR compliant". Useful questions include: - In which country or region is our primary data stored? - Where are backups and disaster-recovery copies stored? - Can our data leave the EU during processing? - Which metadata, logs or account information fall outside the residency commitment? - Can employees outside the EU access our environment? - How is technical support access restricted and audited? - Which subprocessors may process our data? - Which legal entity provides the service? - Can a foreign parent company technically access our data? - Who controls the encryption keys? - Can we use customer-managed keys that prevent the provider from independently decrypting the data? - What happens if the provider receives a government request for access? - Will we be informed when legally permitted? - Can we fully export our data and have it verifiably deleted? For AI services, additional questions are needed. Are prompts and uploaded documents retained? Are they used for model training? Where does inference take place? Do the same residency commitments apply to embeddings, vector databases, logs and any external model providers? These details often matter more than the geographic label shown in a cloud console. ## When is a standard EU region sufficient? For many ordinary business applications, a European cloud region may be entirely appropriate, particularly when data residency is contractually defined and access controls, encryption and subprocessors are properly managed. A stricter architecture may be justified for sensitive [RAG systems](/en/blog/rag-uitgelegd), legal documents, employee records, healthcare data, confidential business knowledge or public-sector workloads. Possible options include a European cloud provider, a sovereign cloud service, customer-controlled encryption keys or a fully on-premises deployment. That does not mean every sensitive workload must automatically be moved on-premises. The correct approach depends on the type of data, the purpose of the system, the provider and the technical and contractual safeguards in place — a deliberate risk assessment rather than assuming that selecting "EU West" in a cloud dashboard resolves every compliance and sovereignty question. ## What should you ultimately remember? An "EU region" mainly tells you that a cloud provider can keep certain data within a European geographic boundary. It does not automatically mean that all processing takes place in Europe, that nobody outside Europe can access the data, or that only European law applies. Data residency, processing location, administrative access, legal jurisdiction, encryption key ownership and actual technical control should therefore be assessed separately. For sensitive business data or personal data, an EU region is an important control, but it is not a complete legal or technical risk assessment. Neuralex does not provide legal advice. Where sensitive personal data, international data transfers or foreign jurisdiction are involved, have the chosen cloud architecture reviewed by qualified legal counsel. Do you know where your data really lives? ## We map the data residency of your AI stack From storage location to subprocessors and encryption keys — we help figure out the technical side. Have the legal assessment reviewed by qualified counsel afterwards. [Ask your question](/en/contact) [Read about AI and GDPR](/en/blog/ai-en-de-avg) --- Volledige (opgemaakte) versie: https://neuralex.nl/en/blog/data-residency-eu-regio