On June 3, the European Commission published the Cloud and AI Development Act, or CADA. On the surface it’s a procurement regulation for EU public sector bodies: new mandatory requirements about which cloud providers they can use for sensitive workloads, graded on four assurance levels. Easy to file under “not my problem.”

It’s more interesting than that.

What the four levels actually define

CADA’s sovereignty framework isn’t really a compliance checklist. It’s a taxonomy of how much control you have over where your data lives and who can reach it.

Level 1 is essentially “you’re a legitimate cloud provider.” Standard certifications, some transparency, no specific geographic or ownership requirements. Most major hyperscalers qualify.

Level 2 requires providers to demonstrate independence from third-country interference and give customers meaningful visibility into their software supply chain.

Level 3 requires EU ownership and operational control of the provider itself, plus personnel citizenship requirements.

Level 4 is the most demanding: full supply chain transparency, documented hardware origin, no third-country interference possible at any layer.

For most commercial software (apps that store data in a managed AWS or Azure or GCP database) the honest answer is they don’t clearly pass Level 1 under this framework. The data sits in a US-headquartered cloud. The provider can receive legal process from a US court without notifying the customer. Customers have limited visibility into anything below the application layer. That’s not a scandal. It’s a choice. But it’s worth being clear that it’s a choice.

Why the EU cares, and why that number matters

The Commission’s proposal cited a figure worth sitting with: EU-based cloud providers held about 29% of the European cloud market in 2017. By 2022, that had dropped to roughly 15%.

This happened for entirely rational reasons. AWS, Azure, and GCP are better products in most dimensions: more features, more reliability, better developer tooling, easier to hire for. European companies made the sensible call, and the cumulative result is that European governments are running sensitive public infrastructure on cloud services subject to US law and US court orders.

CADA is the policy response: create procurement criteria that favor EU-controlled providers for the most sensitive workloads, and mandate minimum sovereignty levels across the board. Whether that succeeds at reversing market concentration is a real question. The IAPP called the proposal “grand ambition, fragile foundations,” and they’re not wrong that EU cloud providers don’t always match the hyperscalers on features or coverage. But the underlying observation, that “convenient cloud” and “jurisdictional control” are different things, is accurate regardless of whether the regulation achieves its goals.

What this means if you’re building a product

The founders who should pay attention to CADA aren’t necessarily selling to EU municipalities. The more relevant group is anyone building products where the location and control of data is part of the value proposition.

Healthcare apps. Financial tools. B2B software in regulated industries. Consumer apps where “your data stays on your device” is a real differentiator, not just a privacy page bullet point.

For those products, the architecture that satisfies something like Level 2 of CADA looks a lot like what privacy-conscious builders have been doing anyway:

That last option, local-first design, where sensitive data stays on the user’s device and only syncs what the user explicitly chooses, is the most complete answer to “where does the data go?” because the answer is “it doesn’t leave the device.” It’s harder to build than a conventional architecture. But it’s architecturally honest in a way that matters when customers or regulators ask. It’s the approach behind our local-first software work, and CADA makes a reasonable case for why it’s not just ideological: keeping data close to users is a durable answer to sovereignty questions that doesn’t depend on which jurisdiction a cloud provider is incorporated in.

Where this is the wrong call

To be direct: building for data sovereignty when you don’t need to is expensive for no reason.

If you’re making a consumer app with low-sensitivity data and your users actively want their stuff synced everywhere, the right answer is a managed cloud service. The complexity of maintaining infrastructure with strong geographic controls, or the development overhead of local-first sync, isn’t justified by a regulation that doesn’t apply to you.

The question is whether your customers will eventually ask where the data lives, whether you operate in a regulated sector where it matters legally, and whether you want to be retrofitting the architecture after you’ve already shipped. CADA being a 2026 regulation rather than a 2019 one is partly a story about how long it takes to respond once a dependency is locked in.

The supply chain piece that gets missed

Level 4 of CADA requires “full transparency and control over the software supply chain.” That phrase tends to get read as a cloud provider concern: hardware origin, datacenter infrastructure. But it applies equally to the software you commission.

If you’re buying custom software rather than building it in-house, you should own the code outright, have access to the build pipeline, and be able to hand everything to another developer if the relationship ends. That’s not a CADA requirement for most private companies. But it’s what CADA formalizes for public sector because governments have learned, slowly, that vendor lock-in isn’t just inconvenient, it’s a strategic liability that compounds over time.

The same logic applies to founders. Owning what you build isn’t a regulatory requirement. It’s just a better position to be in.

If you’re building something where any of this matters, regulated industry, EU customers, or data you’d have trouble explaining in a procurement questionnaire, get in touch. These are architecture problems, and they’re much cheaper to solve before you’ve shipped than after.