“AI Made in Germany”: What Hosting Location, Data Processing Agreements, and Data Residency Really Mean

“Hosted in Germany” now appears on almost every provider’s website. For data protection officers and management, that’s a reassuring sentence. It’s also justified — but it answers fewer questions than it appears to.

This article sorts out the terms and names the questions that actually help in a vendor selection conversation.

A checklist of six questions for any provider, and three routes that work in practice, is on the page Using ChatGPT in a GDPR-compliant way.

Four levels that tend to get mixed up

1. Where is the data stored at rest?

This refers to the storage location: documents, search index, user accounts, logs. This question is usually answered, and the answer is often “German data center.”

2. Where is it processed?

That’s a different question. A provider can store documents in Germany and, for the actual answer generation, call a model that runs elsewhere. That call is exactly the process during which your contract text or customer inquiry gets transmitted.

So ask specifically: which country is the language model running in that actually reads my content?

3. Who can access it?

A server’s location says nothing about who has administrative access. If a provider with a German data center runs its support out of a third country, and that support can access data in the event of a fault, a third-country access is taking place — regardless of where the hardware sits.

4. Who is your contracting party?

Who do you sign the data processing agreement with? A German company, a European subsidiary, a company in a third country? That determines which law applies and who you turn to in a dispute.

Why the distinction matters in practice

What matters for the data protection assessment is whether personal data is transferred to a third country, and on what basis. Processing entirely within the EU simplifies this assessment considerably. As soon as a third-country link exists, you need a valid basis and, as a rule, a documented balancing test — effort that many Mittelstand companies would rather avoid.

There’s also an aspect beyond data protection: trade secrets aren’t personal data, yet they still deserve protection. Cost calculations, design data, and contract drafts don’t fall under the GDPR, but leaking them can be more expensive than any fine.

The questions for the vendor selection conversation

A list that has proven itself in practice. Ask for written answers — not out of distrust, but because you’ll need them for your documentation anyway.

• In which country is content stored, and in which is it processed?
• Which model is used, who operates it, and where?
• Are my inputs or outputs stored? If so, for how long and for what purpose?
• Is content used to train models? Does that also apply to outputs and usage data?
• Who are the subprocessors, and where are they based?
• From which countries do administrative access and support take place?
• Who is the contracting party for the data processing agreement?
• How are deletion requests implemented technically — including in logs and backups?
• What happens to my data when the contract ends?
• Are there certifications or audit reports, and exactly what do they cover?

The second-to-last question is rarely asked and is one of the most important: an export path for your configuration and content determines whether you’ll ever be able to switch providers again.

What “sovereign” and similar terms actually mean

A set of terms has become established around this topic that aren’t a certification mark of any kind. “Digital sovereignty”, “sovereign cloud”, “European solution” — these are all descriptions, not protected designations. They can mean a lot, or very little.

So check concrete characteristics instead of labels: contracting party, processing location, access paths, subprocessors, export option. These five points say more than any label.

Where location alone isn’t enough

A German data center doesn’t fix a poor permissions concept or missing logging. The most common security problems in AI projects are homemade: employees find documents that are none of their business; nobody can trace what an answer was based on; former colleagues still have access.

The hosting location is a necessary but not a sufficient condition. Anyone who only checks that has resolved the one question that was easiest to resolve.

The advantage that goes beyond compliance

There’s a practical reason for regional proximity that gets lost in data protection discussions: accessibility. When something doesn’t work, the difference between a support form in a foreign time zone and a contact person who knows your system landscape is bigger in everyday life than any feature comparison.

The same applies to rollout. The questions that actually cost time in Mittelstand projects — how is our directory structured, how did the permissions evolve, which department needs what — can’t be resolved via a support ticket.

Conclusion

“AI made in Germany” is a sensible criterion, but only once you break it down. Ask about storage location, processing location, access paths, contracting party, and exit — and get the answers in writing. After that, the assessment is easy.

We deliberately run our platform so that these questions can be answered clearly, and we disclose the chain all the way down to the subprocessors. Ask us about it — and ask every other provider the same way.

Reading certificates correctly

Providers like to point to certifications. These are a useful signal, but they don’t automatically answer your question. What matters is the scope: a certificate can apply to the data center, to the provider’s organization, or to a specific product — and these three are not the same thing.

So ask specifically which scope is certified, by whom, when it was last audited, and whether the audit report can be reviewed. A provider who answers that clearly is likely to be a reliable partner on other questions too.

The difference between storage and training

Two terms are often confused and should be clarified separately. Storage means your inputs and the generated responses are retained for a certain time — often for abuse detection or error analysis. Training means your content flows into a model and can therefore potentially show up in answers given to others.

For most companies, training is a disqualifying factor, whereas brief, purpose-bound storage is acceptable — provided it’s stated in the contract with a defined time limit. Get both confirmed separately.

Frequently asked questions

Is it enough for the provider to be headquartered in Germany?

No. The registered office says nothing about the processing location, the subprocessors, or the access paths in support. Ask about the whole chain, not the address.

What about models developed outside the EU?

The place of development is irrelevant under data protection law. What matters is where the model is operated and who has access there. A model developed outside the EU that runs in a European data center can meet the requirements.

Do we need a data protection impact assessment?

That depends on the use case, not the tool. For applicant selection, performance evaluation, or extensive processing of sensitive data, it’s regularly required. Clarify this with your data protection officer before you start.

How do we document all of this?

One page per system is enough: provider, contracting party, processing location, subprocessors, retention period, training exclusion, contact person, date. This page will later answer most of the questions that come your way — from the supervisory authority as much as from your own customers.

The question catalog as a working document

So the review doesn’t get reinvented for every provider, it’s worth having a fixed document that you send out unchanged. It has three sections.

Section 1 — Technical information. Country of storage. Country of processing. Models used and their operators. Storage of inputs and outputs, with duration and purpose. Use for training, answered separately for inputs, outputs, and usage data. Encryption in transit and at rest.

Section 2 — Contractual information. Contracting party with registered office. Data processing agreement with a template. Complete list of subprocessors with location and role. Procedure when a subprocessor changes. Provisions for deletion and data export at contract end.

Section 3 — Organizational information. Which countries support and administrative access take place from. How that access is logged. What certifications exist, with scope and audit date. How security incidents are reported, and within what timeframe.

Ask for the answers in writing. That’s not distrust, it’s your documentation — and it reliably filters out providers who don’t have a solid answer to these questions.

Assessing the answers correctly

Not every uncomfortable answer is a disqualifier, and not every reassuring answer is a good one. Three patterns help you make sense of them.

Evasive answers to precise questions are the clearest warning sign. Someone who responds to “Which country does the model run in?” with “We process data in compliance with the GDPR” understood the question and didn’t answer it.

Certificates without a stated scope say little. A certificate for a subprocessor’s data center is something different from one for the product you’re using. Ask about the scope and the audit date.

Openly stated limitations are a good sign. A provider who says “Some of our support is based outside the EU, access is logged and limited to incident cases” is more reliable than one who claims there’s no access at all. The latter is practically never true.

What you should document yourself

Create one page per service used, containing: provider and contracting party, purpose of use, data categories affected, processing location, subprocessors, retention period, training exclusion, contact person at the provider, the internally responsible person, and the date of the last review.

This one page will later answer most of the questions that come your way — from the supervisory authority, from the data protection officer, from customers as part of vendor audits, and increasingly from public-sector clients too. Creating it properly once costs an hour; pulling it together after the fact costs a day.

The special case of data processing in the supply chain

If you’re a service provider yourself and use AI in delivering services to customers, the perspective shifts: you’re then not just the controller for your own data, but a processor for your customers’ data — and the AI provider becomes your subprocessor.

As a result, there are three duties that are easily overlooked. You need your customers’ approval for this subprocessor; depending on the contract, that’s either a general approval with a right to object or explicit consent case by case. You must pass on the obligations your customers have placed on you — a data processing agreement that’s weaker than your own doesn’t work. And you should inform your customers of changes, for example if the provider switches a subprocessor.

In practice, that means: before you turn an AI tool loose on customer data, check your customer contracts. This review takes an hour and can save you an uncomfortable conversation later.