Data Residency Isn't Sovereignty: The CLOUD Act Gap in Legal AI

A managing partner at an AmLaw 100 firm recently told us their IT committee had approved a generative AI vendor specifically because "the data stays in the EU — Frankfurt, fully GDPR-compliant." That statement is true and almost entirely beside the point. If the vendor is a US company, Frankfurt is a filing cabinet, not a fortress. Under the CLOUD Act, a US court order reaches data "in the possession, custody, or control" of a US provider no matter which continent the servers sit on. The firm had solved a residency problem and left a sovereignty problem completely untouched.

This conflation — residency as a proxy for sovereignty — is probably the single most consequential misunderstanding in legal AI procurement right now. It's also, from an education standpoint, a gift: the concept is simple enough to explain in one chart, consequential enough to justify a hard look at architecture, and increasingly impossible to ignore since a February 2026 ruling (widely referred to in industry briefings as the Heppner ruling) forced firms to ask sharper questions about where generative output actually sits once it's been produced.

The Conflation That's Costing Firms Control

Ask ten law firm IT directors where their AI vendor's "EU data residency" claim comes from, and most will cite a data center location — AWS Frankfurt, Azure Dublin, GCP Belgium. Few will be able to answer the follow-up question: is the company that operates that infrastructure incorporated in the United States? That second question is the one that matters for CLOUD Act exposure, and it's rarely part of the procurement conversation.

The distinction breaks down into three separate questions firms routinely merge into one:

• Where is the data physically stored? (Data residency — a geography question.)
• Whose laws govern who can compel access to that data? (Data sovereignty — a jurisdiction question.)
• Who actually controls the infrastructure, keys, and access logs? (Data control — an architecture question.)

A US-headquartered SaaS vendor hosting an EU customer's documents in Dublin satisfies the first question completely. It does nothing for the second, and depending on the deployment model, very little for the third. The 2018 CLOUD Act was written precisely to close the jurisdictional loophole that residency-based thinking assumes still exists — the Microsoft Ireland case that preceded it was about a US warrant for data stored in Dublin, and Congress's answer was to make corporate nationality, not server geography, the controlling fact.

What the Heppner Ruling Actually Established (and Didn't)

It's worth being precise here, because overclaiming the scope of a single ruling is its own kind of malpractice-by-marketing. The Heppner ruling did not ban US cloud AI vendors from legal work, did not invalidate standard contractual clauses, and did not hold that EU hosting is meaningless as a matter of law.

What it did do — and why legal ops teams have been citing it since February 2026 — is scrutinize a specific gap: provider confidentiality guarantees applied to inputs, but the reasoning exposed how little those guarantees say about derivative outputs. When a document is retrieved, summarized, and used to generate new text by a model hosted on infrastructure the firm doesn't control, the resulting output is a new artifact. Contractual promises about "where your documents are stored" don't automatically extend to where that generated output is logged, cached, used for abuse-monitoring, or retained for debugging. The ruling's reasoning pushed courts and compliance teams to ask: who has custody of the output, not just the input?

That's a narrower, more technical point than "US AI vendors are unsafe for EU legal work" — and firms that oversell the ruling's scope to clients or regulators will eventually get caught overclaiming. The honest reading is that Heppner raised the evidentiary bar for what counts as a genuine confidentiality guarantee, and vendors whose answer is "we have a data processing agreement" are increasingly being asked to show the architecture behind the agreement.

CLOUD Act Mechanics: Why Frankfurt Doesn't Stop a Subpoena

The mechanics are worth spelling out because they're more absolute than most GCs expect.

The CLOUD Act amended the Stored Communications Act to clarify that US providers must comply with valid US legal process to produce data "within the provider's possession, custody, or control" — explicitly regardless of whether the data is located within or outside the United States. There is a mechanism for providers to contest an order on the grounds of conflict with foreign law, and the Act supports bilateral executive agreements (the US-UK agreement entered into force in 2020) that create alternative channels. But none of that changes the baseline: a US company's EU-hosted infrastructure is not legally insulated by geography alone.

Compare that to the EU's own regulatory reaction. Post-Schrems II (2020), the European Data Protection Board has repeatedly flagged that encryption and data localization alone don't satisfy adequacy requirements if the processing entity remains subject to foreign surveillance law. Several EU data protection authorities have specifically called out the structural tension between US-headquartered cloud vendors and GDPR Article 44 transfer rules — a tension that residency claims paper over rather than resolve.

For a law firm handling privileged client documents, M&A due diligence, or regulatory investigation materials, this isn't an abstract compliance nuance. It's the difference between being able to represent to a client, with a straight face, that their documents cannot be compelled out of the firm's control — versus representing that the documents are stored in a particular country but remain reachable through a different legal channel entirely.

Residency vs. Sovereignty: A Structural Comparison

The table makes the hierarchy explicit: residency is a subset of sovereignty, and sovereignty is a subset of control. Firms that stop at the first column have addressed the easiest, least consequential question.

The Architecture That Actually Matters: Corpus vs. Chunks

Here's where the conversation needs to get more technical than "US vendor bad, EU vendor good" — because that framing is both wrong and strategically useless. RAGbase Legal uses large language model providers too. The honest differentiator isn't whether an LLM is involved; it's what travels to that LLM, and what never leaves the firm's walls.

In a conventional cloud legal AI deployment, the full document corpus is typically ingested into the vendor's environment: uploaded, indexed, embedded, and stored on infrastructure the vendor operates. The firm's workflows, connectors, permission structures, and retrieval logic all live inside the vendor's platform. A CLOUD Act request — or a vendor breach, or a change in the vendor's data retention policy — potentially exposes all of it, because all of it is within the vendor's possession, custody, or control.

In RAGbase's private AI deployment model, the architecture is inverted:

• Stays on firm infrastructure: the full document corpus, the retrieval and indexing layer, vector stores, permission mappings, audit logs, and the agentic workflow scaffolding that orchestrates multi-step legal tasks.
• Leaves the firm's infrastructure (optionally, and minimally): only the specific retrieved chunks — a few paragraphs of a contract, a holding from a case, a clause under review — sent to the LLM the firm has selected, under the firm's own API terms, for the narrow purpose of generating an answer.

That's a difference of kind, not degree. A vendor that holds your entire corpus is a custodian subject to the CLOUD Act regardless of hosting location. A firm that holds its own corpus and sends a model only the minimal context needed to answer a specific query has removed the corpus from any third party's "possession, custody, or control" altogether — the legal predicate the CLOUD Act depends on. The LLM provider never had the documents to begin with; it had a redacted sliver, transiently, under contract terms the firm negotiated itself (including zero-retention API agreements where available).

This is also why the sharper pitch isn't "we never touch the cloud." It's: full corpus and agent layer under client control, versus minimized chunks sent to a model of the firm's choosing. Firms running case search across privileged litigation files, or running agentic workflows across M&A data rooms, get the benefit of frontier models without making their entire document set a standing target for compelled disclosure.

What This Means for Different Workloads

Not every matter carries the same sovereignty stakes, and treating all legal AI use cases identically wastes procurement effort. A rough triage:

Firms increasingly run a two-tier stack: per-seat SaaS tools like Harvey, CoCounsel, Lexis+ Protege, or Legora for lower-sensitivity drafting and research acceleration, alongside a private, firm-controlled deployment for the subset of matters where sovereignty is a client requirement rather than a preference. That's not an anti-SaaS argument — it's portfolio management. The mistake is applying the low-sensitivity tool to the high-sensitivity matter because nobody distinguished between residency and sovereignty at the intake stage.

Due Diligence Questions Managing Partners Should Actually Ask

Most vendor security questionnaires ask about encryption-at-rest and SOC 2 certification — necessary, but insufficient for the sovereignty question. The questions that actually surface CLOUD Act exposure:

1. Is the vendor entity, or its parent company, incorporated in the United States? (Residency answers don't answer this.)
2. Does the full document corpus reside on vendor-controlled infrastructure, or client-controlled infrastructure?
3. What specifically transits to the LLM provider — full documents, or retrieved chunks?
4. What are the data retention terms with the underlying LLM provider, and who negotiated them — the vendor, or the firm?
5. In the event of a US legal process request, does the firm have visibility into or control over the vendor's response?

Firms that can't get clear answers to questions 2 through 5 don't actually know their sovereignty posture — they know their residency posture, which is a different and much smaller thing. Our AI for law firms guide walks through the fuller procurement checklist, including how to map matter sensitivity to deployment model before signing anything.

Where This Goes From Here

The regulatory trend line points one direction: more scrutiny of derivative outputs, not less. If the Heppner reasoning becomes a template rather than an outlier, expect bar associations and outside counsel guidelines to start asking firms to document architecture, not just location, in response to client sovereignty requirements. The firms that have already mapped their matter portfolio to a two-tier deployment model — SaaS for velocity, private infrastructure for sensitivity — won't be scrambling when a client's GC asks the harder version of the data residency question for the first time.

If your firm is still answering sovereignty questions with a data center address, it's worth running the five questions above against your current stack before a client — or a court — asks them for you. The gap between "our vendor has an EU data center" and "our data never left our control" is exactly the gap worth closing.