Digital Sovereignty Doesn't End at the Server Location

Recently, on an AI podcast: the founder of an AI training academy presents his solution and calls it "digitally sovereign". His reasoning: the database and the memory stores sit on a server in Frankfurt. In the same breath he admits, "The models are still American." US LLMs, switched with a click, including a backup model in case one goes down. This is exactly where the reasoning breaks, and it is a common mistake. Server in Frankfurt, model from the US: that is precisely not sovereign. I take this up as a principle, not as a person. And I will state clearly what it means from the perspective of data protection and information security.

You measure sovereignty by the data flow, not by the data center

Digital sovereignty means this: you keep control over who processes your data, when, where and how. The location of a database is only one building block, and often the least important one. What matters is where the data flows when actual work happens.

In an AI system, "working" means: a prompt goes to a model, the model answers. This process is called inference. And inference happens where the model runs. If the model runs in the US, every prompt goes to the US for inference. With everything it contains.

What does it contain? In practice: customer names, contract details, uploaded documents, proposal text, internal notes, sometimes entire PDF attachments. The database in Frankfurt may store the system's memory. But the actual processing, the thinking, takes place on a third-party model in a third country. A vault in Frankfurt is of little use if you ship its contents overseas every day to work on them.

A server in Frankfurt does not make your data sovereign if the model that reads it is computing in Virginia. What is sovereign is the data flow, not the postal code of the hard drive.

A prompt sent to a US model is a third-country transfer

Under data protection law this is not a detail, it is the core. When personal data goes to a US model API for inference, that is a transfer to a processor (or sub-processor) in a third country. This brings Chapter V of the GDPR into play, Article 44 and following. Such a transfer is only permitted if you meet the conditions set out there.

In concrete terms you need at least three things. First, a data processing agreement under Article 28 GDPR with every provider that processes data on your behalf. Second, a valid transfer mechanism under Chapter V, typically Standard Contractual Clauses or a suitable adequacy decision. Third, complementing these, a Transfer Impact Assessment: a documented review of whether the destination country actually achieves an adequate level of protection despite the contract, or whether additional measures are required.

This is not red tape, it is the law in force. And it is my professional assessment as an auditor, not individual legal advice. The point stands: "server in Frankfurt" answers none of these three questions. The hard drive in Frankfurt replaces neither the processing agreement, nor the transfer mechanism, nor the review of the data flow to the model.

The one-click model switch multiplies your processor chain

Now for the part that was sold on the podcast as a feature: you can switch the model with a click, and there is a backup model in case one fails. It sounds like flexibility. From a compliance perspective it is the opposite of control.

Every model you can switch on is another processor in your chain. Switch to provider A today, provider B tomorrow, with a backup model from provider C running in the background, and you now have three potential recipients of your customer data. The same duty applies to each of them: processing agreement, transfer mechanism, review of the level of protection. You must have this under control contractually and technically, not just in the founder's head.

• Which model providers are configured, and in which country do they actually compute?
• Is there a data processing agreement under Article 28 GDPR for every single one, including approved sub-processors?
• For each third-country provider, does a transfer mechanism under Chapter V and a Transfer Impact Assessment exist?
• Is your data used for model training, or is training cleanly excluded by contract?
• Who decides the model switch: you, or does the system fail over automatically to a backup you have never reviewed?

If you cannot answer these questions for every model that can be switched on, the one-click switch is not convenience, it is an open barn door. An automatic fallback to an unreviewed backup model is a data protection incident waiting to happen: your customer data ends up with a recipient no one ever approved.

ISO/IEC 27001 demands exactly this control over the supply chain

Anyone who thinks this is only a data protection topic underestimates information security. ISO/IEC 27001:2022 addresses precisely this situation in Annex A. Controls A.5.19 to A.5.22 govern security in supplier relationships: you must define, agree and monitor requirements for suppliers throughout the entire term. Control A.5.23 was newly added in 2022 and applies explicitly to the use of cloud services: acquisition, use, management and exit must meet your security requirements.

An interchangeable US model in the background is nothing other than a cloud service in your supply chain. An auditor then simply asks: show me the list of your model providers, the contracts, the approval processes and the evidence that a model switch does not carry data into a new third country in an uncontrolled way. Whoever only points to the Frankfurt server has not understood the question. This is a classic finding, and I see it often.

Claim versus reality: what "sovereign" really means

I have nothing against US models. I use powerful AI in my own AI-driven ERP, and for many use cases the large models are simply the best choice. The point is not whether you use US models. The point is whether you know it, whether you have it under control and whether you name it honestly.

"Digitally sovereign" because the database sits in Frankfurt, while the models are, by the provider's own admission, "still American": that is a self-contradiction. It would be sovereign if you controlled the entire data flow, if the processor chain were documented without gaps and if every recipient were under contractual and technical control. Or if, for sensitive cases, you relied on a model with processing kept within Europe or a self-hosted model. Marketing does not replace a processor chain. And a server location does not replace data sovereignty.

My advice from the workshop floor: judge every AI solution not by the marketing word, but by the data flow. Map out where a prompt with real customer data actually travels. Only once that map is complete do you know whether "sovereign" is merely on the label or genuinely inside.