ADS
Contact
ADS
← All insights

ADS INSIGHTS / Cloud & Infrastructure

Your data is in Europe. But is your IT really European?

Digital sovereignty is not about buying European at any cost. It is about knowing where you depend on others, how much control you still have, and whether you can move when circumstances change.

Bart AckermanIT Consultant · Ackerman Digital Services · 7 min read
In this article

A company can quite honestly say that its data is stored in Europe while relying almost entirely on technology it has very little influence over.

Microsoft 365 for email and collaboration. Azure or AWS for infrastructure. A US-based CRM. Security software from another vendor. AI services delivered through the same cloud ecosystem.

There is nothing inherently wrong with that. Many of these platforms are excellent, scalable and professionally operated. They have expertise and security capabilities that a mid-sized Belgian company would struggle to reproduce on its own.

Yet digital sovereignty has moved rapidly up the European agenda. The phrase can sound as if companies are expected to replace every US provider or start building everything themselves. For most organisations, that would be unrealistic and in some cases counterproductive.

A more useful question is much simpler:

How much control do we still have when something changes?

That change could be a price increase, new contractual terms, an outage, new regulation or simply a decision to move to another provider.

A European data centre is not the same thing as European control

The European Commission made that distinction unusually concrete in 2026. As part of its broader push for technology sovereignty, it proposed the Cloud and AI Development Act.

The proposal does not treat cloud and AI sovereignty as a binary issue. It introduces several assurance levels. At the first level, data is processed and stored within EU infrastructure. Higher levels also look at independence from third countries, transparency over the software supply chain and, ultimately, ownership and control from within the EU.

That distinction matters.

Data may physically sit in Frankfurt, Paris or Brussels while the underlying technology, product roadmap, software updates, contracts and strategic decisions are still controlled elsewhere.

That does not make the service bad. It simply shows that data residency and digital sovereignty are not the same thing.

For many companies, that distinction is more useful than the simple question: "Is our data in Europe?"

Vendor lock-in creeps in

Vendor lock-in rarely comes from one obviously bad decision.

Nobody sits in a meeting and decides to make switching providers as painful as possible five years from now. The opposite happens.

A team selects a strong managed database. Then an identity service that integrates neatly with it. Monitoring. A data platform. Serverless functions. Security tooling. A few AI services.

Each decision makes sense on its own.

A few years later, those sensible decisions have collectively become one major architectural commitment.

The environment may work extremely well, but changing it has become far harder than anyone expected at the start.

That is the practical side of cloud lock-in. Not necessarily a bad choice, but a choice that becomes increasingly expensive to reverse.

Europe now treats this as a market issue too

In June 2026, the European Commission reached the preliminary view that Amazon Web Services and Microsoft Azure may need to be designated as gatekeepers under the Digital Markets Act.

The Commission specifically referred to their entrenched market positions, large ecosystems, high switching costs and lock-in effects. The expanding role of AI also matters, because cloud and AI purchasing decisions are increasingly intertwined.

That makes the debate more useful than a simple "US cloud versus European cloud" argument.

The real question becomes:

Can a company still make a genuine choice, or does that choice mainly exist on paper?

For a CIO or IT manager, that is far more relevant than the nationality of a logo.

Switching is getting easier

The EU Data Act contains specific rules for cloud and other data processing services. Providers must reduce technical barriers to switching and support customers who want to move or use several services in parallel.

From 12 January 2027, switching charges will also disappear, including certain data egress fees required to move to another provider.

That helps. But it does not remove the biggest difficulty.

Moving data is not the same as moving an environment.

Exporting a database can be relatively straightforward. The applications, policies, scripts, identities and operational processes built around it do not move automatically.

An export is not an exit strategy

Imagine a company that relies heavily on Azure today and decides to move elsewhere tomorrow. The files and databases can probably be exported. Much of the real migration cost sits in everything built around them.

For example:

  • Identity and access: Entra ID integrations, roles, policies and service accounts.
  • Platform services: Azure Functions, monitoring, security tooling and AI services.
  • Operations: deployment pipelines, automation, runbooks, logging and recovery procedures.
  • Knowledge: the team's experience with that particular architecture and toolset.

A cloud exit strategy therefore has to start long before the day someone decides to leave.

A company does not need a complete migration project sitting on the shelf. It should, however, understand which parts are portable, which parts are deliberately platform-specific and which dependencies would become difficult or expensive to replace over time.

Multicloud is not free insurance

The obvious response is: "Then we will just use more than one cloud."

That can be sensible, especially when there is a real reason such as resilience, regulation or a specific workload requirement.

But multicloud does not automatically solve lock-in. It creates costs and complexity of its own: broader skills, multiple security models, more monitoring, more contracts, more integrations and often overlapping tooling.

And if a company deliberately limits itself to the most generic services so that everything remains portable, it may also give up some of the platform benefits that made cloud attractive in the first place.

Portability has a price too.

The goal is not for every workload to run on three clouds tomorrow. The goal is to understand where dependency is being accepted deliberately and why.

Not all lock-in is bad

Depending on a supplier is not automatically a mistake.

A platform may deliver ten years of speed, integration, security and productivity that far outweigh the cost of a future migration.

The problem is not necessarily the dependency itself. The problem is pretending it does not exist.

If a company knowingly commits to a platform because the benefits outweigh the risk, that is a defensible architecture decision. If nobody can explain how deep the dependency has become, that is different.

Sovereignty is also a continuity question

You do not need to turn the subject into geopolitics to make it relevant.

For a Belgian company, this is also ordinary business continuity. Which services stop if a critical provider is unavailable? Which data and configuration can we restore independently? And do we still have the knowledge and alternatives to respond when prices, terms or regulation change sharply?

Those are not abstract policy questions. They directly affect resilience, risk and negotiating power.

AI may deepen the dependency even further

AI makes the issue more tangible because the dependency rarely sits in the model alone.

A modern RAG application may rely on document storage, an embedding service, vector search, identity, monitoring, security and an agent framework from the same cloud provider. That is attractive for engineering teams because the pieces work together and a first application can be built quickly.

But every extra integrated component also increases the platform's grip.

Embeddings can be recalculated and data can be moved to another vector database. That does not automatically move the retrieval logic, access controls, evaluations, observability or integrations around it. The more of those pieces sit inside one ecosystem, the larger the migration project becomes.

The model selected today may be replaced next year. The surrounding architecture often remains for much longer.

An AI application that takes a few weeks to build can therefore become an architecture decision that lasts for years.

That may still be the right trade-off. It is simply better to see it while you are building than to discover it five years later.

Complete independence is not the goal

For almost every modern organisation, complete technological independence is unrealistic. It does not need to be the goal either.

The more useful question is:

Which dependencies are we consciously accepting, and which ones could restrict us later?

That conversation belongs to more than IT. Security, procurement, finance, legal and management all have a stake in it.

Three questions for the next IT meeting

  1. Which systems are so critical that switching provider would realistically take us more than a year?
  2. Where are we accepting platform dependency because the business value justifies it, and where has dependency simply grown without anyone making a conscious decision?
  3. What could we actually do if pricing, terms, availability or regulation around our main provider changed sharply?

Digital sovereignty does not mean owning everything yourself. Keeping data in Europe can be part of the answer, but real control goes further.

You have genuine choice only when you know where you depend on others, why you accept it and what you would do if you ever had to move.

Sources and further reading

Read also

ADS / Cloud & Infrastructure ↗

← All insights