A European region alone does not settle a deal review. Before a pilot, get two answers in writing: what each request leaves behind, and how the provider tells you about new subprocessors. A subprocessor is another company that handles part of the service for your provider.
So how do you get an LLM project past an EU data review without stalling the deal? The question usually arrives with a customer's security questionnaire. Sometimes your own legal team asks it first.
Three separate questions sit behind that review. Each one is answered by a different document.
| Check | What the reviewer wants to know | Where the answer sits |
|---|---|---|
| Data location | Where prompts are processed, and who else handles them | The provider's data-handling page and subprocessor list |
| Contract | What the provider commits to in writing | The DPA and the TOMs |
| AI Act | Which duties fall on your use | Your own use case, read against the Act |
TOMs are the technical and organisational measures: the security controls a provider commits to. The steps below follow the table in order. Each one ends with the articles that answer it in depth.
We are Lyceum, a sovereign European AI inference provider for open-source models. Our serverless models, which you call per request without running servers, run in Paris and Finland. Prompts and outputs are processed, not stored, and never used for training. Our legal and data-handling page shows what that means for one request.
Step 1: Find out where your prompts are processed
Data location comes first, because it decides whether personal data leaves the EU at all. The GDPR is the EU's data protection law. Under it, a transfer to a country outside the EU needs a legal ground. Standard contractual clauses, model contract terms pre-approved by the European Commission, are one such ground.
A region label does not show what happens inside one request. Our legal page traces a serverless request through four stops and says what we keep at each.
| Stop | What we keep |
|---|---|
| Your app sends the request | Nothing |
| Our gateway checks your API key | A usage record: your organisation and user, the model, token counts and the time |
| The model runs on a GPU | Recent prompt prefixes, in GPU memory, until newer requests replace them |
| The answer streams back | The output token count, added to the usage record |
The usage record never contains your prompt or the response. We keep it to bill you and run the service. A prompt prefix is the opening part of a prompt, such as a fixed system prompt. We hold recent prefixes only in GPU memory as a cache, never on disk or in a database. Newer requests overwrite them. Reusing a held prefix is what makes cached input, the repeated part of a prompt, cheaper.
Location also covers the companies behind the provider. Our subprocessors are mainly in the EU and the European Economic Area (EEA). Subprocessors outside the EU and the EEA are covered by the GDPR's safeguards, such as standard contractual clauses.
Before you move on, have two answers in writing:
- What one request leaves behind at each stop, and for how long.
- Where each subprocessor sits, and which safeguard covers any outside the EU and the EEA.
The articles in this step help when a customer asks where data is processed. Start with AI data residency, explained properly and which open-weight models are hosted in Europe, and where. If you use a US provider today, read whether a US-based AI API can work under GDPR. Then read what an EU region of a US cloud leaves open. For training data, see where third-country risk bites. Why an EU region is not enough covers what a hosting location cannot prove.
Step 2: Get the provider's commitments in writing
The contract check asks what the provider promises in writing, not on its website. Under our DPA, you are the controller and we are the processor. The controller decides what is processed and why. The processor handles the data on the controller's behalf.
GDPR Article 28 sets the rules for that relationship. A controller may use only processors that give sufficient guarantees of appropriate technical and organisational measures. A processor may not bring in another processor without the controller's written authorisation. A general authorisation is a standing written permission to use subprocessors, instead of approving each one. Under it, the processor must announce each new or replaced subprocessor, so the controller can object.
Our terms put this in writing:
- Our 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.
- Which subprocessors apply depends on the service you choose.
- Our DPA obliges us to tell you immediately about any breach involving your personal data.
- Our ISO 27001:2022 audit is in progress. ISO 27001 is the international standard for managing information security.
The objection window is where a deal can slip without anyone noticing. Here is the count for a notice on a hypothetical date.
Notice arrives: Monday 2 November 2026 (hypothetical)
Business days: Monday to Friday, no public holidays assumed
Days counted: 3, 4, 5, 6, 9, 10, 11, 12, 13, 16 November
Last day to object: Monday 16 November 2026Ten business days come to two calendar weeks in this example. If the notice lands in an inbox nobody reads, the window closes unseen. The example assumes no public holidays. It does not show how your contract counts holidays, or what happens after an objection.
Before you move on:
- Get the DPA and the TOMs, and check what they commit to.
- Name one person who reads every subprocessor notice and tracks the objection window.
- Check how and when the provider must tell you about a breach.
Turn to these when legal asks for the DPA or a security review is due. The DPA question explains subprocessor terms in AI inference. For retention, read how to verify zero data retention and what GDPR actually requires of it. Before a proof of concept, use the DPA, NDA and customer-data checklist. For the review itself, see passing an internal security review and the deal-risk checklist for an EU provider. To compare providers, read EU-hosted LLM API providers compared. Two articles test a "sovereign" label, a claim of European control: how to vet a sovereign cloud claim and what the label must prove. C5 is a German government catalogue of cloud security criteria. For public-sector bids in Germany, read what C5 requires of LLM APIs.
Step 3: Work out your duties under the AI Act
The AI Act sets risk-based rules for AI developers and deployers regarding specific uses of AI. It gives the two roles different duties. A provider builds an AI system and puts it on the market. A deployer uses an AI system in its own product or process. Once a system is on the market, deployers ensure human oversight and monitoring, and providers run post-market monitoring.
To pick your role, ask one question: did you build the system you offer, or are you using one someone else built? A team that calls a hosted model inside its product answers the second way. Fine-tuning a model and passing it on can change the answer.
The use case decides the risk level. The European Commission lists CV-sorting software for recruitment and credit scoring among the high-risk examples. A support chatbot answering order questions sits in a different place than a tool that ranks job applicants.
Before you build:
- Decide whether you are the provider or the deployer of your AI system.
- Check your use case against the high-risk uses in Annex III.
- If you fine-tune a model and pass it on, check whether that makes you a provider.
The articles below matter most when your product makes or supports decisions about people. Start with provider or deployer: AI Act roles for inference. Then work through the developer compliance checklist and the high-risk decision tree. It walks through Annex III, the part of the Act that lists high-risk uses. For records, read deployer logging under Article 26 and tamper-evident audit trails. A DPIA, a data protection impact assessment under the GDPR, is covered in do you need a DPIA for LLM inference. If you train your own variant, read whether fine-tuning makes you a GPAI provider, meaning a provider of a general-purpose AI model. The Annex IV documentation checklist and marking outputs under Article 50 cover documentation and labelling. Legal teams can start with what to verify before using an LLM API on legal documents.
Where to start, by situation
Start with the check your reviewer named. The four situations below are common starting points.
- A customer asks where data is processed. Send them our legal page and read AI data residency, explained properly.
- Legal asks for the DPA and subprocessors. Request the list, then read the DPA question.
- Your use case might be high-risk. Work through the high-risk decision tree before you build.
- You are bidding on a German public-sector project. Start with what C5 requires of LLM APIs.
If a review is blocking a deal today, answer the location and contract questions in one message. Get the DPA, the TOMs and the subprocessor list from our legal page.