GDPR and AI APIs: A Practical Compliance Guide

GDPR is usually explained to engineers as a set of principles. It is more useful read as a set of questions about a specific record moving through a specific system — because that is the form the questions arrive in when somebody asks them for real.

This is engineering guidance and not legal advice. The regulation is long, its interpretation moves, and the sections referenced below should be read in their current text rather than trusted from a summary. What this page can do is tell you which artefacts you need to have built before that conversation is productive.

Who is the controller, and of what

The regulation distinguishes the party that decides the purposes and means of processing (the controller) from the party that processes on their instructions (the processor). Almost every argument about AI and GDPR is really an argument about where that line falls, so settle it first.

The usual shape: your customer’s personal data, sent by your application to a model provider, makes you a controller and the provider a processor acting for you. The provider is separately a controller of its own account, billing and abuse-prevention data — both things are true at once, about different data. That dual role is normal and is not a red flag; what matters is that the provider is not quietly a controller of your customers’ content, which is what a broad “we may use content to improve our services” clause can amount to.

Where you are a processor for your own customers, everything below runs twice: once between you and them, once between you and each provider. Article 28 is explicit that a processor may not engage another processor without authorisation, which is the legal shape of the sub-processor chain the rest of this cluster keeps talking about.

Lawful basis is per purpose, not per app

Article 6 sets out the bases on which processing can be lawful — consent, performance of a contract, legal obligation, vital interests, public task, and legitimate interests. The mistake to avoid is picking one for “the AI feature”. A basis attaches to a purpose, and one feature routinely has several.

Article 9 sets a higher bar for special categories — health, biometrics, political opinions, and the rest. Free-text prompts are exceptionally good at collecting these by accident: a support chatbot receives health information the moment a customer explains why they need a refund. You do not get to say you did not intend to collect it. Either build the detection and handling, or design the surface so it is not invited.

Every hop is a potential transfer

Chapter V governs sending personal data outside the EEA. The mechanisms are an adequacy decision for the destination, appropriate safeguards such as standard contractual clauses, or one of the narrow derogations. Which of those applies is a question for counsel; the engineering question is prior to it and is one nobody else can answer: which hops exist.

Enumerate them literally. Your application region, your gateway region, the provider’s API endpoint, the region the model is actually served from, any sub-processor behind that, and — the one most often missed — the location from which the vendor’s support and operations staff can access systems. Remote administrative access from a third country is a transfer even when the disks never leave.

Case law has moved this area repeatedly, and the current expectation is that signing clauses is not by itself sufficient: the law of the destination has to be assessed against them. Check the current position before relying on any particular mechanism, and keep the hop list current, because a provider adding a region is a change to your transfer picture that will not be announced to you as one.

The ROPA row for an inference call

Article 30 requires records of processing activities. Most teams treat this as a document exercise; treat it instead as the inventory you were going to need anyway, and generate it from something closer to the code:

activity:            "Support assistant — answer generation"
role:                controller
purpose:             respond to an inbound customer message
lawful_basis:        legitimate interests (LIA: docs/lia-support.md)
data_subjects:       customers, and third parties they mention
categories:          name, account id, free-text message body
special_categories:  possible in free text — see redaction policy
recipients:
  - name: <model provider>        role: processor   dpa: <ref>
  - name: <gateway, if any>       role: processor   dpa: <ref>
  - name: <their sub-processors>  role: sub-processor  list: <url>
transfers:           yes — <destination>, mechanism: <SCCs | adequacy>
retention:           conversation 90d; provider-side: <per DPA>
security:            TLS in transit, field-level redaction pre-send,
                     prompt bodies excluded from application logs
reviewed_on:         <date>   owner: <team>

Two fields do disproportionate work. special_categories forces the free-text conversation to happen in writing. And listing the gateway and the provider’s sub-processors as separate rows is what stops the record from describing a two-party system that does not exist.

Rights requests, mechanically

Access, rectification, erasure, portability and objection all resolve to the same engineering question: can you find every copy of one person’s data and act on it within a month. For an AI feature the copies are in more places than the primary database.

• Conversation store. Straightforward, provided messages are keyed to a subject rather than to an anonymous session you cannot reverse.
• Your logs and traces. The reason to keep prompt bodies out of them is precisely that a rights request otherwise reaches into your observability stack.
• Evaluation sets and fine-tuning corpora. If production content was copied into a dataset, the dataset is in scope and needs the same subject key.
• The provider side. Governed by the DPA. This is why the retention and deletion clauses matter operationally and not just contractually.
• Model weights. A genuinely hard case, treated separately in the page on erasure and trained models.

Article 35 requires a data protection impact assessment where processing is likely to result in high risk, and large-scale processing of free-text personal data through a third party is at least a candidate. Doing one early is cheaper than being asked for one late, and it produces the same inventory as everything above.