Calling an AI API means sending text — and often personal data — to a third party. To stay GDPR-compliant you need four things: a lawful basis, a data processing agreement with the model vendor, a residency path (EU endpoint, region pinning, or self-host), and prompt logging that is off by default or redacted before it is written.
What actually gets sent to a model
The PII surface is far larger than “the user’s message.” One chat completion can carry six distinct payloads, and teams typically discover two of them after an incident.
| Payload | Typical PII | Why teams miss it |
|---|---|---|
| User message | Names, emails, account numbers typed by a human | Obvious — usually handled |
| System prompt | Interpolated tenant or customer data | Treated as code, not as a data flow |
| Retrieved context (RAG) | Database rows, tickets, contracts, transcripts | Your DB has retention; the vendor’s copy does not |
| Tool / function outputs | CRM, billing and HR API JSON | Agents fetch data and hand it over by design |
| Conversation history | Everything above, replayed each turn | Stateless APIs resend history |
| Vendor telemetry | Full prompts in a dashboard | Request logging is often on by default |
Conversation history is an amplifier. Chat completion APIs are stateless: you resend the whole message array every turn. If turn one contains a customer email, that email is transmitted again on turns two through twenty — twenty disclosures under GDPR, and twenty log entries at the vendor and in your observability stack. Truncating history is a privacy control, not just a cost control.
Embeddings are personal data. It is tempting to treat a vector as anonymised because you cannot read it, but inversion research shows approximate text recovery is feasible, and a vector still permits singling out an individual — the GDPR test for identifiability. If you embed user documents, those vectors belong in your deletion path. See AI embeddings and RAG for the architecture this affects.
GDPR basics for AI teams
This is engineering-adjacent compliance, not legal advice — have counsel review anything customer-facing.
1. Lawful basis: consent is usually the wrong choice
Consent must be specific, informed and as easy to withdraw as to give — and withdrawing mid-conversation means unwinding context already sent to a vendor. For most B2B AI features, legitimate interests is more defensible, provided you document a Legitimate Interests Assessment covering purpose, necessity, the balancing test and your safeguards. Redaction and no-logging belong in that test. Where AI output is what the customer pays for, contract performance is cleaner still.
2. Controller, processor, and the question that breaks the chain
You are the controller; a vendor acting only on your instructions is a processor. The chain breaks when a vendor processes your prompts for its own purposes, typically to improve its own models — it is then a controller for that purpose, and a single Art. 28 agreement no longer covers it. That is why “does this vendor train on API traffic by default?” is the first due-diligence question, not the last.
3. The DPA must name subprocessors — including the inference host
Article 28 requires a written contract with every processor covering subject matter, duration, nature and purpose, categories of personal data and data subjects, and your instructions. The clause teams under-scrutinise is Art. 28(2): subprocessors need prior authorisation, plus notice of changes and a right to object. Many AI vendors add subprocessors silently, so ask for a published list and a notification channel — then monitor it. The list should name the hyperscaler region where inference runs, not just “cloud infrastructure.”
4. International transfers need a Chapter V mechanism
Moving personal data from the EEA to a US entity requires a transfer mechanism: an adequacy decision, EU-US Data Privacy Framework certification, or Standard Contractual Clauses. Because adequacy arrangements are politically reversible, SCCs plus a transfer impact assessment is the durable option. Crucially, a transfer is not only storage. If an engineer or abuse-review analyst outside the EEA can open your prompt in a support console, that is a transfer your mechanism must cover.
5. Know when a DPIA and Art. 22 are triggered
A DPIA is required for systematic and extensive evaluation of individuals, large-scale special-category processing, or systematic monitoring. A writing assistant usually does not trigger one; a health-triage bot or HR screening tool does. Article 22 also bites when a decision rests solely on automated processing with significant effects — an auto-rejecting feature triggers it, an assistant does not.
Keeping prompts out of logs
“No logging” is three separate switches that vendors frequently conflate. Ask about each independently:
- Training opt-out — your data is not used to improve models. Most commonly offered, least protective.
- Retention window — how long prompts and completions are stored. A training opt-out does not imply zero retention; a fixed abuse-monitoring window is common and legitimate, but still processing you must disclose and record.
- Access logging — whether a human can read the prompt in a dashboard or support tool. This turns a storage question into a transfer question.
Get all three in the DPA as a number and a purpose, not in a help-centre page that can change without notice. Then close your own side of the leak: redact high-signal identifiers before the payload leaves your process, and never write the raw request body to application logs. The pattern below keeps a token-to-value map in memory so you can re-hydrate the reply without persisting the original:
import re, hashlib
# Redact PII before the payload leaves your process.
# The vault stays in memory - never persist it.
PATTERNS = {
"EMAIL": r"[\w.+-]+@[\w-]+\.[\w.]{2,}",
"IBAN": r"\b[A-Z]{2}\d{2}[A-Z0-9]{10,30}\b",
"CARD": r"\b(?:\d[ -]?){13,19}\b",
}
def redact(text: str, vault: dict) -> str:
for label, pattern in PATTERNS.items():
def swap(match):
digest = hashlib.sha1(match.group().encode()).hexdigest()[:8]
token = "[[%s_%s]]" % (label, digest)
vault[token] = match.group() # in-memory only
return token
text = re.sub(pattern, swap, text)
return text
vault = {}
safe_prompt = redact(user_message, vault)
response = client.chat.completions.create(
model="gpt-4o-mini",
messages=[{"role": "user", "content": safe_prompt}],
)
reply = response.choices[0].message.content
for token, value in vault.items(): # re-hydrate for the user
reply = reply.replace(token, value)
Three caveats matter. Regex is a floor, not a ceiling — it will not catch a person’s name or a street address, so pair it with a named-entity recogniser such as Presidio for free-text fields. Placeholders change model behaviour: a prompt full of [[EMAIL_a1b2c3d4]] tokens can degrade output, so measure quality before and after. And scrub your observability stack too — an APM tool that captures HTTP request bodies will store every prompt you just redacted, so disable body capture or strip the messages field.
If you route through a gateway or relay, add a fourth layer: confirm the gateway itself is not logging request and response bodies. A relay sits directly in the path of every prompt, so its default logging behaviour becomes part of your data flow. You want prompt logging disabled and metadata-only retention — status, latency, token counts, model name — in writing. That is a first-class reason to choose a gateway on privacy grounds rather than convenience; see our AI API gateway guide for the rest of the evaluation criteria.
Data residency options
Residency is a spectrum, and each rung trades effort for strength. Pick the lowest rung that satisfies your actual obligation.
| Option | Residency strength | Effort | Best for |
|---|---|---|---|
| EU endpoint, US vendor | Medium — verify remote access + transfer mechanism | Low | EU data at rest, fast |
| Region-pinned relay / gateway | Medium-high — enforced centrally | Low-medium | Teams routing multiple models |
| Self-hosted open weights | High — no third-party processor | High | High-volume narrow tasks |
| Hybrid routing by data class | Medium-high | Medium | Mixed workloads |
An EU endpoint is not automatically an EU-only processing path. Check three things: whether data at rest is in an EU region, whether inference itself runs there (some “EU endpoints” front a global inference fleet), and whether support or abuse-review staff outside the EU can read your prompts. The third item is the one that survives contact with auditors.
Region pinning at the gateway is the pragmatic middle. Instead of asking every service to remember which endpoint to call, declare the residency policy once and let the routing layer enforce it. A relay that pins inference to EU-hosted deployments keeps your OpenAI-compatible request shape and existing code, while giving you one auditable place to prove where a request went. qoraapi.com supports region pinning and prompt-logging opt-out, making it a workable enforcement point if you would otherwise scatter residency logic across services.
Hybrid routing is the cheapest compliant design most teams should adopt. Tag each call site with a data class — personal or non-personal. Code generation and classification of non-user content can go anywhere; anything carrying customer data gets pinned to the EU path. You keep frontier-model quality where it is safe and hard residency guarantees where they are required. The failure mode to avoid is a data-class tag that lives in documentation instead of in the request path.
Vendor due diligence
These are the questions where vague answers are the signal. Ask all eight before signing, and record the answers in your Art. 30 processing record.
| Question | Adequate answer | Red flag |
|---|---|---|
| Where does inference run? | Named regions + inference host | “Global infrastructure” |
| Retention window for prompts? | A number, a purpose, zero-retention option | “We do not retain your data” |
| Training on our API traffic? | Contractual opt-out, default off | Dashboard toggle |
| Who can read our prompts? | Least-privilege, EU-only option | “Authorised personnel” |
| Subprocessors and change notice? | Published list + notification channel | “Available on request” |
| Transfer mechanism? | DPF and/or SCCs, TIA on file | “We are GDPR compliant” |
| Zero retention in the contract? | Yes, in the DPA | UI setting only |
| Data on termination? | Deletion, with confirmation | Silence |
One technique makes this concrete instead of contractual: send a canary. Put a unique marker such as PII-CANARY-7f3a91 in a real request, then try to find it — in the vendor’s dashboard, by asking their support for the request record, and by grepping your own logs, traces and vector store. You are testing whether the retention claim matches reality, and you end up with evidence rather than a marketing sentence. Re-run it whenever the vendor changes its terms. Keep this workstream separate from key and abuse controls — our guide to AI API security covers that side; privacy is about what you send, not who can send it.
A pre-ship privacy checklist for AI features
Run this before launch, and re-run it when you add a model, a tool or a retrieval source. Every item is something an auditor, an enterprise questionnaire, or a customer’s DPO can ask for by name.
- Data map per call site. For each AI call, list the fields that enter the prompt and their source system. Everything else depends on this artefact.
- Documented lawful basis per use case, with an LIA on file where you rely on legitimate interests.
- DPIA screen. Special-category data at scale, systematic monitoring, or significant automated decisions? If yes, run a full DPIA before launch.
- Art. 30 record updated with the AI processing activity, retention window and transfer mechanism.
- Signed DPA with every model vendor and every gateway or relay in the path, including subprocessor authorisation and change notification.
- Subprocessor list reviewed, with a recurring reminder to re-check it quarterly.
- Transfer mechanism confirmed (DPF and/or SCCs) with a transfer impact assessment covering remote access, not just storage.
- Redaction layer in the request path, with a unit test that feeds a fixture containing a fake email, card number and IBAN and asserts none survive into the outbound payload.
- Observability scrubbed. Request-body capture disabled in your APM, and the
messagesfield excluded from error reports. - Gateway configured for privacy: prompt logging off, metadata-only retention, residency pinned per route.
- Residency enforced in code, not in a wiki page — a data-class tag on every call site, with personal-data routes pinned to the EU path.
- Retention timers on every derivative store: prompt cache, vector store, trace store and evaluation dataset each have a TTL and a scheduled purge.
- Deletion path tested end to end. Can you delete one user’s prompts, embeddings, cached completions and traces on request? Most teams can delete from the primary database and cannot delete from the vector store — test it, do not assume it.
- Privacy notice updated to name the AI processing, the vendors and the retention window.
The last two items are where launches slip. A DSAR runbook that only covers relational tables will fail the first time a customer asks you to delete their data, because the vector index and trace store still hold it.
Frequently asked questions
Is sending data to an AI API a data transfer under GDPR?
It is a transfer whenever personal data reaches an entity outside the EEA — including a US vendor’s EU region, if staff outside the EEA can access it. You then need a Chapter V mechanism (adequacy, DPF certification, or SCCs) plus a transfer impact assessment. Document which mechanism covers which flow, because one vendor can involve several.
Does a no-logging endpoint mean nothing is retained?
No. Training opt-out, retention window and access logging are independent. A provider can decline to train on your data while still retaining prompts for a fixed abuse-monitoring window with human review. That is often legitimate, but it is processing you must disclose and record. Ask for the window as a number and the purpose in the DPA.
Are embeddings personal data?
Treat them as personal data. A vector is derived from personal data, permits singling out an individual, and is subject to inversion attacks that recover approximate source text. Redacting before you embed does not make the vector anonymous if the redaction was incomplete. Include the vector store in your retention schedule and deletion path.
Do we need a DPIA for an AI chat feature?
Usually not for an internal assistant or a general writing tool. You do need one when the feature processes special-category data at scale, systematically monitors people, or drives automated decisions with significant effects. Run a short screening assessment at design time and keep the result — it is far easier than retrofitting one after a customer’s DPO asks.
Conclusion
AI data privacy is not a policy document — it is four engineering decisions. Know what leaves your process, because retrieved context and tool outputs carry more PII than the user’s message. Get the DPA right, including subprocessor authorisation and a named transfer mechanism. Redact or disable prompt logging at every layer. And enforce residency in the request path, not in documentation.
If you are deciding where to enforce that, start with the OpenAI-compatible API model of one endpoint in front of many providers — it gives you a single place to pin regions and disable prompt logging without touching application code. Then run the checklist above before your next release.
Leave a Reply