Privacy and compliance
9 min read10 questionsEU AI Act and GDPR for LLM apps: a compliance checklist for choosing an inference provider
If your product sends prompts to a language model through an API, two European regulations shape what you have to check: the GDPR, as soon as a prompt carries personal data, and the AI Act, depending on what your app does. This is what each one asks of you, when it applies, and the questions to put to any inference provider before you send it real data.
GPU Flow team. Published on 9 November 2026.
Not legal advice
This article summarises public rules and explains how our own service works. It is not legal advice: how your system is classified under the AI Act and which legal bases you rely on under the GDPR depend on your use case. Check them with your data protection officer or a lawyer.
Which EU rules apply when your app calls an LLM API?
Two regulations do most of the work. The General Data Protection Regulation (Regulation (EU) 2016/679) applies whenever you process personal data, and a prompt is processing: a support ticket pasted into a chat, a CV sent for screening, a call transcript sent for a summary. It does not care that the processing is done by a model.
The AI Act (Regulation (EU) 2024/1689) regulates AI systems and general-purpose AI models. What it asks of you depends on two things: your role (provider or deployer) and what the system is used for (prohibited, high-risk, subject to transparency duties, or none of those). Many LLM apps land in the transparency tier, not the high-risk one, but a few common uses do not.
The inference provider sits in the middle of both. It receives the personal data in your prompts, it serves models whose documentation you may need, and the way it stores and logs requests becomes part of your own compliance file.
EU AI Act timeline: what applies and when
The AI Act entered into force in 2024 and applies in stages. In 2026 the Digital Omnibus on AI moved the high-risk deadlines back; the European Commission says it entered into force on 27 July 2026. This is the calendar as the Commission publishes it today:
| Date | What starts to apply | Where |
|---|---|---|
| 1 August 2024 | The AI Act enters into force | Regulation (EU) 2024/1689 |
| 2 February 2025 | Prohibited AI practices and AI literacy | Articles 4 and 5 |
| 2 August 2025 | Obligations for providers of general-purpose AI models, and the governance rules | Chapters V and VII |
| 2 August 2026 | Most of the remaining rules, including the transparency obligations; enforcement starts | Article 50 and Article 113 |
| 2 December 2026 | Deadline for some generative systems already on the market to mark their output; new bans on non-consensual sexual deepfakes and child sexual abuse material | Article 50(2), as amended by the Omnibus |
| 2 December 2027 | High-risk rules for the use cases listed in Annex III | Annex III |
| 2 August 2028 | High-risk rules for AI built into products covered by EU product law | Annex I |
Dates from the European Commission, checked on 9 November 2026. They include the changes made by the Digital Omnibus on AI. Sources: digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai, ai-act-service-desk.ec.europa.eu/en/ai-act/timeline/timeline-implementation-eu-ai-act, eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R1689, eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:L_202601744
Provider or deployer: where an LLM app usually sits
The AI Act separates the provider, who develops an AI system or model and places it on the market under its own name, from the deployer, who uses an AI system under its own authority (Article 3). The obligations for general-purpose AI models in Chapter V, such as technical documentation and a copyright policy, fall on the provider of the model: usually the lab that trains and publishes it, not the company that only serves it or calls it through an API.
If you build a chatbot on top of a model and offer it to customers under your brand, you are normally the provider of that AI system. If you use an AI tool internally, you are its deployer. Either way, Article 4 asks both providers and deployers to make sure the people who operate the system have enough AI literacy.
Article 50 is the part most LLM apps meet first. Providers must design systems that talk to people so that those people know they are dealing with an AI, unless it is obvious. Providers of systems that generate synthetic audio, images, video or text must mark the output in a machine-readable format. Deployers must disclose deepfakes, and AI-generated text published to inform the public on matters of public interest unless a person reviewed it and holds editorial responsibility.
High-risk is about the use, not the model. If your app helps decide on hiring, access to education, creditworthiness or access to essential services, among the other areas in Annex III, you are in high-risk territory from 2 December 2027, with obligations on risk management, logging, human oversight and documentation.
Article 50 as summarised by the Commission's AI Act Service Desk, checked on 9 November 2026. Source: ai-act-service-desk.ec.europa.eu/en/ai-act/article-50
GDPR for AI apps: the articles that matter when prompts carry personal data
Under the GDPR you are usually the controller of what goes into your prompts, and the inference provider acts as your processor for that content. That relationship, and the rules around it, decide most of what you need from a provider:
| GDPR article | What it asks of you | What to ask the provider |
|---|---|---|
| Article 5 | Send only the personal data the task needs, and keep it no longer than necessary | Do you store prompts and outputs, and for how long? |
| Article 28 | A written contract with every processor, with the terms the article lists | Which contract covers my prompts, and which other companies take part in serving them? |
| Article 30 | A record of your processing activities | What exactly do you log about each request? |
| Article 32 | Security appropriate to the risk | Which certifications do you hold, and can I see them? |
| Article 33 | Tell the authority about a breach within 72 hours of becoming aware of it | How and how fast will you tell me about a breach? |
| Article 35 | A data protection impact assessment when the processing is likely to be high risk, especially with new technologies | Can you give me the facts my assessment needs? |
| Articles 44 to 49 | A valid legal mechanism for any personal data sent to a country outside the EEA | Where is each model served, model by model? |
Regulation (EU) 2016/679, consolidated text on EUR-Lex. Source: eur-lex.europa.eu/eli/reg/2016/679/oj
The checklist: 10 questions to ask an inference provider
Put these in writing before you send production data, and keep the answers in your compliance file. A provider that cannot answer one of them clearly has told you something too.
- 1Do you store the content of my prompts and the model outputs? If some kinds of content are stored, which ones, and why?
- 2Is anything I send used to train or fine-tune a model, yours or anyone else’s?
- 3What do you log about each request (identifiers, token counts, IP addresses), who can read it and what is it for?
- 4Where is each model served? Ask model by model: one catalogue can run in more than one place, and a single model served elsewhere changes your assessment.
- 5Which contract governs my prompts under Article 28 of the GDPR, and who is the controller of my account data?
- 6Which security certifications do you hold, issued by whom, and where can I download the certificates?
- 7How will you notify me of a security incident that affects my data?
- 8Can I see the model card and the licence of every model I use? You will need them for your own documentation under the AI Act.
- 9Does the API mark generated content in any way? If your app generates synthetic text, audio or images, Article 50(2) makes the marking your job as provider of the system.
- 10Where is the company that runs the service established, and which supervisory authority oversees it?
How this works on GPU Flow
These are our answers to the questions above that we can answer in one line. They describe the service as it runs today, 9 November 2026.
| Question | GPU Flow |
|---|---|
| Prompts and outputs | On our infrastructure we do not store the content of text, transcription or voice requests: it is processed in memory and returned in the same call. The exception is music, which is generated asynchronously, so we keep the lyrics, the description and the song for you to collect. |
| Training | Nothing you send is used to train any model. |
| Logs | We keep usage metadata for each request (request id, a hash of your API key, model, tokens or units, cost and time) to bill you and enforce rate limits. Technical logs never contain the request body or your key. |
| Where it runs | Sandboxes and dedicated GPUs run on our machines in Spain. GLM 5.3 is served outside our cluster, in the United States. Each model page says where that model runs. |
| Certifications | ISO/IEC 27001:2022 and the Spanish National Security Framework (ENS), medium category. The certificates can be downloaded from the footer of our site. |
| Company and authority | The service is run by a company established in Granada, Spain, and the Spanish Data Protection Agency (AEPD) is the supervisory authority. |
| Incidents | Our security policy sets out a documented incident procedure, with notification to the AEPD within 72 hours when personal data is affected, and to the people concerned when required. |
What we do not promise
We do not offer a guarantee that every API request is handled inside the EEA. GLM 5.3 is served outside our cluster, in the United States, so personal data you send to it goes there and is handled by that infrastructure; if your impact assessment rules that out, leave that model out of any flow that carries personal data.
We also do not publish retention periods that are not fixed yet, and we do not promise that the API marks generated content. If a question on your checklist is not answered on this page, ask us before you rely on an assumption.
The details are in our security policy and our privacy policy, which also explains how to exercise your GDPR rights.
What stays on your side
Choosing a provider does not finish the job. Some of the most common gaps sit in your own application, whoever serves the model:
- 1Your own logs. Many apps store every prompt and answer in their own database or observability tool. A provider that keeps no content does not help if you do.
- 2Data minimisation. Strip names, emails and identifiers from prompts when the task does not need them.
- 3Telling users they are talking to an AI, and marking synthetic content, under Article 50.
- 4AI literacy for the people who build and run the system, under Article 4.
- 5Your record of processing and, where needed, an impact assessment that names the provider and the models you use.
- 6Checking whether your use case falls under Annex III before 2 December 2027.
Check our answers against your checklist
Read how we handle security, then try Token Factory, our OpenAI-compatible API for open-source models, with the model that fits your assessment.
Related
- Migrate from the OpenAI API to an open-source alternative in 15 minutes (code included)Move from the OpenAI SDK to GPU Flow in five steps: change the base URL, pick the equivalent model and keep streaming, tools and reasoning.
- An OpenAI API alternative: GPU Flow vs OpenAIPrice per million tokens, audio, migration and when to stay on OpenAI, with their prices checked on their own site.