AI API and GDPR: A Practical Compliance Checklist for Developers

Every prompt your application sends to an LLM API is data processing under the GDPR. If that prompt contains a name, an email, a medical condition, a purchase history, or any other personal data — and prompts almost always do — then your company is a controller (or processor) engaging a third-party processor (the model provider), and the entire GDPR machinery applies: legal basis, transparency, data minimization, processor agreements, data subject rights, cross-border transfer rules, and retention limits. Most AI teams discover this after a Data Subject Access Request (DSAR) lands, or when a European customer asks where their data is stored. This guide is a practical, developer-focused compliance checklist: what the GDPR actually requires when you build on AI APIs, and how to implement each requirement without a legal team on retainer.

Is the GDPR Your Problem? Territorial Scope in Plain Terms

The GDPR applies if you process personal data of people in the EU/EEA — regardless of where your company is incorporated. Two provisions matter most:

• Article 3(1) — establishment: if your company has any EU presence, the GDPR applies to all your processing, including AI features.
• Article 3(2) — targeting: even with no EU establishment, the GDPR applies if you offer goods or services to people in the EU (an English-language SaaS with EU customers qualifies) or monitor their behavior.

The practical test for an AI application: do you have users who can be located in the EU? Then assume the GDPR applies and build for it — the cost of compliance is a few engineering habits, while the cost of non-compliance starts at 4% of global turnover or €20M, whichever is higher. Note also that "personal data" is broad: names, emails, IP addresses, chat histories, behavioral profiles, and anything that identifies a natural person. Free-text prompts are personal data the moment they contain identifiable information, which means most conversational AI is in scope by default.

Data Minimization: The First Line of Defense

Article 5(1)(c) requires that you process only the personal data adequate, relevant, and limited to what is necessary. For AI APIs this translates into three concrete practices:

• Strip PII before it reaches the model. The model does not need the user's real name, email, or national ID to answer most queries. Redact, pseudonymize, or replace identifiers with placeholders before sending, and de-redact on the way back.
• Don't log what you don't need. Request logs containing raw prompts are personal data stores. Log metadata, token counts, and error types; keep raw prompts only if your product genuinely requires them (and justify it in your DPIA).
• Scope the prompt to the task. Sending an entire customer record when the model only needs the shipping city violates minimization. Send the minimal context slice.

# Minimization in practice: redact before sending, restore after
def redact(text):
    text = re.sub(r"[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}", "<EMAIL>", text)
    text = re.sub(r"\d{3}-\d{2}-\d{4}", "<SSN>", text)   # US SSNs
    text = re.sub(r"\+?\d[\d\s-]{8,}\d", "<PHONE>", text)
    return text

prompt = redact(user_input)              # send this to the LLM
reply = llm.chat(messages=[{"role": "user", "content": prompt}])
reply = restore_placeholders(reply)      # restore known placeholders only

Redaction is not a silver bullet — models can infer identities from context, and restored placeholders can leak if the model echoes them — but it dramatically shrinks the surface area. Combine it with a documented policy of what types of data your application will never send to a model (credentials, health data unless absolutely required, government IDs).

Legal Basis and Transparency (Articles 6, 13, 14)

Every processing operation needs a legal basis, and for AI features the realistic options are consent, contract, or legitimate interest — not a free choice between them. Whatever you choose, document it and be transparent:

• Consent: explicit, specific, informed, and freely given. A pre-ticked checkbox is invalid. Works well for AI features that are not strictly necessary to deliver the core service.
• Contract: processing necessary to perform the contract with the user. Defensible for core functionality (e.g., a translation service cannot function without translating), but not for optional AI extras bolted on later.
• Legitimate interest: requires a balancing test (Article 6(1)(f) + Recital 47) documented in your records. Possible for analytics and abuse detection, harder to defend for sending personal data to third-party models.

Transparency means telling users, in plain language at the point of collection (Articles 13–14): that their input is processed by AI, which provider processes it, where the data goes (including non-EU countries), how long it is kept, and how to exercise their rights. A buried privacy-policy paragraph is not enough — an in-product notice next to the chat input ("Your messages are processed by AI providers; see privacy policy") is the pattern regulators expect.

DPIA: When High-Risk AI Processing Needs a Formal Assessment

Article 35 requires a Data Protection Impact Assessment when processing is "likely to result in a high risk to the rights and freedoms of natural persons." For AI applications, high risk is common: large-scale processing of sensitive data (health, political opinions, biometrics), automated decision-making with legal or significant effects, or systematic monitoring of publicly accessible areas. An AI support chatbot handling customer names and order history is usually not high risk; an AI screening tool that ranks job applicants, or a health-assistant LLM processing symptoms, almost certainly is. The DPIA itself is a structured document: describe the processing, assess necessity and proportionality, identify and evaluate risks to individuals, and list mitigations. It is not a one-time artifact — re-run it when you change providers, add a new data category, or ship a materially different AI feature. Templates are published by most EU supervisory authorities and by the EDPB; use one and keep it versioned.

Article 28: Processor Agreements with Your Model Provider

When you send personal data to an LLM API, the provider is your processor, and Article 28 requires a written contract between you and them covering, at minimum:

• The subject matter, duration, nature, and purpose of the processing
• The categories of data subjects and personal data involved
• That the processor only acts on your documented instructions (no training on your data without separate, explicit consent)
• Confidentiality obligations for anyone with access
• Security measures (Article 32)
• No subprocessors without your prior authorization — and a list of subprocessors when they exist
• Assistance with data subject rights and with your compliance obligations
• Deletion or return of data at your direction
• Audit rights (in practice: audits, or documented certifications such as SOC 2 / ISO 27001)

All major AI providers publish Data Processing Agreements (DPAs) you can sign — usually with a "no training on your data" default and an opt-in for training. Sign the DPA, file it, and note the subprocessor list. For open-ended model APIs without a signed DPA, the processor relationship is undocumented and that is a compliance gap, full stop. When you use an AI gateway (like DrAI) that fronts multiple providers, check whether the gateway's DPA covers its upstreams or whether you need a chain of agreements; gateways that let you disable data retention and pick EU-resident upstreams simplify the whole picture.

Data Subject Rights: Access, Erasure, Rectification (Articles 15–17)

Data subjects can demand, free of charge, that you: confirm whether you process their data and give them a copy (access); correct inaccurate data (rectification); and delete their data without undue delay (erasure). For AI applications, the implementation burden lands in three places:

• Prompt/conversation history. If you store chat history, DSARs apply to it. Provide a self-service export and delete (see our chat history guide), and an automated path for erasure that cascades to all stores — primary database, logs, backups where feasible, and vector embeddings.
• Provider-held data. You cannot unilaterally delete data already sent to a third-party model API. Your DPA must give you a deletion mechanism (most providers offer data-retention settings or deletion requests), and your erasure workflow should include a step for the provider side.
• Derived data. Outputs generated from personal data, fine-tuned weights, and cached responses are all subject to the same rights regime. Document what derived artifacts exist so the answer to "what do we hold about this person?" is complete.

Respond within one month (extendable by two more with justification). The cheapest way to be fast is to build the delete/export endpoints before the first DSAR arrives — retrofitting them under a 30-day clock is how breaches of Article 12 happen.

Cross-Border Transfers: SCCs and the Data Protection Framework

Sending personal data to a model provider outside the EU/EEA is an international transfer (Chapter V). The compliant paths, in order of preference:

For most AI stacks this means: sign the provider's DPA with SCCs (their standard offering), run a quick Transfer Impact Assessment (a checklist, not a novel), and confirm the provider has no subprocessors outside the covered scope. If your product is EU-facing and sensitive, prefer providers or gateways with EU data residency — it removes the transfer question entirely for the majority of traffic.

Retention and Logging: Delete on a Schedule

Article 5(1)(e) requires that personal data be kept no longer than necessary. For AI systems, define and enforce concrete retention windows:

• Raw prompts/responses: default 0–30 days for most products (debugging needs) unless the product is a persistent assistant, in which case tie retention to the account lifecycle with a documented maximum.
• Logs and traces: strip personal data from logs at write time (log redaction middleware); keep metadata 30–90 days.
• Embeddings/vector stores: when a user deletes their account or invokes erasure, delete their embeddings too — a common oversight.
• Backups: apply the same retention logic; document how erasure propagates to backups (or set backup retention short enough that cascade erasure is bounded).

Encrypt everything at rest and in transit (TLS at minimum), and restrict access to prompt data to the minimum number of people with a logged reason (Article 32). Retention is where "we don't keep prompts" should be the honest engineering truth — not a policy nobody implemented.

Vendor Assessment Checklist

Before production traffic touches a new model provider or gateway, run this checklist and file the evidence:

Treat the checklist as a living document — re-verify annually and whenever the provider publishes new terms. Provider privacy pages change more often than your code does.

The GDPR Compliance Checklist for AI Developers

1. Confirm whether the GDPR applies (EU users or establishment) and document the decision
2. Inventory where personal data enters AI processing: prompts, logs, history, embeddings
3. Implement PII redaction/pseudonymization at the prompt boundary
4. Document a legal basis per AI feature; add in-product transparency notices
5. Run a DPIA for high-risk features; version it and re-run on material changes
6. Sign and file Article 28 DPAs with every provider; review subprocessors
7. Build self-service export and deletion for chat history and derived data
8. Implement provider-side deletion steps in the erasure workflow
9. Cover cross-border transfers: DPF check or SCCs + TIA
10. Set retention windows for prompts, logs, and embeddings; enforce them in code
11. Encrypt in transit and at rest; restrict and log access to prompt data
12. Re-run the vendor checklist annually and on provider term changes

Compliance on AI APIs is mostly engineering hygiene: redact what the model does not need, document what you send and why, sign the paperwork that turns your provider into a compliant processor, and build deletion before you need it. None of it requires slowing down your roadmap. If you are choosing a gateway, look for one that lets you disable retention, offers EU-resident upstreams, and documents its processing terms plainly — DrAI publishes its data handling terms and supports retention controls; see pricing and sign in to evaluate. Pair this guide with our LLM data privacy deep dive and the AI API security checklist for the full picture.