Why digital sovereignty is not the same as GDPR compliance

• GDPR compliance governs whether a solution operates lawfully. Digital sovereignty concerns the strategic control over data, software and decisions. The two terms mean different things, and confusing them becomes a risk for companies.
• What matters is who controls the provider, because the US CLOUD Act follows the ownership structure and does not stop at national borders.
• Sovereignty is therefore a question of risk management and belongs at leadership level. amber stores the core of its software on Deutsche Telekom’s T-Cloud and does everything technically possible to operate as sovereignly as possible.

In almost every conversation about AI and the cloud, the phrase comes up: “But we’re GDPR-compliant.” What is usually meant is that the servers are in Europe, a data processing agreement is in place and the data is encrypted. That matters, but it answers a different question than the one about digital sovereignty.

GDPR compliance is operational and legal at its core. It describes whether personal data is processed lawfully: purpose limitation, data minimisation, data subject rights. Digital sovereignty is strategic. It describes whether a company itself decides over its data and systems in an emergency, or whether someone else does. The same applies to the EU AI Act: it governs how AI systems are operated safely, transparently and in a risk-appropriate manner, but likewise does not answer the question of strategic control.

The German digital association Bitkom defines digital sovereignty as “the ability to exercise self-determination in the digital space.” The term aims at reducing one-sided dependencies and preserving freedom of choice. It does not mean complete autarky, where a company runs everything itself. The BSI has now formalised the distinction as well: with its C3A criteria catalogue, the agency no longer assesses only the technical security of a cloud offering via the well-known C5 catalogue, but additionally whether an offering “can be used in a self-determined way within the respective risk context.” Security and sovereignty are thus two separate assessment dimensions.

The CLOUD Act of 2018 requires US companies to hand over stored data on the order of a US authority, regardless of the storage location. What is decisive is control over the company, while the location of the data centre recedes into the background.

This creates a paradoxical situation. A European customer engages a provider based in Europe whose servers are located in Frankfurt. If that provider has a US parent company, the parent can be compelled to hand over the data from Europe. The reach arises from the ownership structure via the group parent and therefore applies across national borders. On top of this, such orders are often tied to a duty of secrecy. The affected European customer may never find out about it. There are certain bureaucratic hurdles to this, but legally it is possible.

This directly conflicts with Article 48 GDPR, which prohibits such disclosure without a mutual legal assistance agreement. The same conflict caused the EU-US data protection agreement to fail in the CJEU’s 2020 Schrems II ruling, because US surveillance law does not provide an equivalent level of protection. For a long time this was regarded as a theoretical risk – until one day in June 2025.

On 10 June 2025, two senior representatives of Microsoft France testified under oath before an inquiry committee of the French Senate. The rapporteur Dany Wattebled asked general counsel Anton Carniaux whether he could guarantee that the data of French citizens would never be handed over to the US government without the consent of the French authorities.
The recorded answer was: “No, I cannot guarantee that.” Carniaux added that such a case had never occurred to date.

Microsoft had previously assured that the data of European customers would contractually never leave Europe, neither at rest nor in transit nor during processing. This lays the core bare: a solution can be run in Europe in a technically and legally clean way and still not be sovereign. When the ultimate decision-making power lies in another legal jurisdiction in an emergency, contractual clauses only help to a limited extent.

Instead of arguing over buzzwords, a sober look at two questions helps.
The first concerns the supply chain. How dependent is a company on a provider, how quickly could it be replaced, and under which legal system does it operate? The market situation is clear: the three large US hyperscalers – Amazon Web Services (AWS), Microsoft Azure and Google Cloud – control around 70 percent of the European cloud market, while the share of European providers has fallen over the years. A vendor lock-in therefore concerns far more than price and becomes a risk to a company’s ability to act, because functions, prices or entire services can change unilaterally.

The second concerns decision-making power. Who decides over the data in case of doubt, and in whose interest? This is about ownership structure, control and governance. A US-controlled provider must follow US law in the event of a conflict, regardless of the contract text. That is the immediate lesson from the Senate hearing.

Most discussions revolve around hosting and the question of where the servers are located. The same logic applies one level up, at the software provider itself.

An example at the software level: an AI provider presents itself externally like a German company, with a German GmbH, a German team and European servers. A look at the shareholder structure, however, shows that the shares are held 100 percent by a US holding company – for instance a corporation registered in Nevada – which in turn is owned by a mixed group of European and American shareholders. From a GDPR perspective, everything can be clean here. From a sovereignty perspective, it is not, because the US holding is subject to the CLOUD Act and can instruct its German subsidiary to hand over data. The German veneer changes nothing about this. What remains decisive is who sits at the top of the ownership chain and can be compelled to disclose data in an emergency.

How concrete this dependency can become was shown by a case from The Hague. After the US government imposed sanctions on the chief prosecutor of the International Criminal Court, Karim Khan, in early 2025, he lost access to his email account held at Microsoft and switched to the Swiss provider Proton. Microsoft stated that it had at no point discontinued its services for the court; the exact sequence of events is disputed. For the affected person’s ability to work, the consequence was substantial: a sanctions decision in Washington had an immediate effect on the digital infrastructure of an international institution in Europe. The court subsequently migrated parts of its IT to an open-source solution.

How real the risk is at the model level too became apparent in June 2026. The US government ordered the AI provider Anthropic, via an export control directive, to block access to two new models for all foreign users, citing national security. Since US and non-US citizens could not be separated in real time, the provider shut the models down worldwide for all customers that same evening – including European ones with no connection whatsoever to the order. The provider considers the measure unjustified and legally challengeable, but complies with it. For companies that had built on these models, the software foundation disappeared overnight through a decision they had no influence over. Just under two weeks later, the models were re-enabled (as of 2 July 2026).

GDPR compliance provides the legal foundation. Digital sovereignty determines who retains control over the data in an emergency.

For most companies, the analysis ends at digital sovereignty and the GDPR. For professionals bound by confidentiality – such as doctors, lawyers, tax advisors and auditors – an additional layer comes into play. Section 203 of the German Criminal Code (§ 203 StGB) makes the unauthorised disclosure of client and patient secrets a criminal offence, independently of the GDPR and with stricter standards. Since the 2017 reform, the use of IT and AI service providers has been permitted, but only if they are effectively bound to confidentiality.

The word “effectively” is decisive here, and it concerns two parties at once. The cloud provider must guarantee confidentiality. Deutsche Telekom’s T-Cloud does this and provides professionals bound by confidentiality with a standardised confidentiality agreement in accordance with § 203 StGB. US providers offer such a guarantee only in exceptional cases at best, because their group parents can be compelled to disclose data via the CLOUD Act. Alongside this, the software provider itself is also under obligation: it must secure confidentiality technically and contractually bind its employees to secrecy.

This leads to a clear practical consequence. For professionals bound by confidentiality, only AI models operated on the T-Cloud, or from providers that guarantee § 203 StGB throughout, are eligible. A mere confidentiality clause with a US-controlled provider does not hold, because an official order overrides it in an emergency – often under secrecy, so that neither the firm nor the client finds out. What cannot be read technically and cannot be disclosed also cannot be revealed.

Sovereign alternatives address exactly these points. Deutsche Telekom’s T-Cloud is operated from European data centres and by staff based in Europe and, as a German company, is subject to the European legal framework; there is therefore no obligation to disclose data to non-European authorities. Open standards also keep the door open for migrations and reduce the lock-in risk.

amber has built this consequence into its own architecture. The core of the software sits on the T-Cloud; all development and processing steps take place on servers in Germany and Europe. There, certain AI models are available sovereignly by default, under German and European law and according to German values. GDPR compliance is thus covered, and the strategic question of sovereignty is additionally answered.

amber also names the limits. The platform can be extended with models from providers such as OpenAI, Google or Anthropic if a customer wishes. Some of these come with a restriction: OpenAI, for example, hosts exclusively on Azure, so these models are obtained via Azure Europe. By default, amber operates sovereignly; extending it with additional models remains a deliberate decision by the customer with a transparent trade-off. amber does everything technically possible to act as sovereignly as possible – and makes visible where the limits lie.

1. Know your dependencies. Which processes come to a standstill if a provider discontinues the service or raises prices, and which data is particularly worth protecting?
2. Check the legal jurisdiction. It must be clarified who controls the provider and which legal system the group parent is subject to; the server location alone is not sufficient as a criterion.
3. Keep sensitive matters sovereign. Critical data and core applications belong in sovereign, European environments. For non-critical workloads, hyperscalers remain a legitimate option, since sovereignty means freedom of choice and does not exclude such providers in principle.
4. Consider regulated sectors separately. As soon as professional secrets, health, financial or critical-infrastructure (KRITIS) data are involved, the GDPR question is not enough, and the guarantee under § 203 StGB becomes a selection criterion for cloud and software.

If you'd like to see what a GDPR-compliant solution hosted on a sovereign cloud can look like, talk to us.