An AI chatbot hosted in Germany processes personal data exclusively in the EU, transfers no data to third countries during operation, and thus renders the most sensitive GDPR question obsolete: third-country transfer. Two things are decisive here. First, where the chatbot runs. Second, where it sends data with every response. It is precisely at this second point that many supposedly German solutions fail.
At a glance
The data flow is what matters: A frontend operated in Germany that calls a US API for every response is not data sovereign.
US cloud remains a legal risk: As soon as data enters the US, the CLOUD Act and FISA apply. The basis for transfers can cease to exist at any time.
Data sovereignty is created through architecture: EU hosting, European models, and no external API calls.
For regulated industries and the public sector, the data location is often an exclusion criterion.
What to watch out for: Processing location, data flows during operation, sub-processors, model hosting, encryption, and deletion concept.
What "chatbot hosting in Germany" really means
"Made in Germany" on the website says little about where your customer data actually ends up. An AI chatbot consists of several components, such as frontend, dialogue logic, knowledge base, and language model, and each of these can run in a different location.
Genuine German hosting means that all components that process personal data run in the EU, including the language model. Although many solutions host the interface and database in Germany, they forward the actual response generation via API to a US provider. At that moment, the content of the user query leaves the EU.
The decisive audit question is therefore: Does any personal data leave the EU to answer a question? The location of the server alone is not sufficient as an answer.
Why US cloud chatbots are a compliance risk
As soon as personal data is transferred to the US, companies need a robust transfer mechanism and bear the risk if its foundation is invalidated. This is not a theoretical scenario. The legal framework for transatlantic data transfers has been overturned several times in the past.
In addition, there is the US CLOUD Act. It obliges US providers to hand over data, even if it is physically located in Europe, as long as the company is subject to US law. A European data center of a US corporation therefore does not fully solve the problem.
For banks, insurance companies, and the public sector, the data location is therefore often a knock-out criterion in tenders. Anyone relying on a US cloud here risks being disqualified from the process from the very start.
Data sovereignty is created through architecture
Contracts and assurances cannot cure an architectural problem. Data sovereignty is achieved when data cannot technically leave the EU in the first place. Three building blocks are crucial for this:
Processing exclusively in the EU, including all sub-processors, with the shortest possible chain.
European, self-hosted models. The language model runs within the same EU environment as the other components, without API calls to external providers.
No use of customer data for training third-party models, contractually and technically excluded.
If these three points are met, the question of third-country transfer no longer arises at all.
Checklist: What you should look out for in chatbot hosting
Processing location: Is all personal data processed exclusively in the EU?
Data flows during operation: Does the bot call external (US) APIs to answer questions? If so, what data is transmitted?
Model hosting: Does the language model run in the EU environment or at an external provider?
Sub-processors: How short and EU-centric is the list in the data processing agreement (DPA)?
Encryption: Is data encrypted in transit and at rest? Are customer-managed keys possible?
Training usage: Are your conversations used for training?
Deletion concept: Are retention periods configurable and can users delete their data themselves?
These points are also the core of a GDPR- and EU AI Act-compliant AI chatbot. Hosting is a central building block here, but not the only one.
How Mercury.ai hosts
Mercury.ai is the conversational AI platform from Germany and is designed for data sovereignty through architecture:
Processing exclusively in the EU, in Germany. Mercury.ai operates its environment on the AWS European Sovereign Cloud, which is operated by an EU legal entity with EU personnel. End-user data is processed exclusively there, without any third-country transfer.
A single sub-processor (Amazon Web Services, Germany branch) keeps the processing chain short and the DPA verification simple.
European, self-hosted models: Mercury.ai uses licensed, self-hosted, and fine-tuned Mistral models. There are no API calls to external providers, and the data remains in Germany.
Encryption with customer-managed keys. Data is encrypted in transit and at rest (AWS KMS and HSM). With customer-managed keys, ownership remains with the customer, meaning the operator cannot read the contents.
No training with customer data, no cross-client learning. Responses are generated solely from your verified sources.
Security: Tenant separation, two-factor authentication, full audit logging, and regular penetration testing. The data centers used are ISO-27001 certified; Mercury.ai aligns itself with ISO 27001.
As a result, the frequent CLOUD Act objection does not apply. Processing takes place in an EU-operated environment, and thanks to customer-managed encryption, the data is unreadable even in a theoretical access scenario. Data sovereignty here arises from the combination of EU operation and customer key ownership.
That this model also holds up in highly regulated environments is demonstrated by Volkswagen Bank, which uses Mercury.ai to automate recurring customer queries around the clock. You can read how the knowledge base and model architecture work together under Mercury Intelligence. Read about our approach to the EU Artificial Intelligence Regulation in the EU AI Act Security Paper.
Frequently Asked Questions (FAQ)
Is it enough if the chatbot provider is based in Germany?
No. The company's headquarters say nothing about where the data is actually processed. What matters is the real processing location of all components, including the language model, and whether data is transferred to third countries during operation.
Is a European data center of a US provider GDPR-compliant?
A standard cloud region alone does not fully solve the issue because the provider can be forced to hand over data via the CLOUD Act. Two levers are decisive: an environment operated by an EU legal entity, such as the AWS European Sovereign Cloud, and customer-managed encryption so that no readable data is released even in the event of an official order.
Mercury.ai runs on AWS. Isn't that still a US cloud?
The processing takes place on the AWS European Sovereign Cloud, which is operated by an EU legal entity with EU personnel, and the data is encrypted with customer-managed keys. Even in the theoretical event of an order under the US CLOUD Act, no readable data could be handed over. The combination of EU operation and key ownership is what makes the difference.
What does data sovereignty specifically mean for an AI chatbot?
That the data technically does not leave the EU. Hosting, knowledge base, and language model run in an EU environment, without external API calls and without training using your content.
Can we keep the data in Germany and still use generative AI?
Yes. Generative AI can be operated with self-hosted, European models. The generative component then only formulates the response while the processing remains in Germany.
Conclusion
When it comes to chatbot hosting, architecture makes the difference. Those who rigorously verify the processing location, data flows, model hosting, and deletion concept achieve genuine data sovereignty and render the GDPR question of third-country transfer obsolete.
Would you like to know what data-sovereign chatbot hosting looks like for your company? Get in touch with us or download the EU AI Act Security Paper.
About the Author: Dr. Maximilian Panzner is CTO and co-founder of Mercury.ai. He holds a PhD in computer science from the CITEC Institute of Bielefeld University, where he researched multimodal machine learning and intelligent interaction systems. For more than 20 years, he has been working on artificial intelligence, human-machine interaction, and dialogue-oriented AI platforms for enterprise use.
