EU hosting for AI: what nobody tells you

Ten minutes on a SaaS website is enough: everyone claims 'EU hosted'. Sometimes 'EU data residency'. The odd one 'EU sovereignty'. It looks like the same thing, it is anything but. And for AI applications, where you work with LLMs trained in the US on data from all over the world, the difference between those terms is the difference between GDPR compliant and a potential data breach.

The three levels, in ascending order of strictness

Level 1: EU servers

The weakest claim. It means: the physical machine sits in an EU data center. But it says nothing about where the data comes from or goes to in between. The load balancer can sit in the US, the logs can go to Australia, the backups can live in Singapore. 'EU servers' is a postcode, not a guarantee.

Level 2: EU data residency

Stricter. It means: all persistent data (database, file storage, backups) stays within EU borders. But 'persistent' is the trick: temporary processing, an API call, a log line, a queue message, can still cross an EU border. For LLM AI that's a big leak, because every user interaction passes through a model running somewhere.

Level 3: EU-only processing

The right benchmark. It means: during NO phase whatsoever, not storage, not processing, not temporary caching, does data leave the EU. Including the inference call to the language model. This requires your LLM provider to also have an EU endpoint, and for you to explicitly use that endpoint.

Where it goes wrong with AI tools

Most AI helpdesk tools claim 'EU data residency' but use an American LLM API without EU routing. That means every user question, including all context (customer name, order number, possibly payment details), runs through servers outside the EU before it is answered. The question itself is not 'stored' in the strict sense, but it is processed. And processing falls under GDPR.

What the law says

GDPR Art. 44-46 prohibits the transfer of personal data to countries outside the EU/EEA without a valid legal basis. The valid bases are limited and come with conditions: an adequacy decision (such as the EU-US Data Privacy Framework, which is under legal pressure), Standard Contractual Clauses (SCCs, requiring an additional risk assessment), or Binding Corporate Rules (BCRs).

For AI customer support the practical conclusion is: if your vendor has data processed in the US, always base it on the EU-US DPF, and know that if it falls away, you need an alternative within 90 days. Many CIOs and DPOs therefore demand 'EU-only processing' without transfer as a baseline.

Which level do you need?

• B2C webshop with general support questions → Level 2 is acceptable in practice.
• B2B with enterprise customers where procurement demands a DPA → Level 3.
• Healthcare, finance, public sector, higher education → Level 3 is effectively mandatory.
• Companies with a DPF allergy (often German customers, often legal teams) → Level 3 + European LLM provider (Mistral, Aleph Alpha).

How Conveya solves this

Our database, queue, file storage and API servers run in EU-Central (Amsterdam). Our standard LLM route goes through OpenAI; merchants who demand strict EU-only processing can route through CHAT_PROVIDER to a European provider (Mistral Large is the most proven EU route). At every merchant onboarding we document which route is used and which sub-processors are active, see /privacy for the current sub-processor list.