Your users are sending personal data into your LLM API right now. The customer who pasted their home address into your chatbot. The analyst who uploaded client phone numbers into your AI copilot. The employee who dropped an email thread into your internal tool. None of them thought about GDPR. You have to. Every prompt containing personal data triggers data protection obligations — and your provider’s SOC 2 doesn’t cover your liability. You need your own compliance posture: DPA, PII redaction, DSAR handling, retention policies, breach notification. This 10-point checklist covers every GDPR obligation touching LLM API usage, with regulatory references and implementation steps. For AI-specific regulation, see our EU AI Act checklist.
GDPR & LLM APIs — Where the Two Worlds Collide
GDPR applies to any organization that processes personal data of EU residents — regardless of where the organization is located. Every time your application sends user input to an LLM API, you’re processing personal data. You are the Data Controller. The API provider is the Data Processor. You’re responsible for ensuring the processing is lawful. They’re responsible for implementing appropriate technical and organizational measures.
The key GDPR principles that apply to LLM API usage: data minimization (only send what’s necessary), purpose limitation (only use the data for the specified purpose), storage limitation (don’t keep data longer than necessary), and data subject rights (users can access, correct, and delete their data).
The 10-Point Compliance Checklist
1. Data Processing Agreement (DPA)
Requirement: Article 28 of the GDPR — a written contract between controller and processor governing data processing. Action: ensure every LLM API provider you use has a signed DPA. If you use multiple providers directly, that’s multiple DPAs to manage. A unified API platform consolidates this to one DPA covering all underlying providers. Legal basis: the DPA must specify the subject matter, duration, nature, and purpose of processing.
2. Data Residency
Requirement: personal data of EU residents must be stored and processed within the EU or in jurisdictions with adequacy decisions. Action: check where your API provider processes data. US-based providers (OpenAI, Anthropic) may process data on US servers. This requires Standard Contractual Clauses (SCCs) or an adequacy decision. Some providers offer EU-only processing regions — enable this if available.
3. PII Redaction at Ingress
Requirement: data minimization — only process the personal data necessary for the purpose. Action: strip PII before it reaches any LLM. Regex patterns for structured PII (credit cards, SSNs, phone numbers). NER classifiers for unstructured PII (names, addresses in free text). PII redaction must happen before the data enters your logging pipeline — raw PII should never touch logs, traces, or eval datasets.
4. DSAR Handling
Requirement: Articles 15-22 — users can request access to, rectification of, and erasure of their personal data. Action: build the capability to: (1) locate all personal data associated with a user ID across your LLM conversation logs, (2) provide a readable export, (3) delete it on request. LLM conversation logs are personal data if they contain PII. You must be able to find and delete them.
5. Consent Management
Requirement: Article 6-7 — processing requires a lawful basis. Consent is one such basis. Action: if you rely on consent, users must explicitly agree before their data is sent to an LLM. Pre-ticked boxes don’t count. Silence doesn’t count. Implement a consent capture mechanism and record the timestamp and scope of each consent. Your API authentication layer should validate consent status before forwarding any request.
6. Data Retention Policy
Requirement: storage limitation — data must be kept “no longer than necessary.” Action: define a specific retention period for LLM conversation logs. 6-12 months is common. Implement automated deletion. Document the retention policy in your privacy notice. “We keep data as long as we need it” is not a valid retention policy.
7. Cross-Border Data Transfers
Requirement: Articles 44-49 — transfers to countries without adequacy decisions require appropriate safeguards. Action: if your API provider processes data in a non-adequate country, ensure SCCs are in place. Document the transfer mechanism. This is typically covered in the DPA — verify it.
8. Data Protection Impact Assessment (DPIA)
Requirement: Article 35 — required when processing is “likely to result in high risk” to individuals. Action: conduct a DPIA for your LLM API usage. Document: what data is processed, why it’s necessary, what risks exist, and what mitigations are in place. LLM processing — with its potential for unintended data exposure — typically triggers the DPIA requirement.
9. API Provider Compliance Documentation
Requirement: you’re responsible for your processors’ compliance. Action: collect and maintain current copies of: each provider’s DPA, SOC 2 report or equivalent security certification, data processing location documentation, and sub-processor list. Review annually. This documentation package is what you’ll show a regulator or auditor.
10. Incident Response & Breach Notification
Requirement: Articles 33-34 — notify supervisory authority within 72 hours of becoming aware of a data breach. Action: build an incident response plan that covers LLM-specific scenarios: accidental PII exposure in model outputs, training data extraction attacks, prompt injection leading to data leakage. Document the notification procedure. Test it before you need it.
How API Aggregation Affects Compliance
Using multiple LLM providers directly means managing multiple DPAs, multiple data residency configurations, multiple audit trails, and multiple breach notification procedures. Each provider adds compliance surface area.
A unified API platform consolidates this: one DPA covering all underlying providers, one data residency configuration, one audit trail across every model, one breach notification procedure. The compliance surface shrinks from O(N providers) to O(1). This is not a minor operational convenience — it’s the difference between a compliance review that takes an afternoon and one that takes a week.
Quick Self-Assessment
Answer these 10 questions. Every “no” is an action item:
- Do you have a signed DPA with every LLM API provider you use?
- Do you know where each provider processes your data geographically?
- Is PII being stripped before it reaches any LLM or log?
- Can you locate and delete all data associated with a specific user within 30 days?
- Do you capture and record user consent before sending data to an LLM?
- Do you have a defined data retention period for LLM conversations?
- Are SCCs in place for cross-border data transfers?
- Have you conducted a DPIA for your LLM API usage?
- Do you maintain current compliance documentation for every provider?
- Do you have an incident response plan that covers LLM-specific breach scenarios?
Compliance Failures That Triggered Real Penalties
GDPR enforcement is not theoretical. Regulators across the EU have issued fines ranging from five to eight figures. The thread connecting every case below: the organizations had compliance policies on paper. What they did not have was compliance in practice. Each story is anonymized but draws from actual regulatory actions and enforcement patterns documented in EDPB decisions and national DPA annual reports.
The Chatbot That Stored Everything — Forever
A European e-commerce company deployed an LLM-powered customer support chatbot. The privacy policy stated: “Chat transcripts are retained for 90 days for quality assurance purposes.” The implementation: all chat transcripts, including those containing full names, addresses, order histories, and payment references, were written to an unencrypted log table. The retention policy was a comment in a Jira ticket — not a database-level TTL, not an automated purge job, not anything that would actually delete data.
Eighteen months after launch, a customer submitted a DSAR requesting deletion of all their personal data. The company’s engineering team ran a query and discovered: (a) the logs contained 18 months of chat data, not 90 days, (b) there was no per-user identifier on log rows — transcripts were keyed by session ID, which was not linkable to user IDs without joining through three other tables, and (c) the data volume was 14 terabytes, making full-text search for individual PII instances cost-prohibitive.
The DPA fined the company 2.3 million euros — not for having a data breach, but for being unable to comply with a DSAR. The inability to delete data on request was itself the violation. The company had the policy. It had the intent. It did not have the implementation. The engineering team had treated the privacy policy as a legal document — something the lawyers write and the developers ignore. The DPA treated the gap between policy and reality as negligence.
The takeaway: retention policies that are not enforced by automated deletion are not policies. They are aspirations. Your privacy notice is a binding commitment to users and regulators. If it says 90 days, the data must be gone at 91 days — provably, auditably, automatically.
The “Anonymized” Training Data That Wasn’t
A B2B SaaS company used customer conversation data to fine-tune an LLM for their industry-specific domain model. They ran a PII scrubber over the training corpus — name detection, email regex, phone number patterns. The scrubber caught structured PII. It did not catch: “the CFO of [small regional company with 12 employees] said…” or “we need to ship to the warehouse at [specific address described as ‘the blue building behind the old train station’]” or “patient [first name] in ward [number] was prescribed…”
These indirect identifiers — small population inference, location descriptors, contextual re-identification — survived the scrubber. The fine-tuned model, when prompted with queries about industry-specific regulations, occasionally reproduced fragments of these conversations verbatim. A customer recognized their own company’s internal discussion in a model output and filed a complaint.
The DPA investigation found that consent for training data usage had been bundled into a general terms-of-service acceptance — not a separate, specific consent for AI training. The fine was 4.1 million euros. The DPA’s reasoning: “anonymization” requires that re-identification be impossible by any means reasonably likely to be used. Context-rich business communication, by its nature, contains re-identifiable information. Applying an off-the-shelf PII scrubber to domain-specific conversation data is not anonymization — it’s a privacy theater.
The takeaway: training data that contains real user conversations needs more than regex-based PII scrubbing. Differential privacy techniques, k-anonymity thresholds for rare entities, and explicit, separate consent for AI training are not optional. If you cannot guarantee re-identification is impossible, you need consent — specific, informed, and freely given. Not a checkbox inside a 40-page terms-of-service document.
The Cross-Border Transfer That Skipped the Paperwork
A mid-sized European tech company used three US-based LLM API providers. They had DPAs with all three. What they did not have: any process for verifying that the SCCs in those DPAs were still valid after the EU-US Data Privacy Framework was adopted in 2023, challenged in 2024, and partially constrained by national court rulings in 2025. The legal landscape for transatlantic data transfers had shifted three times since their last legal review. Their DPAs referenced the previous framework.
During a routine audit triggered by a separate complaint, the DPA requested documentation of the legal basis for cross-border transfers. The company could not produce current SCCs reflecting the post-Schrems III legal reality. The finding was not that data had been compromised — it was that the company could not demonstrate a lawful transfer mechanism existed at the time of processing.
The fine: 890,000 euros. Small by GDPR standards, but the operational cost was worse — the DPA imposed a 60-day suspension on processing EU personal data through any non-compliant transfer mechanism. The company had to route all LLM traffic through an EU-only processing region under an emergency migration, which took 11 days of engineering effort and caused partial service degradation throughout.
The takeaway: cross-border transfer compliance requires annual review, not a one-time checkbox. The legal mechanisms — Privacy Shield successors, SCCs, adequacy decisions — change. Your DPAs must be re-verified against the current legal framework at least annually. An expired legal basis is no legal basis.
Further reading. GDPR compliance complements our EU AI Act compliance checklist. For the API security baseline that underpins data privacy, review our API security documentation.
FAQ
My API provider already has GDPR compliance. What else do I need to do?
Their compliance covers their processing. It doesn’t cover yours. You still need: a DPA with them, a lawful basis for sending them user data, PII minimization before transmission, DSAR handling capability, a defined retention policy, and breach notification procedures. Their SOC 2 is one piece of your compliance puzzle — not the whole picture. Consolidating to a single API integration point simplifies the paperwork and reduces the number of DPAs you need to manage.
Does user input in a prompt count as “processing personal data”?
Yes. If a user types their name, email, address, or any information that can identify them — and that text is sent to an LLM API — you’re processing personal data. GDPR applies. The fact that the user voluntarily provided the information doesn’t exempt you from data protection obligations.
How do I use US-based APIs (OpenAI, Anthropic) and comply with EU data residency?
Standard Contractual Clauses (SCCs). Both OpenAI and Anthropic offer SCCs in their DPAs, providing a legal mechanism for transferring EU personal data to the US. Some providers additionally offer EU-only processing regions — if available, enable this for an additional layer of compliance. For the technical safeguards that protect API keys and access controls across provider boundaries, see our API security best practices.
How do I handle a DSAR that asks for deletion of LLM conversation data?
Locate all conversation logs associated with the requesting user’s ID. Delete them. Confirm deletion to the user within 30 days. If the data has been archived to cold storage, you may need to retrieve and delete it from there as well. This is why retention policies and data locality matter — if you don’t know where the data is, you can’t delete it on request.
What happens if I self-report a compliance gap to a DPA?
Voluntary disclosure materially reduces penalties — every EU DPA considers cooperation and proactive reporting as mitigating factors in their fining guidelines. If you discover that you have been processing data without a valid DPA, that PII has been leaking into training datasets, or that your retention deletion job has been silently failing for six months: (1) document the gap precisely — what data, what time period, how many users affected, (2) fix it immediately — don’t wait for regulatory guidance, (3) notify your DPA within 72 hours if the gap constitutes a data breach (unauthorized access, accidental disclosure), or as soon as practicable if it is a procedural compliance gap, (4) notify affected users if the gap presents risk to their rights and freedoms. Organizations that self-report and demonstrate remediation typically receive fines 40-60% lower than those discovered during an investigation. The catastrophic penalty cases you read about — the eight-figure fines — almost always involve organizations that knew about the problem and did nothing, or actively concealed it. Self-reporting is unpleasant. Getting caught hiding a compliance gap is worse by an order of magnitude. Document everything. Fix it. Tell the regulator. The regulator’s job is to enforce compliance, not to maximize fines.
GDPR compliance for LLM API usage isn’t a one-time project — it’s ongoing operational hygiene. Run through the 10-question self-assessment above. Every “no” is a compliance gap that compounds with every API call your application makes. Address them in priority order: DPA first, PII redaction second, DSAR handling third. The regulatory clock is already ticking.