GDPR for AI agents: can you delete data you don't control?

A customer emails: “Delete everything you hold about me.” Under GDPR that’s not a courtesy — it’s an obligation with a clock on it. You go to honor it, and then you remember the AI agent. It talked to this customer a dozen times. It has their questions, what was decided, what it did on their behalf.

So, the question that ends a lot of agent pilots:

Can you actually delete that? Or does it live somewhere you don’t control?

For agents built on a rented platform, the answer is usually the second one. And a deletion request you can’t fully execute isn’t a paperwork problem — it’s a compliance gap with your name on it, because under GDPR you’re the controller, not the vendor running your agent.

This is the final post in the compliance series, and it lands on the same place the memory post did, from the regulator’s side of the desk: privacy obligations are only as real as your control over the data.

Four obligations a black box puts out of reach

GDPR (and its growing list of cousins) turns an agent’s conversation history into regulated personal data the moment a real customer talks to it. That brings obligations you have to be able to act on — and a rented memory makes each one someone else’s decision:

• Right to erasure. A data subject can ask you to delete their data, and you have to actually do it — everywhere, including the agent’s history. If you can’t reach into the store, you can’t honor the request; you can only ask a vendor to.
• Retention limits. You’re not allowed to keep personal data forever “just in case.” Conversations should age out on a schedule you set — not sit indefinitely under a default you didn’t choose and can’t see.
• Legal holds. Sometimes the obligation runs the other way: don’t delete this, it’s under investigation. That requires fine-grained control over what’s preserved and what isn’t — which a delete-everything button or a fixed expiry can’t give you.
• Data residency. GDPR restricts transfers of personal data outside the EU/EEA (Chapter V), and many organisations face further residency requirements from sector rules or customer contracts. Where the data physically lives matters — but if your agent’s memory sits “in the platform,” it sits wherever they host it.

Each of these is routine for a mature data team — for the data they control. The agent’s history quietly becomes the one regulated dataset that isn’t theirs to manage.

Data minimization: the part that has to happen before storage

There’s a fifth obligation that a black box can’t help with at all, because it has to happen at the moment of writing: don’t store what you don’t need. Card numbers, health details, a customer venting something sensitive — a lot of it lands in conversation history by default. GDPR’s minimization principle says strip or mask what you don’t need before it’s ever written down.

You can only do that if you control the write. When memory is rented, sensitive content is captured on the vendor’s terms and you’re left trying to scrub it after the fact — if you can reach it at all.

The fix is the same one as the rest of the series: own the store

FlowDrop keeps the agent’s conversations in your own database, and never holds them itself. That single fact turns all five obligations from “raise a ticket and hope” into ordinary data operations you already know how to run:

• Erasure is a delete you execute — across the agent’s history the same way you delete anywhere else in your stack, with no third party in the loop.
• Retention is your policy enforced by your tooling — expire conversations on your schedule, because they’re your rows.
• Legal holds are yours to place and lift, at whatever granularity your situation needs.
• Residency is wherever you run — your region, your infrastructure, your call. FlowDrop runs on your stack, so the data stays where you put it.
• Minimization happens at the write, on your terms — mask or drop sensitive details before they’re ever stored, instead of scrubbing them out later.

“We can honor a deletion request” should be a sentence about your own database, not a promise you’re relaying from a vendor.

Where the series lands

Three obligations, one root cause, one fix. The audit trail you can produce, the human oversight you can demonstrate, and the privacy requests you can honor all come down to the same thing: you hold the parts. The agent proposes; your system decides and runs. The records, the controls, and the data live in your infrastructure — not in a black box you’d have to ask permission to inspect.

That’s not a compliance feature bolted onto an agent. It’s what makes an agent something a regulated organisation can put in front of real customers in the first place — because every question a regulator, an auditor, or a customer can ask has an answer that’s yours to give.

Series — Building agents that pass compliance:

1. Your auditor is going to ask where the agent’s decisions are logged
2. The EU AI Act says you need human oversight — a system prompt isn’t it
3. GDPR for AI agents: can you delete data you don’t control? (you’re here)

Previously: The EU AI Act says you need human oversight — a system prompt isn’t it.

Building it yourself? Start with the docs →