EU data residency tells you where your data sits, not who can reach it.

Data residency: where the bytes physically sit

Residency is a geography question. Pick an EU region and your data lives on disks in, say, Germany or Ireland. It is easy to buy, easy to prove on paper, and it satisfies specific location commitments.

What residency does not tell you is which legal system can reach the company that operates those disks. That is a different question, and it is the one that matters most for confidential and regulated data.

Data sovereignty: whose law and whose control

Sovereignty is a control question with two layers. Legal sovereignty is about which government's law has jurisdiction over the provider. Operational sovereignty is about who holds the keys and can technically read the data.

The EU now draws the same line in its own doctrine. The Commission's Cloud Sovereignty Framework, whose implementation guidance and assessment calculator were published on 1 June 2026, separates a legal and jurisdictional objective (SOV-2) from a data objective (SOV-3), and rolls the objectives into a Sovereignty Effectiveness Assurance Level (SEAL) from SEAL-0 up to SEAL-4. Under SOV-2 it names foreign-jurisdiction law, the US CLOUD Act among it, as a legal risk factor.

Why residency alone is not enough

The US CLOUD Act (2018) lets US authorities, through legal process, compel a US-based provider to disclose data in its control regardless of where it is stored, including EU data centres; how far it reaches the EU subsidiaries of US companies is still an open question. So a US-headquartered provider's EU region gives you residency while leaving the provider under US jurisdiction. Residency in Frankfurt does not remove that reach.

This is not a hypothetical. At a June 2025 French Senate hearing, a Microsoft France legal-affairs executive testified under oath that he could not guarantee that French citizens' data entrusted to Microsoft would never be handed to US authorities without the explicit agreement of the French authorities, adding that this had not happened so far. And complying with such an order can put a controller in a conflict-of-laws position, with no clean GDPR basis for the disclosure. The general principle is simple: any foreign-jurisdiction processor that can technically read cleartext is a sovereignty gap, wherever the servers are.

What sovereignty actually requires

Closing the gap takes architecture, not a stronger clause. In practice it means four things:

• Self-host, or customer-controlled infrastructure, so the firm controls where processing happens and holds the keys.
• Minimise cleartext exposure before any external dispatch, while assessing the residual context and the provider that still receives it.
• Obtain verifiable evidence through controlled source review, reproducible releases, configuration records and, where agreed, escrow or source access.
• An operational exit, so you are not locked to one provider. This aligns with DORA's ICT third-party and exit-plan requirements.

How GAIA Brain maps to these requirements

GAIA Brain is a proposed customer-hosted model gateway for regulated firms. Its built protected-egress mechanism can substitute supported values before external dispatch, but for now remains default-off; residual context may still reach the provider. Hash-chained events and DPIA/RoPA endpoints can support the customer's own GDPR, DORA, AIFMD and AI-governance work. GAIA-CORE will be released under AGPLv3; until that release, source access and continuity terms are agreed commercially.

The exact boundary: GAIA Brain is just short of MVP, with no official customer deployment. On 10 October 2026 it had 130,595 tracked TypeScript lines and a 1,430/1,430 cumulative regression result. The Cloud Sovereignty Framework is neutral EU doctrine, not a GAIA certification or SEAL score. The next step is a customer-hosted, witnessed design-partner pilot.