Data Sovereignty Is No Longer a Geography Problem — It's an Architecture Problem

For years, organizations treated data sovereignty as a geography problem: pick the right cloud region, stay in compliance. The EU’s Cloud and AI Development Act (CADA) reframes the problem entirely. The question is not where your data sits — it’s who can be legally compelled to access it.

How It Works

The U.S. CLOUD Act enables American authorities to demand data from U.S.-incorporated cloud providers regardless of where the data physically resides. A European public sector organization storing sensitive workloads in an AWS Frankfurt region is still operating infrastructure whose parent company is subject to U.S. legal jurisdiction. Physical location doesn’t change that. CADA introduced a four-tier sovereignty framework for public sector procurement that forces explicit evaluation of these jurisdictional control vectors — who owns the infrastructure, under which legal system, and what compelled access looks like under that system.

The consequence for platform engineers is that sovereignty compliance can no longer be documented after the fact. It has to be enforced through architecture. The open-source stack organizations are assembling for sovereign platforms has four components:

Kubernetes is the governance layer. Admission controllers enforce workload placement policies at the API level — a pod attempting to schedule outside an approved jurisdictional boundary fails before it reaches the scheduler. Node affinity rules restrict pods to approved infrastructure. Policy engines like OPA/Gatekeeper and Kyverno evaluate every API request for compliance. This is sovereignty enforced as code, not documented in a compliance spreadsheet.

OpenStack provides the sovereign infrastructure foundation. Where public cloud providers can be legally compelled to produce data, operator-controlled infrastructure — using Ironic for bare metal provisioning, Keystone for self-hosted identity, Neutron for network isolation, and Ceph for distributed storage — keeps control within the organization’s legal perimeter. This configuration is operationally heavier and more costly than public cloud, but it’s the only one where “we control access” is literally true rather than contractually asserted.

GitOps provides the auditability layer. Configuration-as-code tracked in version control and applied through tools like ArgoCD or Flux produces a verifiable record of what was deployed, when, and with what authorization — across multiple jurisdictional configurations managed in parallel. The traceability requirement in the EU AI Act makes this operational model, not an optional best practice.

Policy-as-code bridges regulation and runtime. OPA and Kyverno can encode jurisdiction-specific requirements — which data types can transit which networks, which workloads require on-premises compute, which API calls require additional authorization — and evaluate them continuously rather than in point-in-time audits.

What This Means for You

Federated learning provides the clearest architectural illustration of how sovereignty constraints reshape design decisions. Traditional machine learning training centralizes data — which immediately violates localization requirements in multi-jurisdiction environments. In a federated architecture, training runs where the data already resides; only aggregated model updates cross jurisdictional boundaries. The data never moves. This design is possible because the Kubernetes-level policy controls described above can enforce which workloads can communicate across which boundaries at runtime — not just at provisioning time.

For AWS-heavy organizations managing Kubernetes clusters across regions, the sovereignty layer adds complexity to upgrade paths and operational procedures. Each jurisdiction may require separate certificate rotation schedules, independent security patching, and jurisdiction-specific capacity planning. The NIS2 directive adds supply chain dependency requirements; DORA adds operational resilience requirements. None of these are resolvable with regional cloud configurations alone.

The operational burden is real. But the regulatory direction across the EU is toward more enforcement, not less, and CADA’s four-tier procurement framework is already being used to evaluate vendor sovereignty claims in public sector contracts. Organizations that rely on documentation for sovereignty claims and organizations that enforce those claims through admission controllers are in a materially different position when those audits happen.

Source: CNCF Blog

Content created with AI assistance and reviewed for accuracy.