Digital sovereignty in practice

In February 2025, the US imposed sanctions on Karim Khan, the Chief Prosecutor of the International Criminal Court in The Hague. Shortly afterwards, his Microsoft email address stopped working. According to staff at the Court, he switched to the Swiss provider Proton Mail.[1] Microsoft denies having discontinued its services to the Court. In February 2026, however, the company had a statement made by one of its own managers before the British Parliament corrected. According to this, the Court had decided on its own to shut down the service.[2] Who actually pulled the plug remains unclear. It is undisputed, however, that the Chief Prosecutor’s email account ran on an infrastructure over which the Court did not have sole control.

Very few organisations find themselves caught between Washington and The Hague. Nevertheless, the question underlying this case concerns us all: what happens if a service on which one’s own operations rely were to fail tomorrow or only continue to operate under new conditions? Khan was able to switch because an email account could be moved quickly. In the case of a data platform, an ERP system or well-established AI workflows, the same step takes months, in my experience.

Anyone running software in a third-party provider’s cloud is effectively a tenant – usually a very comfortable one. In a rented flat, the landlord needs a valid reason to gain access. In the cloud, the provider holds the key to operations, because without it, they could not maintain, back up or update anything. Who can force the provider to unlock the door depends on the law to which they are subject. Tenants can move out as soon as the contract and export procedures allow. Whether the move is successful is decided long before the move-out: it depends on whether you know what’s in the flat and whether you’ve already viewed a second one.

How dependent are organisations in the German-speaking region?

In the European market for cloud infrastructure services, Amazon, Microsoft and Google together account for 70 per cent. European providers have consistently held a share of around 15 per cent since 2022.[3]

In Germany, according to the Bitkom Cloud Report 2026, 71 per cent of companies with 20 or more employees use cloud services from the US, whilst only 8 per cent would prefer to do so. 64 per cent of companies using the cloud feel compelled by US government policy to rethink their cloud strategy. A year earlier, the figure was 50 per cent.[4]

In Austria, according to the A1 Business Study 2026, 77 per cent of companies consider themselves heavily or somewhat dependent on digital technologies, whilst 12 per cent have implemented corresponding measures. [5] This dependence extends into areas that hardly anyone perceives as an IT issue: according to the Austrian National Bank, 80 per cent of domestic card payments are processed via Mastercard and 18 per cent via Visa – meaning that, combined, 98 per cent are handled by two US corporations.[6]

I have not been able to find comparable figures for Switzerland. In December 2025, the Federal Council designated digital sovereignty as one of the three key themes of the Digital Switzerland 2026 strategy: “The Federal Administration should take targeted steps to increase its digital sovereignty and resilience in the event of a crisis.”[7]

The three levels of digital sovereignty

Jon “maddog” Hall, President of Linux International, assesses every cloud service using three questions: “Under whose laws? Under whose ownership? What is their supply chain?”[8] For an organisation’s day-to-day operations, I add the question that is most often missing: Can we switch? This gives rise to three levels:

Level 1: Location and compliance. Where is the data processed, is this documented, and is it GDPR-compliant? This level can be verified contractually and is covered in almost every tender.

Level 2: Jurisdiction and control. Who manages the systems, and which jurisdiction does this provider fall under? The US CLOUD Act of 2018 obliges US providers to hand over data they own or control upon request, regardless of where it is stored. [9] This applies equally to a data centre in Frankfurt, Vienna or Zurich. In June 2025, the French Senate asked Anton Carniaux, Director of Public and Legal Affairs at Microsoft France, whether he could guarantee that data relating to French citizens would not be handed over to US authorities without France’s consent. His reply (translated): “No, I cannot guarantee that.” He added that this had never happened before.[10] I have described these first two levels in detail elsewhere.[11]

Level 3: Transferability. Can the organisation replace a service in an emergency? Can data be exported in full, is there a vetted alternative, and is the expertise available to migrate?

In my experience, the third level is the least frequently assessed, even though it is the one over which an organisation has the greatest control. It chooses the location and jurisdiction in consultation with the provider. It can improve its own preparedness at any time.

Open source safeguards the right to switch

Open source code is found in almost all modern software. The European Commission estimates that it accounts for between 70 and 90 per cent of all code in the digital economy.[12] A study by Harvard Business School concludes that without open source, companies would have to spend 3.5 times as much on software.[13]

One characteristic is particularly important for autonomy: open licences allow organisations to run the software themselves, adapt it and continue using it with a different service provider. They give an organisation the right to move its entire setup elsewhere. The Terraform case in 2023 demonstrated what this looks like in a real-world scenario. When HashiCorp restricted the licence for its widely used infrastructure tool, the community continued to develop the code under the name OpenTofu at the Linux Foundation.[14] Anyone using the tool was able to continue under the open terms.

According to the Bitkom Open Source Monitor 2025, 73 per cent of companies in Germany are already using open-source software, and just as many see it as a means of strengthening digital sovereignty.[15] Public sector organisations in all three countries are leading the way:

• Germany: Schleswig-Holstein has migrated its email infrastructure from Microsoft Exchange to open-source solutions and, outside the tax administration, largely uses LibreOffice. According to the state government, this saves the state more than 15 million euros in licence costs, with a one-off investment of 9 million euros in 2026. [16] The open-source office suite openDesk reached around 70,000 users in August 2025.[17]
• Austria: The Austrian Armed Forces have migrated around 16,000 computers to LibreOffice. Licence costs were never a factor in this decision; digital sovereignty was the top priority.[18]
• Switzerland: Since 1 January 2024, the central federal administration has been disclosing the source code of software it has developed itself, in accordance with Article 9 of the EMBAG, provided that this does not conflict with third-party rights or security considerations. [19]

At EU level, in June 2026 the Commission adopted a new open-source strategy designed to promote open standards in public procurement in order to avoid vendor lock-in.[20]

Why is the right to transfer alone not enough?

Open licences allow for migration. An organisation must build up the capability to do so itself, and in doing so I repeatedly encounter three obstacles.

1. Staff: In the Bitkom Open Source Monitor, a lack of specialist staff is the most frequently cited obstacle. In Austria, only 14 per cent of companies with 10 to 49 employees have any ICT specialists on their staff at all; for those with 50 to 249 employees, the figure is 44 per cent. Two out of three companies that have recruited ICT specialists encountered difficulties in filling these roles. [21] Anyone who does not have someone capable of operating an open system is reliant on the service provider who operates it on their behalf. This dependency then shifts from the software manufacturer to the partner.

2. Hosting: Open source code does not alter the legal framework of the entity operating it. The French AI provider Mistral publishes several current models with open weights under the Apache 2.0 licence.[22] In July 2026, Microsoft and Mistral expanded their partnership; Mistral Medium 3.5 has since also been available in Microsoft Copilot Studio.[23] Critics point out that Mistral models on Azure are subject to the US CLOUD Act. [24] A model with open weights can run in one’s own data centre or in a US cloud. In both cases, the method of operation determines sovereignty. European clouds only partially solve the problem: in the first tender under the European Commission’s Cloud Sovereignty Framework, no provider achieved the highest level, SEAL-4.[25]

3. Maintenance: According to the Harvard study, 96 per cent of the value of open source is generated by just 5 per cent of developers.[13] Widely used software therefore rests on the shoulders of a few. In March 2024, a backdoor was discovered in the xz-utils compression library, rated with the highest severity level of 10.0. [26] Anyone using open source therefore assumes responsibility for maintaining the components. For software manufacturers, this is now a legal obligation. Under the Cyber Resilience Act, a manufacturer is defined as anyone who develops, or commissions the development of, products containing digital elements and markets them under their own name within the EU, including any embedded open-source components. From 11 September 2026, manufacturers must report actively exploited vulnerabilities within 24 hours as an early warning; the remaining obligations come into force on 11 December 2027.[27] Swiss manufacturers supplying the EU should have their compliance assessed by legal experts.

Lock-in with an AI expiry date

According to the Federal Statistical Office, 26 per cent of companies in Germany with ten or more employees were using artificial intelligence in 2025; for companies with 250 or more employees, the figure was 57 per cent.[28] In Austria, the proportion stood at 30 per cent, compared with 11 per cent two years earlier.[29]

In the organisations I work with, the roll-out was usually pragmatic: one provider, one model, up and running quickly. Over time, however, more than just the data ends up with the provider. Prompts are tailored to the behaviour of a specific model, and workflows are built around its interfaces.

Added to this are short lifecycles, the end dates of which are set by the provider. OpenAI has published these dates itself: the company will disable the August 2025 version of GPT-5 in its programming interface on 11 December 2026.[30] Anthropic promises at least 60 days’ notice before a public model is taken offline.[31] A successor is usually ready. Nevertheless, the provider determines the timing of the switch, and a new model often responds differently to the same prompts. Users can remain flexible if they maintain their prompts in a separate directory and have tested a second model using the same test tasks.

A model with open weights, on the other hand, can be run for as long as the organisation needs, provided the licence delivers what its name promises. The Open Source Initiative requires that, for open-source AI, sufficient information about the training data be provided in addition to the code and weights, and many models marketed as open-source do not meet this requirement.[32] Meta describes Llama as open-source. Nevertheless, companies headquartered in the EU do not receive usage rights for the multimodal models of Llama 4.[33] Models licensed under Apache 2.0, such as several from Mistral, do not have such restrictions. [22]

Added to this is regulation. The transparency obligations under Article 50 of the EU AI Act will take effect from August 2026, in some cases with transition periods until December 2026. The obligations for high-risk systems under Annex III will apply from 2 December 2027. [34] Anyone operating such a system must use it in accordance with the provider’s operating instructions, have it supervised by humans and retain the automatically generated logs, insofar as they are under their control. [35] This presupposes that the organisation knows which model and which version is in use. A model change specified by the provider may therefore become a compliance issue. The AI Act also covers providers based in Switzerland as soon as they place AI systems on the market in the EU or their results are used there.[36]

Who benefits from what, and why?

My view: No organisation should integrate a provider, a language model or a tool so deeply that it can no longer be replaced. Dependency means you cannot switch. That is why I believe a provider-independent, agnostic architecture is the best approach, in which every component remains interchangeable, even the most powerful cloud models.

This doesn’t come for free. Someone has to build and operate a dedicated intermediate layer between the application and the model; someone has to test a second model; and some of a provider’s convenience features are lost. Not every process justifies this effort. That is why I ask one question before every decision: Who benefits from what, and why?

A feature that primarily increases switching costs benefits the provider. Anyone who has built their workflows in OpenAI’s Agent Builder and in saved prompt templates must migrate by 30 November 2026 – a deadline they did not choose.[30] Having your own intermediary layer benefits the organisation because it allows them to swap out the underlying model at any time.

The ‘why’ leads to the second question: does this process require maximum performance or maximum control? For sensitive data and critical processes, I rely on open source and in-house systems. I do not want the on/off switch for these to be located in a foreign country or with a distant organisation. You wouldn’t put a safe in a rented flat. For draft texts, research or the analysis of publicly available information, however, cloud services and the most powerful language models are often the right choice. This gives rise to three scenarios:

• Sensitive data and critical processes, such as HR, health and customer data, or the logic that sets one’s own business apart: open source, operated in-house or by a provider subject to the same legal jurisdiction as the organisation. The organisation then determines for itself who receives a key.
• Standard tasks such as email, Office applications or accounting: purchase these as a service, using open formats, documented interfaces and a tested export method.
• Performance-intensive tasks involving non-critical data: the most powerful cloud models, connected via a dedicated middle layer so that the model can be swapped at any time.

Which of your data is currently stored in a rented flat, even though it belongs in a safe?

How can you tell if your organisation is capable of making changes?

No provider currently offers complete independence, not even a European one. The realistic goal for most organisations is switchability. This can be assessed on the basis of four criteria:

1. For every business-critical service, it is known which jurisdiction the provider is subject to.
2. Data and configurations can be exported in open formats, and this has been tested at least once.
3. For the most important systems, there is a verified alternative; in the case of AI, a second model that has been tested with the same tasks.
4. Known decommissioning dates and contract expiry dates are marked in the responsible parties’ calendars.

The first step is to carry out an inventory of all software, cloud and AI services, including the tools that staff use on their own initiative. For AI services, the model version must also be included on the list. You then assess which services would bring operations to a standstill within a week, and check the legal jurisdiction, export route and alternative for each of these. The EU Data Act provides a reason for renegotiation: From 12 January 2027, cloud providers in the EU will no longer be permitted to charge switching fees.[37]

In my experience, the inventory takes a few days in a smaller organisation. Developing and testing a Plan B takes a few weeks, depending on the system landscape. The list of services, deadlines and alternatives then underpins every subsequent decision, from contract negotiations to architectural considerations.

Conclusion: Transferability can be prepared for

For an individual organisation, digital sovereignty boils down to one question: Can it replace a service before someone else makes that decision for it?

It builds up its own ability to switch providers, starting with those areas where a failure would cause the greatest damage. Open source and European providers make the transition easier, but they are no substitute for preparation. The Austrian Federal Government, too, formulates its goal pragmatically: State Secretary Alexander Pröll speaks of a ‘wise middle ground’.[38]

The first step is to ask your own IT department: Which service would bring our operations to a standstill within a week, and who else apart from us holds the key to it?

Notes:

If you’d like to discuss digital sovereignty with Thomas Morawek or take your first steps in this direction, connect with him on LinkedIn.

[1] AP, 15.05.2025: Trump’s sanctions on ICC’s chief prosecutor have halted tribunal’s work
[2] The Register, 18.02.2026: Microsoft asks UK Parliament to correct record
[3] Synergy Research, 24.07.2025: European Cloud Providers’ Local Market Share
[4] Bitkom, 17.06.2026: Cloud Report 2026
[5] A1/Integral, 20.05.2026: A1 Business Studie 2026
[6] Erik Pipal, OeNB-Blog, 23.10.2025: Digitale Zahlungen in Europa: Warum wir mehr Eigenständigkeit und Wettbewerb brauchen
[7] Schweizerischer Bundesrat, 12.12.2025: Medienmitteilung zur Strategie Digitale Schweiz 2026
[8] Jon „maddog” Hall, März 2026: Sovereignty
[9] 18 U.S.C. § 2713: Required preservation and disclosure of communications and records
[10] The Register, 25.07.2025: Microsoft admits it cannot guarantee data sovereignty
[11] never lost: Digitale Souveränität: Was der Begriff im KI-Zeitalter wirklich meint
[12] EU-Kommission, 12.01.2026: Call for evidence on open source digital ecosystems
[13] Hoffmann, Nagle, Zhou, Harvard Business School, 2024: The Value of Open Source Software
[14] HashiCorp, 10.08.2023: HashiCorp adopts Business Source License; Linux Foundation, 20.09.2023: Announcing OpenTofu
[15] Bitkom, 17.09.2025: Open Source Monitor 2025
[16] move-online, 08.12.2025: Open Source spart Millionen
[17] EU Open Source Observatory, 22.08.2025: Robert Koch Institute partners with ZenDiS
[18] The Document Foundation, August 2026: Why and how the Austrian military moved to LibreOffice, Teil 1 und Teil 2
[19] Schweizerische Bundeskanzlei: Open-Source-Software; datenrecht.ch: EMBAG für die Zentralverwaltung am 1. Januar 2024 in Kraft
[20] EU-Kommission, 03.06.2026: Commission boosts open and interoperable digital ecosystems
[21] Statistik Austria, Januar 2025: IKT-Fachkräfte in Unternehmen 2024
[22] Mistral AI: Models Overview
[23] Microsoft, 21.07.2026: Microsoft and Mistral expand strategic partnership
[24] Georg Kalus, european.cloud, 26.07.2026: Microsoft and Mistral
[25] EU-Kommission, 17.04.2026: Commission advances cloud sovereignty through strategic procurement
[26] NIST National Vulnerability Database: CVE-2024-3094
[27] Cyber Resilience Act, Verordnung (EU) 2024/2847: Artikel 71
[28] Statistisches Bundesamt: Unternehmen mit Nutzung von KI nach Beschäftigtengrößenklassen
[29] Statistik Austria, 24.06.2026: IKT-Einsatz in Unternehmen 2025
[30] OpenAI: API Deprecations
[31] Anthropic: Model Deprecations
[32] Open Source Initiative: Open Source AI Definition 1.0
[33] Meta: Llama 4 Acceptable Use Policy
[34] Verordnung (EU) 2024/1689 in der Fassung des Digital Omnibus, Überblick: Usercentrics
[35] EU AI Act: Artikel 26, Pflichten der Betreiber von Hochrisiko-KI-Systemen
[36] EU AI Act: Artikel 2
[37] EU Data Act, Verordnung (EU) 2023/2854: Artikel 29
[38] Bundeskanzleramt Österreich, 12.11.2025: Digitale Souveränität ist Sicherheitspolitik, Innovationspolitik und Demokratiepolitik

Would you like to support Thomas Morawek and discuss digital sovereignty in practice? If so, please share this post on social media or within your organisation.