The CLOUD Act and your client data: why 'UK data centre' does not mean UK jurisdiction
The marketing materials for every major cloud AI vendor include some variation of the phrase “UK data centre.” AWS, Microsoft Azure, and Google Cloud all operate data centres in the United Kingdom. Harvey AI processes legal data through OpenAI’s infrastructure. CoCounsel runs on Thomson Reuters’ cloud, itself dependent on US-headquartered hyperscale providers.
What none of these materials make clear — and what most procurement conversations never surface — is that data residency and data sovereignty are not the same thing. A UK data centre tells you where the bits sit. It says nothing about who can legally compel their disclosure.
The legal mechanism that makes this distinction consequential is the US CLOUD Act 2018. Understanding it is not optional for any firm operating under UK GDPR.
What the CLOUD Act actually says
The Clarifying Lawful Overseas Use of Data Act was enacted by the US Congress in March 2018. Its origin lies in a legal ambiguity created by the 2013 Microsoft Ireland case, in which a US district court sought to compel Microsoft to produce email data stored on servers in Dublin. A US appeals court temporarily ruled that the US government could not compel production of data physically stored overseas — creating, briefly, a meaningful distinction between data held in the US and data held abroad.
The CLOUD Act closed that gap permanently.
The operative principle is simple and absolute: jurisdiction follows corporate ownership, not geographic server location. A US court can issue a warrant or subpoena to any US-incorporated technology company and compel the production of data held anywhere in the world — including data sitting in a server rack in London, Manchester, or Edinburgh.
The implications for UK firms using US-headquartered cloud AI services are direct:
- AWS is a subsidiary of Amazon.com Inc., incorporated in Delaware. Selecting the
eu-west-2(London) region does not remove AWS from US jurisdiction. - Microsoft Azure is operated by Microsoft Corporation, incorporated in Washington State. Microsoft Cloud for Sovereignty, the UK Government Cloud, and any other “sovereign” variant remain subject to CLOUD Act process served on the US parent.
- Google Cloud Platform is operated by Google LLC, incorporated in Delaware. The same analysis applies.
- Harvey AI is incorporated in the United States and processes data through OpenAI’s US-incorporated infrastructure. CLOUD Act exposure is structural.
- CoCounsel (Thomson Reuters) is operated by a Canadian parent with US-listed shares and US-incorporated operating entities. The position is complex but the US nexus exists.
For all of these providers, a US federal court can issue a demand for UK-held client data. The UK firm may never be notified. CLOUD Act demands routinely carry gag orders — the provider is legally prohibited from disclosing that a demand was made or complied with.
The Microsoft Ireland case and why it matters
The pre-CLOUD Act Microsoft Ireland litigation illustrates precisely why the distinction between residency and sovereignty is not theoretical.
In 2013, US authorities investigating a narcotics case sought email records from a Microsoft account. The data was stored in Microsoft’s Dublin data centre, not in the United States. Microsoft refused to comply, arguing that the US Stored Communications Act did not have extraterritorial reach. The Second Circuit Court of Appeals agreed in 2016 — a significant win for the principle of data sovereignty.
The US government promptly appealed to the Supreme Court. Before the Supreme Court could rule, Congress passed the CLOUD Act in March 2018, mooting the case. The CLOUD Act explicitly amended the Stored Communications Act to apply extraterritorially, confirming that US-incorporated providers must comply with valid US legal process regardless of where the data is stored.
The practical lesson: the courts moved towards data sovereignty, and Congress legislated to reverse that movement. The current legal architecture reflects a deliberate US policy choice that the nationality of the provider, not the location of the data, determines US jurisdiction.
Direct conflict with UK GDPR
The CLOUD Act creates an irresolvable conflict with three specific provisions of UK GDPR.
Article 5 — lawful, fair, and transparent processing. UK GDPR requires that personal data be processed in a manner that is lawful, fair, and transparent to the data subject. A secret foreign government order compelling disclosure is neither fair nor transparent. The data subject cannot be notified. The controller cannot inform them. The processing occurs invisibly.
Article 32 — appropriate technical and organisational security measures. UK GDPR requires that controllers and processors implement appropriate security measures having regard to the risk. A structural legal vulnerability to compelled foreign government access — one that cannot be mitigated by any technical measure — is not an appropriate security posture. Encryption does not resolve it: as discussed below, the “Customer-Managed Keys” argument fails on examination.
Article 48 — international transfers not authorised under Chapter V. UK GDPR provides specific mechanisms for lawful cross-border data transfers — adequacy decisions, Standard Contractual Clauses, Binding Corporate Rules. The CLOUD Act bypasses all of these. It does not require the provider to obtain a UK adequacy assessment. It does not route through the Mutual Legal Assistance Treaty process that Article 48 contemplates for cross-border government access. It simply compels. The transfer occurs in breach of Article 48 regardless of what SCCs or DPAs the firm has executed.
The provider faces an impossible choice: comply with the CLOUD Act demand and breach UK GDPR, or refuse and face US contempt of court. In practice, providers comply. UK data subjects and their legal advisers are not informed.
Why “sovereignty washing” does not work
Hyperscalers have responded to growing awareness of the CLOUD Act with a category of product broadly described as “sovereign cloud” — regional offerings with local data centres, local staff, compliance certifications, and specialised governance controls. AWS European Sovereign Cloud, Microsoft Cloud for Sovereignty, and Google Distributed Cloud are examples. They typically carry a 15–30% price premium over standard offerings.
None of them resolve the CLOUD Act problem. The providers themselves acknowledge this in their terms, when pressed.
The argument offered in mitigation — “Customer-Managed Keys” (CMK) — works as follows: if the customer holds the encryption keys in an external Key Management System (KMS) outside the provider’s control, then a CLOUD Act demand yields only encrypted ciphertext. The provider cannot produce intelligible data because it does not hold the keys.
Legal analysts have identified three reasons why this argument does not hold:
First, the legal exposure remains absolute. The CLOUD Act compels production of all data the provider controls or has access to. The litigation and governance risk of a gag-ordered US court demand is a material risk to the controller regardless of what the demand eventually produces. The existence of the demand, the fact of compliance, the potential breach of UK GDPR Article 48 — none of this is resolved by encryption.
Second, hyperscalers require access to unencrypted metadata. Even where payload data is encrypted under customer-managed keys, the provider necessarily accesses unencrypted metadata, telemetry, system logs, and billing information to maintain service availability. This data — communication patterns, user identities, resource utilisation, query volumes — is itself personal data and flows to US-based control planes. A CLOUD Act demand encompasses this data.
Third, no provider can make a legally binding promise of non-compliance. No US-incorporated company can contractually commit to refusing a valid US court order without risking criminal contempt of court. The DPA may say they will not voluntarily disclose; it cannot say they will defy a court.
CLOUD Act exposure by provider
The following table reflects the structural CLOUD Act position of providers commonly used by UK professional services firms for AI workloads. This is not a question of the provider’s security posture or contractual commitments — it is a function of their corporate nationality.
| Provider | US incorporation | CLOUD Act exposure |
|---|---|---|
| AWS (Amazon Web Services) | Amazon.com Inc., Delaware | ✗ Yes — applies to all regions including UK |
| Microsoft Azure | Microsoft Corporation, Washington State | ✗ Yes — applies to all regions including UK Sovereign |
| Google Cloud Platform | Google LLC, Delaware | ✗ Yes — applies to all regions |
| Harvey AI | US-incorporated, OpenAI dependency | ✗ Yes — structural |
| CoCounsel (Thomson Reuters) | Thomson Reuters Corporation, US-listed | ✗ Yes — US nexus exists |
| UK/EEA sovereign infrastructure | Non-US incorporated, no qualifying US operations | ✓ None — outside US jurisdiction |
This table is not a comprehensive legal opinion. Firms should obtain independent legal advice on their specific procurement decisions. The structural position described here is, however, consistent with the plain language of the CLOUD Act and the legal analysis applied in the Microsoft Ireland case.
What your DPIA must document
Under UK GDPR Article 35, a Data Protection Impact Assessment is mandatory before processing that is “likely to result in a high risk” to data subjects. Processing privileged client data using an AI service operated by a US-incorporated provider is precisely this kind of processing.
Your DPIA must address:
Data sovereignty risk. Where exactly is the data processed? Who is the corporate parent of the provider? Is that parent subject to US jurisdiction? Is there any legal mechanism — gag order, court demand, intelligence agency process — under which your data could be disclosed to a foreign government without your knowledge? The answer for every US-headquartered provider is yes.
Transfer mechanism adequacy. What mechanism authorises international transfer of the data? If the provider is UK-based but processes data outside the UK (including via sub-processors), what adequacy decision or SCCs cover that flow? The CLOUD Act represents a category of transfer risk that SCCs cannot address — they bind the provider contractually but do not override US law.
Notification obligations. In the event of a CLOUD Act demand, will your firm be notified? Can the provider legally notify you, given that CLOUD Act demands typically carry gag orders? The answer is almost certainly no. Your DPIA must account for a class of disclosures that you will never learn about.
Mitigation measures. What technical or contractual measures reduce the risk? As discussed above, Customer-Managed Keys do not eliminate it. The only architecture that genuinely eliminates CLOUD Act exposure is one in which the provider itself has no US corporate nexus — and therefore cannot be compelled by US legal process.
The ICO has stated that DPIAs must be specific, evidence-based, and proportionate to the identified risks. A DPIA that notes “data stored in UK data centre” without addressing the provider’s corporate nationality and the CLOUD Act is inadequate on its face.
The architectural answer
There is one class of infrastructure provider for which CLOUD Act jurisdiction does not apply: a non-US company with no qualifying US operations, no US-listed parent, and no US-incorporated operating entities.
A UK-registered, UK-owned, and UK-operated bare-metal infrastructure provider with no qualifying US operations falls outside CLOUD Act jurisdiction. There is no US corporate nexus through which a US court could compel production of data held on that provider’s infrastructure.
The same analysis applies to EEA-incorporated providers with no US corporate nexus.
Private AI deploys its sovereign AI infrastructure exclusively on UK and EEA infrastructure providers with no US corporate entity in the access path at any layer — not the inference layer, not the storage backend, not the network gateway, not the authentication layer. True sovereignty requires that the provider itself be beyond the reach of foreign legal process. Anything less is sovereignty in name only.
This matters for more than regulatory compliance. It matters for professional privilege. UK lawyers have a duty to protect client-confidential communications. Submitting those communications to a service operated by a US corporation — even one with a UK data centre — creates a structural risk to privilege that the CLOUD Act makes concrete and unavoidable.
What to do next
Step 1: Read our analysis of data residency versus data sovereignty — the foundational distinction that most procurement conversations fail to make.
Step 2: Read our companion article on shadow AI governance — the 96% of UK law firms using AI and the governance crisis that has followed.
Step 3: Review what the ICO expects from firms experiencing AI-related data breaches — the enforcement trajectory under the Data (Use and Access) Act 2025.
Step 4: Talk to our team to walk through the CLOUD Act analysis as it applies to your specific AI procurement and vendor relationships — and see what a genuinely sovereign architecture looks like in practice.
Private AI Ltd (SC881079) acts as a Standing Data Processor under Article 4(8) UK GDPR, operating a Zero Standing Privileges architecture. We deploy sovereign, zero-egress AI environments for regulated professional services. In the Default Operating State, we hold no active connection and no credentials to client systems.