How to check AI vendor sovereignty: 10 pieces of evidence you should request
Whether an AI vendor operates with sovereignty cannot be judged from claims like "GDPR compliant", only from verifiable evidence. This includes the location and operator of the hardware, the list of subprocessors, the jurisdiction of the parent company, access to logs, a binding statement on training, encryption, a data deletion policy and an arrangement for the exit.
Why promises are not enough
"GDPR compliant" appears on almost every AI website. It can almost never be verified. In 2026, sovereignty has become the price of entry: many vendors promise it, few prove it.
The need is real. According to the Bitkom Cloud Report 2026, 85% of the companies surveyed feel too dependent on US clouds, 71% use them anyway, and 43% see no equivalent European alternative. At the same time, only 12% accept a premium of 10 to 20% for a sovereign solution. So companies want sovereignty, yet they are not willing to pay for it blindly. That makes it all the more important to check what they actually get.
A common misconception concerns the server location. A data center in Frankfurt says little about who can access the data. The US CLOUD Act obliges US companies to hand over data to US authorities, regardless of where the servers are located. How serious this question is became clear in 2025 at a hearing before the French Senate. Asked whether Microsoft could guarantee that data of French customers would remain out of reach of US authorities, the representative of Microsoft France replied: "Non, je ne peux pas le garantir."
This calls for a change of perspective. Do not ask whether a vendor is sovereign. Ask for evidence.
The 10 pieces of evidence at a glance
| No. | Evidence | How you recognize a good answer |
|---|---|---|
| 1 | Location and operator of the hardware on which the model runs | A specific data center and a named operator, not just "in Germany" |
| 2 | List of all subprocessors with access to data or metadata | A complete list with location and purpose, including monitoring and support, with an obligation to inform you in advance of any changes |
| 3 | Data processing agreement with specific technical and organizational measures | The measures are described for the specific system, not as a generic template for all products |
| 4 | Logging of every use and your right to inspect the logs | You see the logs yourself, in an exportable format, without having to submit a request each time |
| 5 | Binding statement on whether inputs are used for training | The exclusion is written into the contract and also applies to subprocessors and to metadata |
| 6 | Jurisdiction of the vendor and its parent company | A disclosed corporate structure up to the ultimate parent company, with a statement on obligations to hand over data to authorities outside the EU |
| 7 | Encryption in transit and at rest, including key management | A clear statement of who holds the keys; ideally they stay with you or in your environment |
| 8 | Role and permission concept for your team | Roles can be adapted to your organization and connected to your directory service |
| 9 | Data deletion policy with retention periods | Periods for each type of data, including logs and backups, with written confirmation of deletion |
| 10 | Exit arrangement covering data format and costs | Handover in open formats, with a deadline and a quantified effort, as part of the main contract |
The following table summarizes which evidence an AI vendor should be able to provide and how you can tell a solid answer from an evasive one.
A simple rule of thumb helps with the assessment: if a vendor evades more than two points, sovereignty is a promise, not a fact.
How to carry out the review
The review works best when it does not rest with procurement alone. Three perspectives belong at the table: your IT team assesses architecture, encryption and the permission concept. Your data protection team assesses data processing, subprocessors and the data deletion policy. Your works council is interested in logging and in how usage data can be analyzed.
A proven process in four steps:
-
Ask in writing. Send the ten points as a questionnaire and ask for answers with supporting documents, not for a presentation.
-
Assess documents, not slides. A data processing agreement, a list of subprocessors and a data deletion policy are documents that either exist or do not.
-
Request a spot check. Have the vendor show you log access and the permission concept in the live system.
-
Record the result. Note which evidence was provided in full, in part or not at all. This gives you a basis for comparing vendors.
Repeat the review at regular intervals and with every major change. Evidence ages: subprocessors are added, corporate structures change, a vendor switches the model in the background or moves support to another country. For this reason, agree contractually that you will be informed of such changes in advance and can object to them. A review at contract signing is a start, not a permanent state.
It also helps to store the results centrally, for example in the record of processing activities or in your information security documentation. That way, in an audit or an inquiry from the supervisory authority, you can show that you did not just select the vendor but also reviewed it.
Whether a contract meets the requirements of the GDPR in an individual case remains a legal assessment. Involve your data protection officer for this and, if needed, a legal review.
Typical evasive answers and how to assess them
Evasive answers often sound convincing. Buyers encounter four patterns again and again.
"Your data is stored in Germany." That answers the question of location, not of the operator and not of the jurisdiction. Ask about point 1 and point 6.
"We are certified." Certificates are valuable, yet they cover a defined scope. Ask which certificate applies to which system and which location.
"We do not train on your data." What matters is where that is written. A statement on the website is not a contract. Ask whether the exclusion also applies to subprocessors and to model providers in the background.
"Our standard contract covers that." Standard contracts are legitimate. They should, however, describe the measures for the specific system. Ask for the annex with the technical and organizational measures.
What this means for our systems
For our own systems, the rule is: what we promise must be verifiable. By your IT team, your data protection team and your works council. We operate AI systems in environments you control, in your own data center or with a German hosting provider, with open models and complete logging. We describe the setup under Private AI Infrastructure and our security measures under Security.
We take the tenth piece of evidence particularly seriously. How we handle the exit, with format, deadline and costs, is described under Exit.
Sovereignty that cannot be verified is marketing.
Frequently Asked Questions
Is a data center in Germany enough for sovereign AI?
No. The operator and the jurisdiction of the parent company matter as well. The US CLOUD Act applies regardless of server location.
Who in the company should review the evidence?
IT, data protection and the works council together, each with its own focus. For contractual questions, a legal review complements the technical assessment.
What should you do if a vendor cannot provide some of the evidence?
Record the gap in writing and assess whether it is relevant to your use case. If a vendor evades more than two points, you should look at alternatives. Would you like to assess your current or planned AI vendors against these ten pieces of evidence? We will gladly go through the points with your IT and data protection teams. Schedule an initial consultation.
Sources and References
- Bitkom e. V.: Cloud Report 2026, representative survey of 603 companies in Germany.
- Hearing of Microsoft France before a commission of inquiry of the French Senate, 2025.
- Clarifying Lawful Overseas Use of Data Act (CLOUD Act), USA, 2018.
