Sending personal data to an LLM API in a trial already counts as processing under the GDPR, the EU data protection law. Under the GDPR the provider then acts as your processor, and a processor works under a contract. So that contract has to exist before the first request, not after the trial.
What contracts do we need before sending customer data to an LLM API? The question usually reaches an engineering lead in the week the trial should start. The answer decides whether it can. With Lyceum, the contract does not hold the trial up. Our DPA is part of our terms, so it applies the moment you accept them, trials included.
Define the data and roles before the first request
A PoC (proof of concept, a small trial) needs a dataset, and the dataset decides the paperwork. Our hypothetical PoC: your team wants to test summarising 5,000 support tickets, each with six fields.
| Field | Personal data? | Why |
|---|---|---|
| Customer name | Yes | It identifies a person directly. |
| Email address | Yes | It identifies a person directly. |
| Order number | Yes | Your order system ties it to one customer. |
| Ticket text | Often | Customers write names, addresses and order details in free text. |
| Product | Not alone | It names no one, but next to the fields above it can point to a customer. |
| Date | Not alone | It names no one, but next to the fields above it can point to a customer. |
Personal data means any information that relates to an identifiable person. Three fields are personal data and the ticket text often is too, so the PoC processes personal data on its first request. The table is an illustration, not a legal assessment of a real dataset. Your legal team decides how to classify the real one.
The GDPR also gives the two sides names. You are the controller, the party that decides why and how the data is processed. The API provider is the processor, the party that processes it on your behalf. The European Data Protection Board publishes guidelines on both roles, its Guidelines 07/2020.
Put the processing agreement in place
Article 28 of the GDPR says processing by a processor must be governed by a binding contract. That contract is the DPA. It must be in writing, and electronic form counts, so it does not need a separate paper signature.
Article 28 lists what the DPA has to cover. For the ticket PoC, check that the contract covers these seven points from Article 28:
- Instructions: the provider processes the tickets only on your documented instructions.
- Confidentiality: the people who handle the data have committed to keep it confidential.
- Security: the provider applies security measures suited to the risk.
- Subprocessors: the provider hires other companies only on the terms the contract sets.
- Assistance: the provider helps you answer requests from the people in your tickets.
- Deletion or return: at the end, the provider deletes or returns the data, as you choose.
- Audits: the provider gives you the information to show compliance and allows audits.
We run this at Lyceum, a sovereign European AI inference provider for open-source models. Our serverless models run in Paris and Finland, and our Trust page links the DPA, which you can read before you accept anything. Our DPA is Annex 1 of our terms, so it forms part of them, applies when you accept them and needs no separate signature. Under it you are the controller and we are the processor.
You can instruct us in writing at any time, audit us with notice and choose deletion or return when you leave. We tell you immediately about any breach involving your personal data. Our terms also apply during any trial period.
Send any changes your legal team wants to our compliance team through the Trust page. We promise none in advance.
Check what confidentiality terms add
An NDA and a DPA answer different questions. The DPA covers the Article 28 terms for personal data. An NDA covers confidential business information, whether or not it is personal.
Article 28 only asks that the staff handling personal data keep it confidential. Your tickets may also hold other secrets, such as an unreleased product name or a pricing exception.
Section 18 of our terms already makes both sides treat confidential information and trade secrets as confidential. Check whether that wording is enough for your tickets. If your legal team wants a separate NDA, take it to our compliance team. We do not promise a custom NDA in advance.
Review subprocessors, transfers and security together
A subprocessor is a company the provider hires to run part of the service, such as GPU capacity or payments. Article 28 says a processor needs your written authorisation before it engages one. That can be one approval per subprocessor, or a general approval with notice of changes and a right to object.
We tell you before we add or replace a subprocessor, and you can object within 10 business days of our notice. Our subprocessors are mainly in the EU and the EEA (the European Economic Area, the EU plus Iceland, Liechtenstein and Norway). The list is available by email through our Trust page.
Sending data outside the EEA is called a transfer to a third country, and the GDPR sets conditions for it. A common safeguard is standard contractual clauses (SCCs), model contract terms, pre-approved by the European Commission, that give appropriate data protection safeguards. Ask which safeguard covers each subprocessor outside the EEA.
Then look at security. The provider describes its security in its technical and organisational measures (TOMs), a written list of its security controls. We make our TOMs available on request, and our Trust page describes how serverless text is handled:
- Prompts and outputs are processed, not stored, and never used for training.
- Our only record of a request is a usage record: your organisation and user, the model, token counts and the time. It never holds the prompt or the response.
- The start of recent prompts stays in GPU memory as a temporary copy, which speeds up later requests, until newer requests replace it. Nothing is written to disk or a database.
Not storing the text does not remove the need for a contract, because the model still reads your tickets to answer them.
Approve the dataset and safeguards for the PoC
The DPA is one part of the approval, not all of it. The GDPR separately requires a lawful basis (Article 6), a legal reason such as consent or a contract. It also requires security measures that fit the risk. Your legal team owns both decisions.
While approval is pending, start with synthetic data, meaning invented records that look real. Properly anonymised data, where nobody can be identified any more, also works. In the example, send 200 invented tickets first. Pseudonymised data, where names are replaced by codes, is still personal data. It stays under the same rules.
Work through this checklist of seven steps for the ticket PoC, in order:
- List the six fields and mark which are personal data.
- Confirm your lawful basis and who in your company is the controller.
- Read the DPA and check the seven points above.
- Request the subprocessor list and note the 10-business-day objection window.
- Request the TOMs and check them against your security policy.
- Decide whether the tickets need an NDA on top.
- Send the first request with synthetic tickets. Switch to real tickets once steps 1 to 6 pass.
Serverless inference is pay as you go with no commitment, so the synthetic run costs little. If every step passes, load the 5,000 real tickets. If one of steps 1 to 6 fails, stay on synthetic data until it is fixed.
Bring your PoC data scope and contract questions to our compliance team through our Trust page.