Sovereignty comes from knowledge, not from where the server stands

As a question of location, as a question of contracts, as a question of which flag flies over the data centre: that is how digital sovereignty is being discussed right now. The debate is good news, because it raises a question that went unasked in mid-sized industry for years. It only leads somewhere if you discuss and think it all the way through. Germany's Federal Office for Information Security published a criteria catalogue in April 2026 that does exactly that, and it is the occasion for this piece.

What the location does deliver

A server in Germany brings tangible things: short paths to the supervisory authority, familiar contract law, a court you know. For personal data it is the most convenient way to shorten a discussion, which is why our own working environment, the AIEE server, sits in Germany too.

The location answers exactly one question, however: where the data rests. The two that matter in daily operations stay open: who can read it and who holds the key. A safe offers protection not because it stands on your own ground floor. It protects because somebody holds the key and knows what belongs inside.

The question that leads somewhere

Anyone who stops assessing an AI initiative as a whole and breaks it into steps arrives at usable answers quickly. Which step actually processes something worth protecting? Which one works with material that leaves the building anyway? Where do harmless pieces combine into a picture that did not exist before?

In practice the split happens fast. A quotation assembled from blocks that already sit in the internal catalogue. A fault description and diagnosis from a service report that lands at the customer and operator tomorrow. A personnel file. A drawing carrying the manufacturing trick that defines the company. Four processes, four entirely different answers, and one blanket rule would serve none of them.

Making that distinction is work, and it is the actual competence. Anyone who has done it once for their own company decides every further question in minutes rather than in workshops.

Grading instead of all or nothing

Out of that distinction come tools nobody would deploy without it. A process can start with a small, cheap model and call in a large one only for the hard cases. Individual fields can be substituted before the model call, so the machine works with a structure instead of the real name. One particularly delicate step stays in-house while the rest takes the convenient route.

The most effective move is also the simplest: critical details leave the text before it reaches the model. Passwords and access tokens, names and addresses, personal details, customer and supplier data can be pulled out beforehand and replaced by placeholders. In most cases that already suffices. It protects more than data privacy: also the technical knowledge that sits in designations and relationships, and in the age of tokens, a kind of password for machines and AI, the access itself.

That is where a matter of principle turns into a project: not everything or nothing, but the fitting answer per step. Costs fall along the way, because the expensive model only sees the cases it is needed for.

The state now reasons the same way

Anyone taking this for a consultant's position will find the same thought in a criteria catalogue published by the German Federal Office for Information Security in April 2026. C3A assesses how autonomously a cloud offering can be used in a given risk context, and it does so through individually verifiable points: exit capability, control over encryption, legal access by third parties. The catalogue builds on the established C5 security criteria.

C3A in brief. The full name is Criteria Catalogue Cloud Computing Autonomy, and it extends the long-established C5, which examines the security of a cloud service, by the question of independence. Assessment runs along individual factors rather than in the aggregate: how easily a service can be left again, who controls the encryption, which legal access by third parties exists, how tightly an operation depends on the vendor technically. It is meant as shared language for procurement, IT and vendors, so that a tender contains something verifiable instead of a marketing promise. Published by the BSI.

What is remarkable is the framing. It no longer asks whether the server sits in the EU, but how much independence this particular system needs and how much of it can be evidenced. For a company that means an ERP holding design data and an internal scheduling tool may be treated differently, and there is now shared vocabulary for procurement, IT and vendors to use.

The objection, and it is a strong one

There is a serious counter-argument: the US CLOUD Act reaches further than the location suggests. A legal opinion prepared for the Dutch Ministry of Justice concludes that a European company without any US establishment can still be covered, as soon as it maintains sufficient commercial contacts there. Concluding from this that choosing a location achieves nothing is correct. Concluding that nothing can be done draws the wrong consequence.

That same opinion records that the act is encryption-neutral: it obliges nobody to be able to decrypt. With the keys held beyond the provider's reach, the provider cannot even establish whether it holds the data in question. Of all the measures under discussion, that is the only one a company can implement under its own power. Location, corporate structure and contracts sit elsewhere. The key sits in your own house or it does not.

The story of Gaia-X teaches the same lesson from the other side. Launched as a European alternative to the large providers, it arrived as a set of criteria and labels. The political claim to an infrastructure of one's own and what reaches a company's procurement are two different things. What remained usable is comparability, so once again: knowledge rather than place.

What follows from this

For the company: a data strategy that distinguishes everyday material from what genuinely needs protecting, plus key ownership where it counts. Both are achievable in weeks, require no change of provider and outlive the next regulation.

Such a data strategy starts with an inventory, and that is plainer than the word suggests:

• Which data sits in the company, and what is it actually used for?
• Where does it come from, and how does it arise: from the machine, from the ERP, from an employee's hand?
• Where does it rest today, and who can reach it there?

The strategy grows out of that collection: which data serves which purpose, where it rests, and how it is secured there. Secured means two things that are readily confused: secured against loss, meaning the backup, and secured against access.

What matters is that the answer may differ per kind of data. Design drawings and the development of a new machine generation can sit on your own server or with a German provider, encrypted on top, while e-mail keeps running at a US provider such as Microsoft 365. Both at once is no contradiction; it is the result of a deliberate decision. Practising exactly that distinction is what the workshop and the practice programme do on your own initiative.

For the executive personally: the ability to ask the right question when talking to IT, procurement and vendors. That is the part you could delegate and had better not, because it decides whether an initiative starts or stalls in a debate about principles.

Sovereignty is not, in the end, a property of a data centre. It is the ability to decide deliberately, and it grows with knowing what is genuinely valuable in your own house.

State of this account: 2026-09. The BSI criteria catalogue C3A was published in April 2026; the cited CLOUD Act opinion dates from 2022 and describes the mechanics rather than the current state of every individual question.