Removing names before the request does not take you out of these rules. While you hold the key that links a text back to a patient, it is still personal data. So every check below applies to every request, pseudonymised or not.
Where may patient data go when our product sends it to an LLM API? The question usually arrives from a hospital or insurer customer, inside a security questionnaire. This guide follows one hypothetical request, a discharge letter sent for summarising, from your app to the model and back.
Why patient data needs a legal basis before any LLM call
Patient data needs a legal basis because the GDPR (the EU's General Data Protection Regulation) bans processing it by default. It defines data concerning health as personal data about a person's physical or mental health, including the health care they receive. A discharge letter is exactly that.
Article 9 of the GDPR prohibits processing such data unless one of its listed exceptions applies. Two exceptions matter most for products. One is the patient's explicit consent for specified purposes. The other covers processing needed for diagnosis or health care. It needs a basis in EU or national law, or a contract with a health professional. The controller relies on it, for example the hospital that treats the patient.
Which exception applies is your decision, or your customer's. An LLM provider cannot make it for you. Large-scale processing of health data also needs a data protection impact assessment (DPIA) under Article 35. A DPIA is a documented risk review done before processing starts.
We are Lyceum, a sovereign European AI inference provider for open-source models. Our serverless models run in Paris and Finland. Serverless means you call a shared model through our API and pay per token, without running servers. For a dedicated endpoint (a model on GPUs reserved for you) or a GPU virtual machine, the location is agreed per contract. For the general GDPR picture, see our guide to LLM inference under the GDPR.
What an LLM API provider must give you for health data
An LLM API provider must give you a processor contract, control over who else touches the data, and security measures. Under the GDPR, the controller decides why data is processed, and the processor processes it on the controller's behalf. A data processing agreement (DPA) is the contract that sets this up.
Article 28 adds control over subprocessors, meaning other companies the provider uses to run its service. A processor may not bring one in without the controller's written authorisation. A specific authorisation approves one named subprocessor. A general authorisation approves subprocessors in advance, so the processor must announce each change and give the controller the chance to object. Article 32 names pseudonymisation and encryption among the expected security measures.
Here is how this reads on our side, from our legal and data handling page:
- Our DPA names you the controller and us the processor.
- The DPA is Annex 1 of our terms, so it applies when you accept them.
- We tell you before we add or replace a subprocessor, and you can object within 10 business days.
- Our subprocessors are mainly in the EU and the European Economic Area (EEA). Anything outside it is covered by GDPR safeguards, such as standard contractual clauses: model contract terms adopted by the European Commission.
- Our DPA obliges us to tell you immediately about any breach involving your personal data.
If your product processes the letters for a hospital, the roles shift one step. The hospital is the controller, your product is its processor, and we are your subprocessor. Your DPA with the hospital must allow that.
Our ISO 27001:2022 audit is in progress. ISO 27001 is the international standard for managing information security. For how subprocessor lists work across providers, see the DPA question in AI inference.
Where a discharge letter goes on our API, stop by stop
A discharge letter sent to our serverless API makes four stops. The only thing we store is a usage record. The letter itself stays only in memory while the model works. Our legal page walks one prompt through them. The table follows the hypothetical letter.
| Stop | What we see | What we keep |
|---|---|---|
| Your app sends the request | Nothing yet. HTTPS encrypts the request on the way. | Nothing |
| Our gateway checks your key | Your API key, the model you asked for, and the letter passing through memory | A usage record: your organisation and user, the model, token counts and the time |
| The GPU runs the model | The letter, in GPU memory in a European data centre | Recent prompt prefixes, in GPU memory, until newer requests replace them |
| The answer streams back | The summary, as it streams to your app | The output token count, added to the usage record |
We never log the prompt text or write it to a database. A prompt prefix is the opening part of a prompt, such as your fixed instructions. It stays in GPU memory for a short time, until newer requests replace it.
That short-lived copy is what makes cached input tokens cheaper. When a later request starts with the identical text, the model reuses the work instead of reading it again. On Kimi K3 that cached part is billed at $0.75 per 1M tokens instead of $3.00. Reuse is best effort, so the price can differ from request to request.
The usage record on our legal page shows what one such request leaves behind, for the model moonshotai/kimi-k3. It holds 1,204 input tokens, of which 896 were cached, and 312 output tokens. Using our Kimi K3 page prices, read 2 November 2026, the hypothetical letter costs:
Uncached input: 1,204 - 896 = 308 tokens
308 x $3.00 / 1,000,000 = $0.000924
896 x $0.75 / 1,000,000 = $0.000672
312 x $15.00 / 1,000,000 = $0.00468
Per letter: $0.006276
20,000 letters a month (hypothetical) x $0.006276 = $125.52The record that stays holds token counts, never the letter. The example does not show your own logs, storage, support access or backups. It also does not show whether your legal basis holds.
Before the first letter goes out, check where the model runs. Each of our model pages has a Processing region field. It also tells you to check the model's processing region before sending data. The Kimi K3 page says it runs on EU-hosted infrastructure, and that we do not keep prompts or outputs or use them for training. For per-model regions in depth, see model-by-model data residency. For retention, see zero data retention in LLM inference.
Pseudonymised patient data is still personal data
Pseudonymised patient data stays personal data while someone can link it back to the patient. Article 4 of the GDPR defines pseudonymisation as processing data so it cannot be tied to a person without extra information kept separately.
Say the hypothetical product replaces the name, date of birth and insurance number with placeholders before each request. Its lookup table, which maps placeholders back to patients, stays in its own database.
The EDPB (the board of the EU's data protection authorities) still counts it as personal data. Its Guidelines 01/2025 say pseudonymised data that can be attributed to a person with additional information remains personal data. The same guidelines say lookup tables are personal data too.
So pseudonymise, because it lowers the harm if a request leaks, and run every provider check anyway.
Germany adds C5 for health data in the cloud
Germany adds a cloud rule for health data on top of the GDPR: § 393 of the German Social Code, Book V (SGB V). It covers healthcare providers, statutory health and care insurers, and the processors working for them.
They may process health data in a cloud service only when all of these hold:
- Processing happens in Germany, an EU member state, or an equivalent state. Equivalent states are the other EEA countries and Switzerland. A country outside these also qualifies if the European Commission has found its data protection adequate (an adequacy decision).
- The processing company has an establishment in Germany.
- Technical and organisational security measures meet the state of the art.
- A current C5 attestation exists for the cloud systems used. C5 is the cloud security criteria catalogue of Germany's federal IT security office (BSI).
Since 1 July 2025, "current" means a C5 Type 2 attestation. An attestation is an independent auditor's report. The BSI says auditors check whether the C5 criteria are met on the audit date. Depending on the engagement, they also check whether the criteria were met in the past. Type 2 is the second kind: the controls are tested over a period. Type 1 covers one point in time.
The law also accepts an attestation or certificate under another standard with an equivalent or higher security level. Which standards count is for the Federal Ministry of Health to set by ordinance, together with the BSI.
If your customers include German hospitals, practices or insurers, your product is their processor. Ask every provider in your chain for its current attestation before you sign.
A checklist before you send patient data to an LLM
Use this checklist before the first patient record reaches a model:
- Name the Article 9 exception your customer relies on, in writing.
- Run a DPIA if you process health data on a large scale.
- Sign a DPA with each provider, and check that your role in it matches your role towards the hospital. Read its subprocessor terms.
- Check the processing region of every model ID your code calls, and note the date you read it.
- Pseudonymise before each request, and keep the lookup table in your own systems.
- For German health customers, collect each provider's current C5 Type 2 attestation.
If any item stays open, keep patient data out of the request until it is closed. If you need a fixed EU location for a dedicated deployment, tell us the workload and talk to our engineers.
Frequently asked questions
Is a pseudonymised discharge letter still health data?
Yes. If your system keeps the lookup table, the text you send remains personal data about health.
Can we rule out one of your subprocessors?
Yes. Which subprocessors apply depends on the service you choose, so your choice of service can rule one out. You can also ask us for the full list.