Privacy Compliance for LLM Apps (GDPR, POPIA)

The moment an LLM agent has read access to customer or employee records, it becomes a new data flow that your existing privacy program probably didn't anticipate — a prompt is a place personal data can end up, a third-party model API is a place it can be transmitted to, and a chat log is a place it can be retained far longer than the business process that generated it. GDPR and POPIA don't have an "AI exception"; the same lawful-basis, minimization, and retention obligations apply, they're just easy to violate by accident with an agent that pulls "everything relevant" into context.

Minimize what enters the prompt, not just what you store

Data minimization applies to what you send to the model, not only what you persist afterward. If a task needs to confirm a customer's order status, the tool should return the order status — not the customer's full record with email, phone, and address bundled in because the API call was convenient to make broad. Build tool functions to return the minimum fields the task actually needs, not "select *" from whatever entity the API happens to expose in one call.

def get_order_status(order_nbr: str) -> dict:
    order = fetch_order(order_nbr)  # full record from Acumatica
    # Return only what the task needs — not the whole customer record
    return {
        "order_nbr": order["order_nbr"],
        "status": order["status"],
        "total": order["total"],
    }
    # Name, address, phone, tax ID stay out of the prompt entirely

Third-party model providers are a processor, not a black box

Under GDPR, sending personal data to OpenAI, Anthropic, or any hosted model API makes that provider a data processor, which means you need a data processing agreement in place and need to know their data retention and training-use policies before personal data reaches them. Both major providers offer API-tier terms that exclude prompts from training by default and specify retention windows — read the actual terms for the tier you're on rather than assuming, since consumer-tier and API-tier policies differ meaningfully.

PII in logs and traces needs its own retention policy

Observability logging (covered elsewhere on this site) often captures full prompts and responses for debugging — which means customer PII ends up in your logging infrastructure with whatever retention your logging system defaults to, frequently much longer than appropriate for personal data. Set an explicit, shorter retention window for any log store that captures prompt/response content, separate from your general infrastructure log retention, and redact or hash identifiers where the debugging value doesn't require the raw value.

The right to erasure and what an agent can't "forget"

If your agent uses episodic memory (a vector store of past interactions, discussed in the memory-systems article on this blog), a data subject's erasure request has to reach that store too, not just the primary database. Design memory retrieval keyed on a customer or employee ID from the start, so erasure is a targeted delete rather than a search-and-hope through unstructured embeddings. An agent that "remembers" a customer in a way you can't cleanly delete is a compliance liability you built for yourself.

Consent and purpose limitation for agent-driven actions

An agent answering "what's my leave balance" is using employee data for a purpose the employee expects. The same agent using that conversation history to, say, flag the employee for a performance review pattern is a different purpose that likely needs its own lawful basis and disclosure. Keep the agent's stated purpose narrow and don't let a system built for one purpose quietly start informing decisions it was never disclosed as feeding into.

Wrapping up

Scope tool responses to the minimum fields a task needs, confirm your model provider's processor terms and data residency before personal data reaches the API, and give logging and episodic memory their own shorter retention policy. None of this is exotic once you treat the prompt as a data flow like any other — the mistake is treating "the LLM" as outside the scope of a privacy program that already covers everything else touching the same records.