Sign only when the provider answers four questions in writing:
- Where are requests processed?
- Who are its subprocessors, the companies that run part of the service for it?
- Are prompts used to train models?
- What does each request leave behind, such as logs or usage records?
Does our LLM API have to run in Germany, and what will our DPO and works council ask before we sign? It comes up once an LLM API moves from a test account into your product. Your data protection officer (DPO) checks the GDPR side. Your works council (Betriebsrat), the body that represents employees, checks how the tool affects staff.
We are Lyceum, a sovereign European AI inference provider for open-source models. Our serverless models, the shared models you call through our API and pay for per token, run in Paris and Finland. This guide gives our answer to each point of the German review. It is not legal advice.
Germany or the EU: where a German company's LLM API may run
A German company's LLM API may run in any EU or EEA country, as far as the location rules of data protection go. The German Federal Data Protection Act (BDSG) gives the EEA states equal status with EU member states. All other states are third countries.
Personal data may leave the EEA only under the conditions of Chapter V of the GDPR, the chapter on international transfers. The European Data Protection Board (EDPB), the body of EU data protection authorities, describes when a transfer happens. A transfer happens when a provider covered by the GDPR makes personal data available to an organisation in a country outside the EEA.
So ask two questions instead of "is it in Germany?". Where are requests processed? And which organisation outside the EEA could receive the data? A German data centre answers neither on its own.
Our answer to the first: our serverless models run in Paris and Finland. For dedicated endpoints (GPUs reserved for one customer) and GPU virtual machines, the location is agreed per contract. For a dedicated endpoint, tell us if you need a specific EU location. The second question, who outside the EEA could receive data, is answered by the contract and its subprocessors. The checks behind the sovereign label itself are covered in what the sovereign label must prove.
The AVV comes with a German-law contract
The DSK, the conference of Germany's independent federal and state data protection authorities, published its guidance on AI and data protection on 6 May 2024. It says that a company using a provider's AI application as a cloud solution often has a processing relationship with it. An agreement under Article 28(3) GDPR must then be concluded.
That agreement is the data processing agreement (DPA), called AVV (Auftragsverarbeitungsvertrag) in German. In it, you are the controller, the party that decides why data is processed. We are the processor, the party that processes it on your instructions.
Our terms govern contracts between Lyceum Technology Germany GmbH and its commercial customers. The company is registered at the District Court of Charlottenburg in Berlin. The contract is subject to German law, and the exclusive place of jurisdiction is our registered office. The AVV is Annex 1 of our terms.
The AVV also governs subprocessors. Article 28(2) GDPR says a processor may not engage another processor without the controller's prior specific or general written authorisation. Our subprocessors are mainly in the EU and the EEA. Anything outside is covered by the GDPR's safeguards, such as standard contractual clauses, the EU's model contract for transfers. We tell you before we add or replace a subprocessor, so you can object. We cover the wider question in sub-processors in AI inference.
Training, prompt logs and what your DPIA needs
The DSK tells approvers to check whether input and output data are used for training. Applications that do not use them for training are preferable, it says. Our answer: prompts and outputs are processed, not stored, and never used for training. Nothing is written to disk. The one thing held briefly is the cache shown in the table below.
The second check is about information. A data protection impact assessment (DPIA) is the risk assessment the GDPR requires before processing that is likely to be high-risk. The DSK says a company relies on the provider's information on how the system works to do it. So check at selection that the provider supplies that information.
Our legal page traces one request through our serverless API:
| Stop | What we keep | What we don't keep |
|---|---|---|
| Our gateway, the server that receives your API call, checks your key | A usage record: your organisation and user, the model, token counts and the time | Your prompt text. We never log it or write it to a database |
| The GPU runs the model | The opening part of recent prompts (prompt prefixes), in GPU memory, until newer requests replace them | Your prompt, on disk or in a database |
| The answer streams back | The output token count, added to the usage record | The response text |
The middle row belongs in your DPIA's description of the data flow. The opening part of recent prompts stays in GPU memory until newer requests replace it. We call this the cache: it lets a repeated prompt start be reused, and it is never written to disk. Whether you need a DPIA at all is covered in a DPIA for LLM inference.
What the DPO and works council see in a pilot
The DSK says DPOs should always be involved when decisions on AI applications are prepared or made. Involving works councils should be considered too. In some cases, introducing an AI application triggers the works council's co-determination right, its right to agree before the tool is used.
The legal hook is section 87(1) no. 6 of the Works Constitution Act. It covers technical devices designed to monitor the behaviour or performance of employees. The DSK adds a practical rule for cloud tools. Accounts should not carry individual employees' names, and a functional company email address should be used.
A small pilot shows both reviewers what they will see. Take a hypothetical one: your support tool summarises 500 invented test tickets. Each ticket is 2,000 input tokens, and each summary is 300 output tokens. A token is the unit a model reads and bills by, roughly a word or part of one. The pilot runs on Qwen3.8-27B, at its list price on 23 October 2026: $0.40 per 1M input tokens and $2.40 per 1M output tokens.
input: 500 requests x 2,000 tokens = 1,000,000 tokens x $0.40 per 1M = $0.40
output: 500 requests x 300 tokens = 150,000 tokens x $2.40 per 1M = $0.36
total: $0.76A review pilot costs less than a dollar in tokens, so we recommend running it before the works council meeting, not after. Each approver gets something different from it:
- Your DPO gets 500 usage records, and none of them holds prompt or response text.
- Your works council sees our dashboard's Serverless usage panel. It shows input tokens, output tokens and cached tokens (input reused from the cache) per model, per member and per API key. Run the pilot under one API key for the support tool, owned by a functional account. The panel then shows the tool, not a person.
- Your legal team finds the AVV already in the terms it reviews.
The pilot is easier than real use in one way: its test tickets hold no personal data. It does not show whether your company needs a DPIA, or whether your works council agrees. Whether co-determination applies is for you and your works council to settle. We collected their usual questions in what a works council and DPO ask.
Documents to collect before you sign
Before you sign, hand your DPO five documents from the provider:
- The AVV, with the controller and processor roles.
- The subprocessor list, with locations.
- The technical and organisational measures (TOMs), the provider's security controls.
- The security status: certifications held and audits in progress.
- The incident route: how you hear about a breach or an outage.
Our side of that list sits on our legal page. The DPA, the TOMs and the subprocessor list are one click each. Our other documents sit in our compliance platform. Under our DPA you can instruct us in writing at any time, audit us with notice, and choose deletion or return when you leave. Our DPA obliges us to tell you immediately about any breach involving your personal data. Service incidents appear on our status page.
If a provider can hand over the five documents and answer the four questions above in writing, your approvers have what they need to decide. Send our legal page to your DPO, or bring your review questions to our compliance team: review our legal documents.