GDPR compliance checklist for LLM data processing

Most teams treat GDPR as a legal checkbox until a regulator asks for the prompt logs. This GDPR compliance checklist for LLMs is written for engineers who actually ship inference pipelines, not compliance officers. It covers the technical controls you need to put in place before processing personal data through any model endpoint.

1. Map lawful basis to each processing context

You cannot send an email address to a model without a documented Article 6 basis. Pick one: consent, contract, legal obligation, vital interests, public task, or legitimate interest. Encode that choice in your request metadata so it travels with the payload and survives across service boundaries.

{
  "request_id": "req_8f2c",
  "lawful_basis": "consent",
  "consent_id": "cnt_2024_883",
  "user_id": "usr_5521"
}

If you switch bases per feature, isolate them in separate services. A recommendation bot running on legitimate interest should not share a queue with a support bot that relies on contract. The legal basis is not a global flag; it is a per-processing-operation property, and your code should reflect that.

Document the mapping in a versioned file alongside your infrastructure-as-code. When the DPA asks which basis covers the summarization feature, you should be able to point to a commit, not a slide deck.

2. Minimize personal data before it hits the prompt

Strip direct identifiers at the edge. Use deterministic redaction so you can map back later if needed, but never embed raw PII in the model context unless the basis explicitly allows it. Tokenizers do not forget; once a name is in the prompt, it lives in provider logs and possible caches.

import re

def redact(text: str, user_id: str) -> str:
    text = re.sub(r'\b[\w.]+@[\w.]+\.\w+\b', '[EMAIL]', text)
    text = re.sub(r'\b\d{9,12}\b', '[IDNUM]', text)
    return text + f" ::uid={user_id}"

Keep the mapping table in a sealed store, not in the same log stream as the redacted prompt. Data minimization is the single highest-leverage control in any GDPR compliance checklist for LLMs because it reduces the blast radius of every downstream mistake.

Consider whether you even need the model to see the user ID. Often a surrogate key is enough for the model to maintain conversation state while the real identifier stays in your own session store.

3. Emit audit logs that survive a regulator request

Your logs must answer who sent what to which model at what time. Use a structured schema and include the model provider, the routing region, and the token counts. Regulators do not accept “we think it was OpenAI” – they want the specific processor and the timestamp.

{
  "ts": "2024-05-11T08:22:01Z",
  "request_id": "req_8f2c",
  "user_id": "usr_5521",
  "model": "gpt-4o",
  "provider": "openai",
  "region": "eu-central",
  "prompt_tokens": 412,
  "completion_tokens": 88,
  "lawful_basis": "consent"
}

Ship these to an append-only sink with hash chaining if possible. If you use an inference gateway, per-token usage metering gives you the exact counts without custom instrumentation, and you avoid writing a tokenizer just for billing.

Do not mix redacted prompts with the audit trail. The audit log proves processing occurred; the prompt store explains what was said. Separate them by access policy.

4. Set retention and hard deletion windows

GDPR limits storage to what you need. Define TTLs on prompt logs, vector stores, and cached completions. Automate deletion with cron jobs or object lifecycle policies so you are not relying on a human to remember.

# Delete prompt archives older than 30 days
aws s3 ls s3://llm-logs-eu/ | awk '{print $4}' | \
  xargs -I{} aws s3 rm s3://llm-logs-eu/{} --expires $(date -d '-30 days' +%s)

For user-initiated erasure, purge by user_id across all stores within the statutory month. Keep a deletion receipt that records the query, the matched records, and the timestamp. That receipt is your evidence of compliance.

Retention windows should be shorter for higher-risk data. A support transcript with health mentions should not sit in a debug bucket for a year because someone set a default.

5. Vet every model provider as a sub-processor

Each third-party API is a sub-processor under GDPR. You need a signed DPA and confirmation of their region. If a provider routes to US infra without safeguards, you are exposed regardless of what your frontend claims.

Maintain a config that pins providers per data class:

const routing = {
  pii: { provider: "azure-openai", region: "eu-west" },
  public: { provider: "any", region: "global" }
};

An inference gateway that honors client routing directives lets you enforce this in one place. n4n.ai forwards provider cache-control hints and respects those directives, which simplifies residency proofs when you rotate providers under load.

Review DPAs when providers change their training or logging policies. A provider that silently starts retaining prompts for improvement is a breach waiting to happen.

6. Honor data subject access and erasure with correlation IDs

When a user invokes Article 15 or 17, you must locate all their processing. Generate a correlation ID at ingestion and stamp every downstream call, including fallback attempts and cache writes.

def handle_request(user_prompt, user_id):
    corr_id = f"corr_{uuid4()}"
    log_event(corr_id, user_id, "prompt_submitted")
    # ... call model ...
    log_event(corr_id, user_id, "completion_stored")

Without this, you will manually grep logs during a breach. Build the index now. Erasure requests should trigger a cascading delete keyed by user_id and corr_id across all stores, not just the primary database.

Test the flow with a synthetic user quarterly. If you cannot produce all their data in 72 hours, your access path is broken.

7. Enforce geographic residency at the network layer

Use DNS or proxy rules to ensure EU personal data never leaves eu-* regions. Test with a synthetic request that asserts the resolved IP range. A misconfigured fallback can quietly route to a US zone during a provider outage.

curl -s https://ipapi.co/json/ -H "X-Forwarded-For: $CLIENT_IP" | jq '.region'

If you rely on automatic fallback when a provider is degraded, confirm the fallback target is also region-compliant. A gateway with automatic fallback should still respect your routing constraints; otherwise you have traded uptime for a violation.

Document the residency architecture in a diagram that shows every hop. Regulators understand network boundaries better than abstraction layers.

8. Encrypt everything, manage your own keys

TLS is table stakes. For logs and caches, use envelope encryption with keys you control via KMS. Rotate quarterly and never let application code see the raw key material.

from cryptography.fernet import Fernet
key = Fernet.generate_key()  # store in KMS
f = Fernet(key)
encrypted = f.encrypt(prompt_bytes)

Never log the key material. GDPR expects technical measures; encryption at rest is explicitly recommended in Article 32. If a laptop with a prompt archive is stolen, the difference between a breach and a non-event is whether you encrypted.

Use separate keys per data class. Public data can use a shared key; PII should have a dedicated key with stricter access logging.

9. Monitor provider behavior and cache leakage

Models can echo training data. Log completion outputs that contain patterns matching your redaction tags. Alert if [EMAIL] appears in a response—that means your redaction failed upstream or the provider injected cached content.

if "[EMAIL]" in completion:
    alert("redaction_bypass", request_id)

Also track cache hits. Provider cache-control hints can keep data longer than you intend; forward only the directives you approve. If a provider caches a prompt for an hour, your deletion job must account for that window.

Set up synthetic canary prompts that contain fake PII and verify they never surface in completions or in your own logs unredacted.

10. Run periodic compliance drills

Quarterly, simulate a data subject request and a regulator audit. Time how long extraction takes. If it exceeds a week, your tooling is inadequate.

This GDPR compliance checklist for LLMs is not exhaustive, but it covers the engineering surface that gets teams fined. Implement the logging and correlation ID pieces first; they make every other control auditable. Compliance is a system property, not a document you sign.