GDPR Right to Erasure for AI Agents, in Practice

Someone emails you three words: delete my data. If an AI agent has handled their information, that request reaches more than the conversation you can scroll back through. It reaches the record of what the agent did, the search index it built from their documents, and the backups. GDPR gives you one month to deal with all of it. This is what a deletion request actually touches in an agent setup, when you are allowed to keep data, and what to have in place before the next request arrives.

Someone emails you three words: delete my data.

If an AI agent has handled their information, that request reaches more than the conversation you can scroll back through. It reaches the record of what the agent did, the search index it built from their documents, and the backups. GDPR gives you one month to deal with all of it.

This page covers what a deletion request actually touches in an agent setup, when you are allowed to keep data, and what to have in place before the next request arrives. It reports what the law says. It is not legal advice, and whether a specific request has to be actioned is your call as the business holding the data.

Where does a data deletion request reach in an AI agent setup?

A deletion request reaches every place the agent kept a copy of the person's data, and the chat window is only the first one.

An AI agent is not just a chat. To do its job it keeps records, builds an index of the documents it was given, and writes results into your other tools. Each of those is a separate copy of whatever personal data passed through. When someone asks you to delete theirs, the request lands in all of the following:

• The conversation. The messages you can see in the chat window.
• The record of what the agent did. A log of every action it took: the email it drafted, the CRM field it updated, the file it read. These usually contain names, email addresses, and quoted content.
• The search index. When the agent is given documents to work from, it builds its own searchable copy of them so it can find things fast. That copy is separate from the originals.
• Saved summaries and drafts. Anything the agent generated and kept to save repeating the work.
• Backups. Every automatic snapshot of the above, on whatever schedule the setup runs.
• Your other tools. The contact it created in your CRM, the note in your project tool, the ticket it opened.

So answering a request is a short piece of detective work, not a button. The useful thing to know in advance is which of these your setup actually uses, and where each one lives.

How long do you have to respond?

One month from the day the request arrives, under Article 12(3) of the GDPR.

You can extend that by two further months if the request is genuinely complex, but you have to tell the person inside the first month and explain why. For a first request against a setup nobody built a deletion process for, "complex" is honest. It is not a way to skip the work.

If you decide to refuse, the law puts the burden on you. Article 12(5) says you have to be able to show the request was "manifestly unfounded or excessive". That is a position you have to defend, per piece of data. It is not a default you can fall back on.

The clock is why preparation matters more than speed. A month is plenty of time to run a deletion you have set up and tested once. It is not enough time to discover, mid-request, that the agent has been writing client details into three tools nobody wrote down.

Why isn't deleting the conversation enough?

Because the agent keeps its own copy of the material it works from, and deleting the original does not clear that copy.

When you give an agent a set of documents, such as client files, past emails, or a knowledge base, it builds a search index so it can pull the right passage on demand. That index is a separate store. Delete the source document and the indexed copy stays where it is until it is cleared on its own.[1] The same is true of any summaries the agent saved and any backups taken since.

This is the part that catches people out. "We deleted their file" feels complete. In an agent setup it usually isn't, because the file was only ever the starting point. The agent made working copies to do its job, and each of those is in scope.

There is also a layer you do not control: the company that runs the underlying AI model keeps its own short-term copy of what was sent to it, under its own terms. As of September 2026, OpenAI keeps API data for up to 30 days by default and Anthropic deletes it within 30 days.[2] Those windows are finite and documented, which is the point to record. You are not expected to reach into the provider's systems, only to know the window exists. What each provider keeps and trains on is covered in which AI providers train on your data, and where that data is processed in AI data residency.

When are you allowed to keep the data?

Article 17(3) lets you keep specific data for specific reasons, and two of them come up in real businesses.

To defend a legal claim. If the person's data is needed for "the establishment, exercise or defence of legal claims", such as an open dispute, a live complaint, or a credible threat of one, you can keep what is necessary for that, and only that. Once the claim is resolved, the reason to keep it ends.

Because another law requires it. Where a different rule obliges you to retain the data, GDPR does not override it. Tax records and employment records are the common cases. A recruiting workflow, for example, may sit under rules that require keeping some applicant data for a set period even after a deletion request. The obligation has to be real and specific. "We might need it later" is not one.

The other three grounds in 17(3), freedom of expression, public health, and archiving in the public interest, exist but rarely apply to a small business.

Two limits worth holding onto. A reason to keep one thing does not let you keep everything: if you must retain an invoice for tax, you keep the invoice, not the chat history and the search index. And the retained data still has to be locked down and have an end date. It is kept for a named purpose, not indefinitely.

What does a completed deletion look like?

A completed deletion is not just the data being gone. It is a short record you can produce later if anyone asks.

That record has four parts, and it takes a few minutes to write if you have run the deletion properly:

• What you searched on. The identifiers used to find the person's data across every store: their name, email, an account or reference number.
• What you cleared, and when. Each store (conversation, action log, search index, summaries, connected tools), with the date it was done.
• What you kept, and why. Anything held back under Article 17(3), with the reason named and a date to review it.
• When the backups roll off. The point at which the last automatic snapshot containing the data expires on its normal schedule.

Article 17(2) sets the expectation that a controller takes "reasonable steps" to reach copies of the data, not just the original. The record is how you show you did. A regulator asking about a deletion wants to see the steps, not take your word that it happened.

What does a proper setup do for you here?

A setup built for this makes a deletion request a routine task instead of an investigation, in three ways.

An audit log means you can prove it. When every action the agent takes is recorded, you can show a regulator exactly what was deleted and when. That is the part a controller is expected to be able to demonstrate. Without a log, "we deleted it" is a claim with nothing behind it.

An isolated environment per client means the data is in fewer places. When each client's work runs in its own space rather than one shared pool, a deletion request touches one environment, not a search across everything the agent has ever handled. It is faster to answer and far harder to miss a copy.

Scoped access means you know where the data could have gone. When a workflow can only reach the specific tools it needs, the list of places to check is short and known in advance. A workflow with broad access is the one where you find a copy in a tool nobody expected.

Ongoing support means someone runs the deletion. With a done-for-you setup, clearing the data across every store within the month is the provider's job, done to a written process. It is not a task that lands on you the week the request arrives.

None of this is unique to any one AI framework. It is what setting the system up properly buys you, and a deletion request is the moment it pays off.

What should you check before the next request comes in?

Four things, and all four are cheaper to sort out now than during a live request.

1. Know where client data lives. Ask whoever runs your agent for the list: conversation store, action log, search index, saved summaries, backups, connected tools. If nobody can produce it, that is the first job, and one of the things worth asking about when you choose who sets the agent up.
2. Have a written deletion process. One page: each store, how it is cleared, and who does it. Run it once against a test record so you know it works.
3. Keep an audit log. Confirm the setup records what the agent does, so a completed deletion has evidence behind it.
4. Know your keep rules. Write down which data you are obliged to retain and for how long, covering tax, employment and open disputes, so a request does not force that decision under time pressure.

Get those four in place and a deletion request becomes an afternoon of work with a record at the end of it. That record is also what a client's data protection officer will ask to see.

What this page does not cover

This page reports the law and the current regulator position, and it has clear limits.

• It is not legal advice, and it does not decide your case. Whether a request must be actioned, and which of the Article 17(3) reasons apply, is a determination for the business holding the data.
• The regulator position that a deletion request applies to your setup rather than the AI model itself comes from a 2024 discussion paper by the Hamburg data protection authority.[3] It is one authority's view, not settled law, and other authorities may differ.
• Your setup may hold data in places this page does not list, such as a separate reporting database or an email archive. The list here is a starting point to check against your own.
• Provider retention windows change. The OpenAI and Anthropic figures were current in early September 2026 and both moved in August. Confirm them before you quote them to anyone.

Frequently asked questions

Does deleting a chat delete the customer's data from an AI agent?

No. Deleting the conversation removes it from the chat window and usually from the message history. It does not touch the log of actions the agent took, the search index it built from the customer's documents, saved summaries, backups, or records the agent wrote into your CRM or ticketing tool. A GDPR deletion request covers every one of those copies, so each has to be cleared separately.

How long do you have to respond to a GDPR deletion request?

One month from the day you receive it, under Article 12(3) of the GDPR. You can extend that by two more months if the request is complex, but you have to tell the person within the first month and give the reason. A month is enough time to run a deletion you have set up in advance. It is not enough to work out where the data is once the request is live.

Can you refuse a GDPR deletion request?

Sometimes, and only for specific data. Article 17(3) lets you keep what you genuinely need to defend a legal claim, or what another law requires you to keep, such as tax or employment records. You keep only that part, not the whole account, and if you refuse you carry the burden of showing the request was unfounded or excessive.

What should you ask your AI agent provider about data deletion?

Four questions: Where does client data end up in this setup? Is there a written process for deleting one person's data across all of it? Does the setup keep an audit log? And who runs the deletion if a request comes in? Vague answers mean the one-month clock is a problem waiting to happen.

Notes

Sources retrieved 1 September 2026.

1. On an AI agent keeping a separate searchable copy of source documents, and that copy needing to be cleared on its own: Ghost Vectors: Soft-Deleted Embeddings Remain Reconstructible in HNSW Vector Databases, Chakraborttii et al., June 2026, at arxiv.org/abs/2606.18497. Practitioner guidance on clearing the index, caches and backups and logging the deletion: Twig and AI Competence.
2. OpenAI API data retention is up to 30 days by default for abuse monitoring, with Zero Data Retention for approved customers: OpenAI data controls documentation. Anthropic deletes API inputs and outputs within 30 days, longer where a policy violation is detected: reported via Axios, 19 August 2026. Both terms were revised in August 2026; re-verify before quoting.
3. GDPR Article 17 (right to erasure) and Article 12(3) and 12(5) (response deadline and burden on the controller), quoted from the Regulation text at gdpr-info.eu/art-17-gdpr and gdpr-info.eu/art-12-gdpr. The regulator position that data-subject rights apply to the input and output of the deployed system rather than the model itself: Hamburg Commissioner for Data Protection and Freedom of Information, Discussion Paper: Large Language Models and Personal Data, 12 July 2024, at datenschutz-hamburg.de. A discussion paper, not binding law.

The list of stores describes a common agent setup and should be checked against your own.