Read the exact clause before you pick an architecture. A clause that says "EU" or "EEA" (the EU plus Iceland, Liechtenstein and Norway) fits a shared API in EU data centres. Only a clause that names Germany forces you onto reserved capacity. In that case, write the location into the contract, because a web page can change.
Can you use a serverless LLM API if your customer says the data must stay in Germany? The question comes up when a German client, a tender or an internal policy adds one line to an AI project. This guide reads that line closely and follows one hypothetical assistant through both answers.
We are Lyceum, a sovereign European AI inference provider for open-source models. Our serverless models run in Paris and Finland. The location of dedicated endpoints and rented GPU machines (VMs) is agreed per contract. Serverless means you call a model through our API and pay per token, while we run the servers.
Germany-only and EU-only are different requirements
The two rules sound alike, but they lead to different setups. An EU rule accepts a server in any EU member state. A Germany-only rule accepts one country.
That difference decides the architecture. A shared API runs each model on a pool of GPUs that serves many customers at once. The provider places that pool where it has capacity. Ours sits in two countries, and neither is Germany.
A dedicated endpoint works differently. It is a copy of a model running on GPUs reserved for you alone. Its location can be part of the agreement. So the clause, not the model or the price, is the first thing to read.
The word "Germany" in a clause does not say why the customer wrote it. It can be a hard requirement from a public body. It can also be shorthand for "not outside Europe". Ask before you design around it.
EU law does not tie processing to one member state
EU data protection law treats the EU as one area. The GDPR is the EU's General Data Protection Regulation. It says the free movement of personal data within the Union may not be restricted or prohibited for data protection reasons. Moving a prompt from Berlin to Paris is not a transfer in the GDPR's sense.
The strict rules apply further out. A third country is a country outside the EU. A transfer there may take place only under the conditions of Chapter V, the GDPR's rules for transfers abroad. That is where the real legal work sits, and it concerns countries such as the US, not France or Finland.
Non-personal data follows the same idea. The European Commission says every organisation should be able to store and process data anywhere in the EU.
So the GDPR itself does not ask you to keep data in Germany. A Germany-only rule comes from somewhere else: the customer's contract, a tender or a sector policy. That source decides whether the rule can bend. This article is not legal advice. Your legal team still decides what your setup needs. For checks that German enterprises run on top of this, see what to check in a sovereign LLM API for German enterprises. Public-sector projects can add more checks, such as C5, a German catalogue of cloud security criteria. See C5 requirements for LLM APIs in German public-sector projects.
Where our serverless models run today
Our serverless models run in Paris and Finland, as our homepage states. That meets a clause that says EU. It does not meet a clause that says Germany, and we will not tell you otherwise.
What happens to the prompt matters as much as where it goes. We never log your prompts and responses or write them to a database. Some companies run parts of the service for us, such as payments or GPU capacity. Data protection law calls them subprocessors. They sit mainly in the EU and the EEA. Anything outside is covered by GDPR safeguards such as standard contractual clauses, which are EU-approved contract terms for data sent abroad. Which of these companies work on your data depends on the service you use. You can also object to a new one within 10 business days of our notice.
For a dedicated endpoint, we agree the data centre for your workload. You can tell us if you need a specific EU location. Some providers state a processing region on each model's page. Model-by-model data residency shows how to check every model you call.
One assistant, two readings of the clause
Take a hypothetical example. A consultancy builds an HR assistant for a German client. It runs on weekdays from 08:00 to 18:00, on 22 working days a month. It uses GLM-5.3, an open model from Z.ai that we serve. It reads 40 million input tokens and writes 8 million output tokens a month. A token is a piece of a word, and providers bill per token.
Reading A: the clause says EU. The assistant can use our serverless API. GLM-5.3 costs $1.40 per 1M input tokens and $4.40 per 1M output tokens, list prices read on 6 November 2026.
Input: 40 × $1.40 = $56.00
Output: 8 × $4.40 = $35.20
Total per month = $91.20Per-token billing follows traffic. Nights and weekends cost nothing, because no tokens are sent.
Reading B: the clause says Germany. The assistant needs a dedicated endpoint in an agreed location. Here the bill does not follow tokens. A replica is one running copy of the model on its own GPUs. A dedicated deployment is billed for the time its replicas are running, not per request.
A dedicated endpoint is billed for its running time
Running time is the number to watch. Kept on all month, one replica runs 720 hours. Our dedicated deployments pause after one hour without requests, which stops billing for idle replicas.
For the HR assistant, that pause changes the count. The replica runs for the 10 working hours, then one more idle hour before it pauses.
Always on: 24 h × 30 days = 720 replica-hours
Paused when idle: 11 h × 22 days = 242 replica-hours
Share of always-on: 242 / 720 = about 34%The pause has a cost of its own. The first request after a pause is slower while the replicas start up. If the first employee logs in at 08:00, that first answer waits. Warm the endpoint with a request a few minutes earlier, or accept the slow start.
Two assumptions in the example favour the dedicated side. Its traffic is a steady office-hours pattern, so the endpoint can pause for the rest of the day. And one replica is assumed to be enough. The example also leaves three things out. It shows no dedicated price, because that is agreed per contract. It does not size the GPUs the workload needs, and it does not show whether a German location is available for it. For the cost choice in depth, see serverless vs dedicated inference costs.
Four questions to settle before you sign
Settle these with your customer first, then with the provider. Each one can change the architecture.
- Does the clause say Germany, the EU or the EEA? Ask for the exact sentence and who wrote it. An EU clause opens the shared API route.
- What does it cover? Prompts are one thing. Logs, backups and the support staff who can see your data are others, and each can sit somewhere else.
- Which companies handle the data, and where? A provider's own servers can be in one country while a company it uses sits in another. Ask for the list.
- Is the location in the contract? A web page can change. A contract clause is what your customer's auditor will ask to see.
If the answers point to the EU, start on serverless and pay per token. If they point to Germany, bring the clause and your traffic pattern to a provider that can put a location in writing.
Bring the exact clause and your traffic hours to a call with our engineers. We will tell you which location and capacity we can agree for your endpoint.
Frequently asked questions
Is Germany-only processing required by the GDPR?
No. The GDPR lets personal data move freely within the EU. A Germany-only rule comes from a contract, a tender or a sector policy, so ask who set it.
Does a dedicated endpoint cost money while nobody uses it?
Only for a while. A deployment that receives no requests for one hour pauses and stops billing for idle replicas. The next request wakes it, and that first answer is slower.