In short
Digital sovereignty refers to the ability of companies, organisations and states to control their digital systems, data and processes in a self-determined way: being able to switch providers and technologies without jeopardising operations, retaining access to their own data at all times and working on a legal basis that does not depend on decisions by foreign jurisdictions.
The term comes from the political debate, but has long since become a business factor. When 71 per cent of German companies obtain their cloud services from the USA but only 8 per cent would choose to do so voluntarily, that does not describe a preference. It describes a dependency. Digital sovereignty is the counter-model to this, and it can be defined more precisely than the political exchange of blows would suggest.
What digital sovereignty means
In a corporate context, digital sovereignty is made up of three capabilities that must occur together:
- Ability to switch: a provider, a tool or an AI model can be replaced without processes having to be rebuilt. The effort for the switch is known, limited and tested.
- Data control: business data, configurations, workflows and knowledge bases are kept in formats and places that the company can access independently of the provider. An export is a quick task, not a project.
- Legal certainty: the set-up also survives a changed legal situation, such as an overturned data agreement between the EU and the USA, without operations becoming unlawful or coming to a standstill.
The character of this definition is decisive: sovereignty is a verifiable property of the architecture, not a question of conviction. A company can use US software and still be sovereign if it could replace it at any time. Conversely, a company can use exclusively European tools and be completely dependent if it can no longer get out of them. A provider's origin is an indication; replaceability is the proof.
Distinction: sovereignty is not autarky
The most common error of reasoning in the debate is equating sovereignty with autarky. Digital autarky would be the attempt to produce all technology yourself, or at least within your own economic area. For a globally interconnected industry, this is neither realistic nor desirable, and it is not the goal of serious sovereignty strategies either. The EU Commission itself stresses in its initiatives that the market should remain open to partners.
Sovereignty means having the choice. A sovereign company can use GPT, Claude or another large language model from a US provider productively, as long as these systems hang as replaceable modules in an architecture that belongs to the company. Protectionism demands renunciation. Sovereignty demands control over your own exit.
The term must also be distinguished from data residency. The fact that data is physically located in an EU data centre says nothing about who can legally access it. A Frankfurt data centre belonging to a US corporation remains subject to US law via the parent company. Data residency is a location attribute; sovereignty is a control attribute.
The four dimensions of digital sovereignty
In practice, digital sovereignty breaks down into four dimensions that can be assessed separately. For each, there are now European options that you choose for technical reasons and not on principle:
| Dimension | Key question | Typical risk | European options (examples) |
|---|---|---|---|
| Data | Can we export everything that belongs to us? | Knowledge bases and histories are stuck in cancelled vendor accounts | Own databases (PostgreSQL, pgvector) on EU infrastructure |
| Software | What happens in the event of termination, a price increase or a feature being dropped? | Proprietary SaaS ecosystems without an export path | Open-source and fair-code software such as n8n, Nextcloud, Keycloak |
| Infrastructure | Who owns the data centre, and which law is it subject to? | Access obligations under US law, price and contract changes | Hetzner, IONOS, STACKIT |
| AI | How long does a model switch take? | Prompts, workflows and memories are tied to one model provider | Mistral (Apache 2.0 flagship), model abstraction via your own orchestration |
The AI dimension is the youngest and the most underestimated. The model itself can be exchanged via an API in minutes. What gets stuck are the layers above it: the orchestration of workflows, the prompt libraries, the knowledge bases and agent memories. Anyone who runs these layers on platforms they control themselves can swap models like components. Anyone who has embedded them in closed ecosystems does not switch the model; they switch half their operating system.
The legal framework: the CLOUD Act on one side, EU legislation on the other
The most important opponent of digital sovereignty is the US CLOUD Act of 2018. It obliges providers under US jurisdiction to hand over stored data on the order of US authorities, regardless of where in the world the servers are located. This is precisely why an EU data centre of a US provider does not solve the sovereignty problem: access follows the parent company, not the location. In June 2025, the chief legal officer of Microsoft France confirmed under oath before the French Senate that he could not rule out such access to European data.
The European response to this is currently taking legislative form. Since 12 September 2025, the EU Data Act has applied, obliging cloud providers to make switching easier; the dreaded egress fees for extracting data when switching providers must be abolished completely from January 2027. This makes the ability to switch legally enforceable for the first time.
The tech sovereignty package and the Cloud and AI Development Act
On 3 June 2026, the EU Commission presented its tech sovereignty package, the centrepiece of which is the Cloud and AI Development Act (CADA). The draft regulation aims to at least triple European data centre capacity within five to seven years, speed up permits and create an EU-wide sovereignty framework for cloud services for the first time. It provides for four sovereignty levels that public contracting authorities are to apply depending on their risk assessment: level 1 requires data processing and storage in the EU, level 2 additionally requires proven independence from third countries and transparency about the software supply chain, level 3 requires ownership and control from within the EU, and level 4 requires complete control over the software supply chain without any third-country influence. For now, this is a Commission proposal that still has to pass through Parliament and Council. The direction, however, is clear: sovereignty is turning from a marketing word into an auditable category.
Gaia-X: aspiration and reality
An honest classification of the legal framework also includes the Gaia-X project, launched by Germany and France in 2019 as a counter-model to the hyperscalers. The original expectation that a European cloud would emerge here has not been fulfilled; of all things, the large US providers became members of the supporting organisation early on. What Gaia-X has delivered above all are standards, labels and trust rules on which data spaces such as Catena-X in the automotive industry are built. As an infrastructure alternative, the project has disappointed; as groundwork for today's sovereignty levels, it was useful. Anyone planning digital sovereignty should read Gaia-X as a framework and not as a product they could book.
Digital sovereignty in practice: the European stack for mid-sized companies
How wide the gap between awareness of the problem and action is can be seen in the Bitkom Cloud Report 2026: 85 per cent of German companies consider Germany too dependent on US providers for cloud technologies, and four out of ten would even accept functional compromises for more independence. At the same time, only 12 per cent would pay noticeably more for a protected German alternative. Sovereignty therefore has to pay off, otherwise it remains a topic for Sunday speeches.
That it can pay off is due to a European tool layer that has now become robust. At the infrastructure level, providers such as Hetzner, IONOS or STACKIT host servers and databases entirely under European law. For workflow orchestration, n8n from Berlin has established itself: licensed as fair code, operable via self-hosting on your own infrastructure, with every workflow available as exportable JSON under your own control. The fact that SAP invested in May 2026 at a valuation of 5.2 billion US dollars shows, incidentally, that this layer is no longer a niche phenomenon. As a working interface for the team, Langdock, also from Berlin, bundles the leading models from OpenAI to Mistral behind one login with EU hosting, ISO 27001 and SOC 2; model choice thus becomes an admin setting. And at the model level, Mistral from Paris delivers Mistral Large 3, a flagship under the Apache 2.0 licence that can be operated entirely in-house if necessary.
The pattern behind all these building blocks: they do not necessarily replace the US services, they make them replaceable. GPT remains usable, but as a guest in an architecture whose orchestration, data storage and contracts belong to the company. A data processing agreement governs the legal side of the remaining provider relationships; you govern the architectural side yourself.
How sovereignty can be measured
Because sovereignty is a property and not a creed, it can be tested. The central metric is failover capability: how long does it demonstrably take to swap a critical provider or AI model for an alternative? Mature organisations rehearse this quarterly with a test run against a configured secondary provider, including checking the results on real cases. Anyone who has never rehearsed the switch does not have an option but an assumption.
In addition, three further metrics serve as an early warning system: the estimated exit costs per system (the higher, the deeper the vendor lock-in), the proportion of business data available in open, exportable formats, and the number of processes tied to exactly one provider. These values turn a vague concern into a work list that can be prioritised. In the end, the sovereign company is the one for which switching providers is a boring process.
Frequently asked questions about digital sovereignty
Is digital sovereignty the same as data protection?
No. Data protection governs the lawful handling of personal data and is a compliance obligation. Digital sovereignty is a strategic property that also covers non-personal assets: workflows, prompts, models, infrastructure. A GDPR-compliant set-up can be completely unsovereign if it depends on a single provider.
Do companies have to do without US providers for digital sovereignty?
No. Sovereignty is measured by the ability to switch, not by the origin of the services used. US models and US tools can be used as replaceable modules in a self-controlled architecture. It only becomes critical when central processes, data or knowledge bases sit in a single ecosystem without an export path.
What distinguishes data residency from digital sovereignty?
Data residency describes the physical storage location of the data, such as a data centre in Frankfurt. Sovereignty describes who can legally and practically access and dispose of the data. An EU data centre of a US provider offers residency but, because of the CLOUD Act, does not protect against access via the parent company.
Where is the best place for a mid-sized company to start?
With an inventory: which processes depend on which provider, which account, which model? This is followed by the layer with the best ratio of effort to sovereignty gain, usually workflow orchestration on an open platform, then your own data and knowledge storage. Switching the model is the smallest step and comes last.
What does digital sovereignty cost?
Considerably less than its reputation suggests, if you proceed layer by layer. A self-operated automation server on European infrastructure runs for double-digit monthly amounts; the real effort lies in the one-off migration of workflows and knowledge bases. What is really expensive is the opposite: a forced, unplanned change of provider under time pressure.