GDPR and CCPA compliance for LLM applications

How do you comply with GDPR and CCPA when using LLMs?

The regulations don't have an LLM chapter. They have obligations about personal data, and an LLM application is a system that processes personal data in some fairly specific ways. Compliance work is the job of connecting each obligation to a control in your code, and most of the guidance available stops one level above that.

This guide is that mapping: requirement, the control that satisfies it, and where the control goes. It's written for the engineer who has been handed a data protection impact assessment and needs to know what to build.

This is technical guidance and not legal advice. Whether a specific obligation applies to your processing, and whether a specific control discharges it, depends on facts about your business that a page can't know. Get the analysis from your own counsel or data protection officer. What follows is the engineering half.

Which requirement maps to which control?

Two rows carry more weight than the rest in practice: the recipient inventory, because it's what a reviewer asks for first, and the derived-store delete path, because it's the one that turns out to be a quarter's work when someone finally tries it.

Who receives the prompt?

Start here, because everything else depends on it. Write down every service that sees prompt content, and be exact about content versus metadata.

The list is usually longer than expected:

• The model provider.
• Any AI gateway or proxy in front of it, which by construction receives the body.
• A cloud DLP or PII scanner, if inspection is done by sending content out.
• An observability vendor, if prompts are attached to traces or spans.
• An error tracker, if request bodies are captured on exceptions.
• An evaluation or prompt-management platform, if production traffic feeds it.
• A vector database, if it's hosted rather than run by you.

For each, record what it receives, where it processes, what it retains and for how long, and which contract governs it. That table is most of an Article 30 entry and most of a sub-processor disclosure.

The row that surprises teams is the security scanner. A control bought to prevent personal data leaving is itself a recipient of personal data if it inspects by receiving. That isn't a reason not to use one, but it is a reason it belongs on the list, and it's the argument for inspection that runs in your own process. For more information, see keeping security inspection local.

Does redaction discharge minimization?

Partly, and the honest version of the answer is more useful than a confident one.

Article 5(1)(c) asks that processing be adequate, relevant, and limited to what's necessary. If a task needs the shape of a message but not the customer's phone number, sending the phone number isn't necessary, and removing it before transmission is a direct answer to the requirement. That's a straightforward case and redaction handles it.

Where it gets less clean:

Redaction is best-effort. Detection has false negatives, and a control that mostly works is a mitigation rather than a guarantee. Describe it as risk reduction in your documentation, not as elimination.

Reversible redaction keeps a mapping. If your process holds a table that maps <Redacted email #1> back to the address, that table is personal data, with its own security, retention, and access obligations. Irreversible replacement avoids creating it. Choose deliberately rather than defaulting to reversible because the library offers it.

Pseudonymous is not anonymous. GDPR Recital 26 is explicit that data which can be re-identified with additional information remains personal data. A placeholder plus a mapping is pseudonymization, which Article 32 recognizes as a security measure, and it doesn't take the data out of scope.

Does redaction remove the processor relationship?

This gets misstated in both directions, so it's worth being careful.

Sending redacted prompts to a model provider does not end your processor relationship with that provider. You're still sending them data, still need a contract under Article 28, and still need a transfer mechanism if the processing is outside the EEA. If any personal data survives the redaction, and some usually does, the relationship is unchanged in kind.

What changes is the analysis of a scanner, and only when it runs in your own process. A library that classifies a string inside your application isn't a recipient of that string, because there's no disclosure. That doesn't make you compliant; it removes one recipient from the list you have to account for. Removing a question is not the same as answering one.

Where a vendor claims local inspection, verify it rather than accept it. Ask which specific controls run locally and which call out, what exactly is transmitted for the ones that do, and whether the local component is an in-process library or a sidecar. Then watch your own application's network traffic during a test, which is the only check that doesn't rely on the answer.

Arcjet's sensitive-information detection runs in a WebAssembly module inside your process. What reaches the Arcjet Cloud API is the decision record: the matched entity types, the rule label, and a SHA-256 hash of the scanned text. Note the hash rather than skipping past it. It carries no readable content, but a hash of a low-entropy value such as a phone number is guessable, so treat it as an identifier in your own analysis rather than as anonymized data. Other Arcjet controls do transmit different things, and the control-by-control table says which.

How do you honor an erasure request?

Enumerate where a person's data ends up, then check that each location has a delete operation you can actually call.

• The conversation transcript. Usually straightforward.
• Summaries and derived records. Often in a different table, often forgotten.
• The vector store. This is the hard one. If your embeddings carry no reference back to the source record, you can't find the chunks belonging to a data subject. Store a source identifier as metadata at write time, because retrofitting it means re-embedding the corpus.
• Caches. A cached completion outlives the deletion of the record it describes unless the cache key is invalidated too.
• Logs and traces. If prompts reach them, they're in scope, and log stores are usually append-only. The realistic answer is to keep prompt content out of them rather than to build deletion into them.
• The model provider's retention. Governed by your contract and their configuration, not by your code.

The fine-tuning case has no good answer. Data in the weights isn't deletable in any meaningful sense, which makes "don't put personal data in a fine-tuning set" a compliance requirement rather than a preference. For the disclosure side of that, see how to prevent LLMs surfacing confidential employee or customer data.

How do you keep an audit trail without a second PII store?

An auditor wants evidence that the control ran, fired when it should, and was enforcing rather than observing. None of that requires keeping the content.

Record per decision: a timestamp, the rule and its mode, the entity types matched, a count, the outcome, an actor identifier, and a correlation identifier for the conversation or run. That's enough to demonstrate the control operated and to reconstruct a sequence during an investigation.

Do not record the matched span, the message, or a "helpful" excerpt. A compliance log full of the card numbers your detector caught is a new personal-data store with a long retention period, replicated to your observability vendor, and readable by everyone with a dashboard. It's also, in most retention schedules, kept longer than the request it came from.

If you need to correlate repeated occurrences of the same value without storing it, use a keyed HMAC with a secret held outside the log store, and treat the result as pseudonymous rather than anonymous. For the practical version of this, see how to stop users sending PII to an LLM.

Where enforcement lives affects the evidence too. A control that runs in your application code produces a decision record tied to the specific action, and the rule that produced it is in version control with a review history. For more information about that, see compliance evidence for AI agents.

When do you need a data protection impact assessment?

Article 35 requires one where processing is likely to result in a high risk to individuals, and the European Data Protection Board's criteria include evaluation or scoring, automated decision-making with significant effects, systematic monitoring, sensitive data at scale, and innovative use of technology.

An LLM feature over customer data hits several of those, which in practice means most substantial deployments need one. Getting there first is cheaper than being asked. The engineering inputs are the recipient inventory, the data flow, the retention picture per store, and the control list with its failure behavior. If you've built the tables in this guide, you've done most of the assessment's technical section.

For authoritative sources rather than a summary, the EDPB guidelines and your own supervisory authority's guidance are the ones to cite in the document itself.

Checklist

• List every service that receives prompt content, including scanners and observability vendors.
• Redact or block personal data before the provider call, and describe it as risk reduction.
• Decide reversible versus irreversible per entity class, and account for the mapping table if you keep one.
• Give every derived store a retention period and a delete path that a subject request can reach.
• Store a source identifier with every embedding at write time.
• Keep prompt content out of logs and traces rather than planning to delete it later.
• Record decision metadata for audit, never matched content.
• Keep personal data out of fine-tuning sets.
• Run the DPIA early and reuse the inventory you already built.
• Have counsel review the mapping against your actual processing.