Kim Loohuis, Tech & Business Content Writer and journalist bridging complexity and clarity, recently posted something that made me stop scrolling. She wrote:

My first feature for The Register is out today, looking at how Europe is tackling its 90% dependency on US cloud infrastructure.

While Brussels debates policy and American hyperscalers market 'sovereign' solutions, a handful of public bodies are taking concrete action.

That short update captures one of the most important digital questions facing Europe today: can a region build real digital autonomy when 90% of its cloud infrastructure depends on three US-based hyperscalers?

In this blog post, I want to pick up where Kim's LinkedIn post and her feature for The Register leave off, and unpack why this shift matters, what is actually changing on the ground, and why the legal conflict between the US CLOUD Act and GDPR is quietly reshaping public-sector IT.

Europe's 90% dependency on US cloud infrastructure

When Kim highlights Europe's 90% dependency on US cloud infrastructure, she is pointing at a concentration of power that goes far beyond technology.

For most public bodies and enterprises in Europe, the default cloud menu looks familiar: Amazon Web Services, Microsoft Azure, and Google Cloud. They offer scale, innovation, and global reach. But they also embody a particular legal and governance regime: US jurisdiction, US law enforcement powers, and business models optimised for data aggregation.

From a European policy perspective, this raises three major issues:

Strategic dependency: When most critical workloads run on foreign-controlled platforms, Europe assumes risk in times of geopolitical tension or trade conflict.
Regulatory friction: EU data protection rules, especially GDPR, are not always compatible with how these platforms operate or with the legal obligations they face in their home jurisdiction.
Market distortion: The scale and resources of hyperscalers make it hard for regional providers to compete, even when those local providers may be better aligned with European values and laws.

Kim's post zeroes in on a key point: policy debates in Brussels are important, but real change happens when individual institutions make different technology choices.

Where law and cloud collide: CLOUD Act vs GDPR

One of the most striking elements in Kim's post is her explanation that Austria's Federal Ministry for Economy, Energy and Tourism migrated 1,200 employees to Nextcloud, not primarily for cost reasons but because of the legal conflict between the US CLOUD Act and GDPR.

To understand why that is such a big deal, we need to look at both laws.

What the US CLOUD Act does

The US CLOUD Act allows American law enforcement agencies to compel US-based service providers to hand over data, regardless of where the data is physically stored. In practice, that means:

A European public body using a US hyperscaler may have its data requested by US authorities.
Those requests might be secret and may not require notification to the data controller in Europe.

What GDPR demands

GDPR, on the other hand, is built around principles of data minimisation, purpose limitation, and strict conditions for international data transfers. Controllers must ensure that personal data is adequately protected and that any transfer outside the EU meets those standards.

This creates a structural tension:

If a US cloud provider can be compelled to hand over EU residents' data under the CLOUD Act, without GDPR-level safeguards, then simply hosting data in an EU data centre is no longer enough.
Formal tools like Standard Contractual Clauses or complex transfer impact assessments are not always sufficient to make that risk acceptable, especially for sensitive public-sector workloads.

As Kim notes, this is not a theoretical problem. When Data Protection Impact Assessments (DPIAs) are performed thoroughly, US hyperscalers often emerge as high-risk options.

DPIAs as a turning point for public-sector IT

Kim's piece for The Register looks at what happens when DPIAs are not just box-ticking exercises but serious assessments of risk.

A DPIA asks: what could go wrong for the people whose data we process, and how likely is that risk? When a public body writes down, in clear language, that a provider may be forced by a foreign government to disclose citizens' data, that risk becomes politically and legally hard to ignore.

The Austrian ministry's decision to adopt Nextcloud for 1,200 employees is a powerful example of what happens when legal analysis drives technical architecture:

They chose a European open-source collaboration platform.
They gained the option to self-host or use a trusted regional provider.
They reduced exposure to extraterritorial data access while staying aligned with GDPR.

In other words, compliance became a driver for sovereignty-focused design rather than an afterthought.

Nextcloud and the rise of European alternatives

By highlighting the Austrian ministry's migration, Kim draws attention to a broader trend: European institutions are starting to look beyond the big three hyperscalers when sovereignty really matters.

Solutions like Nextcloud embody a different model:

Open source at the core: Source code is auditable, forkable, and not controlled by a single foreign corporation.
Deployment flexibility: Organisations can run it in-house, with a local partner, or in a regional cloud that meets their legal and security needs.
Ecosystem-building: Each new deployment strengthens a network of European integrators, hosters, and security experts.

This is not about romanticising local vendors. It is about acknowledging that for certain classes of data and functions, the combination of legal jurisdiction, operational control, and transparency matters as much as raw technical capability.

Sovereignty washing vs real digital autonomy

Kim also warns about sovereignty washing: the practice of marketing cloud products as sovereign or European without meaningfully addressing control, jurisdiction, or dependency.

Typical patterns of sovereignty washing include:

Hyperscalers branding EU-based data centres as sovereign, while contractual and legal control still flows back to the US parent company.
Joint ventures or partnerships that look local on the surface, but do not change who ultimately decides how the platform evolves.
Rebranding and new labels that focus on where data is stored, not who can access it or under which law.

This kind of messaging can actually slow down Europe's progress. If public bodies feel reassured by marketing language rather than by legal analysis and architectural change, they may delay investments in genuinely sovereign alternatives.

Structural vulnerabilities: lessons from the Solvinity case

In her Register piece, Kim examines cases like the acquisition of Solvinity to show how fragile European autonomy can be.

When a trusted regional provider that hosts critical public-sector workloads is acquired by a larger group, control can subtly shift:

Strategic decisions move away from local governance to distant shareholders or boards.
Long-term commitments to sovereignty, privacy, or public-interest mandates may be diluted.
Over time, the provider's roadmap can drift toward the priorities of bigger vendors or global financial structures.

Even if data never leaves Europe, the ecosystem around that data can become less European in its values, incentives, and accountability.

Kim's point is not that every acquisition is bad. Rather, she highlights how Europe's structural vulnerabilities are often economic and organisational as much as they are technical or legal.

What public bodies can do differently

Building on Kim's insights, there are several practical steps public institutions can take when they want to move from slogans to real sovereignty:

1. Treat DPIAs as strategic tools, not obstacles

Instead of trying to make an existing cloud choice fit the DPIA, use the DPIA findings to shape the choice of platforms and architectures.

Explicitly document risks related to extraterritorial access.
Involve legal, security, and policy stakeholders early.
Be prepared to say that some services are simply too risky for certain workloads.

2. Design for exit and portability

Vendor lock-in is one of the quiet enemies of digital sovereignty.

Favour open standards and open APIs.
Avoid proprietary formats and tools for core data.
Ensure contractual rights to migrate data and configurations to another provider.

3. Build local and regional capacity

Sovereignty is not only about rejecting foreign platforms; it is about cultivating alternatives.

Work with European open-source projects and regional cloud providers.
Support ecosystems of SMEs that can integrate, secure, and maintain these solutions.
Share best practices and reference architectures across public bodies.

4. Separate innovation from critical control

Hyperscalers can still have a role, especially for experimentation, non-sensitive workloads, or edge use cases.

Keep the most sensitive data and identity infrastructure under maximal European control.
Use hybrid and multi-cloud patterns that prevent any single provider from becoming a single point of failure.

From viral post to long-term transformation

Kim Loohuis's viral LinkedIn post resonated because it plugged into a deeper shift. Europe is moving from abstract discussions about digital sovereignty to concrete, sometimes messy decisions about contracts, platforms, and risk.

A ministry migrating 1,200 employees to Nextcloud may not sound dramatic compared to grand policy announcements. But it is exactly these grounded changes that, at scale, will determine whether Europe can genuinely reduce its 90% cloud dependency and align digital infrastructure with its legal and democratic values.

If there is a takeaway from Kim's work on this topic, it is this: sovereignty is not a sticker you put on a data centre. It is a continuous practice of aligning technology choices with law, accountability, and long-term public interest.

This blog post expands on a viral LinkedIn post by Kim Loohuis, Tech & Business Content Writer | Journalist bridging complexity and clarity. View the original LinkedIn post →