The right to be forgotten: what can a customer have erased from your AI system?

When can a customer demand that you erase their data?

The right to erasure is set out in Article 17 GDPR. It is commonly called "the right to be forgotten", which is an unfortunate name, because it promises more than the text delivers. The law says a person can obtain erasure of their personal data without undue delay, and that you, as the controller, are obliged to erase that data without undue delay — but only where one of the listed grounds applies.

Those grounds are specific. You must erase when the data is no longer necessary for the purpose you collected it for. When you relied on consent, that consent is withdrawn, and there is no other legal basis. When someone objects to the processing and you have no overriding legitimate grounds. When the objection concerns direct marketing — under Article 21(2) that objection is absolute, and there is nothing to discuss. And when you processed the data unlawfully, for example because you never had a valid basis in the first place.

Note what the article does not say. It does not say that anyone can demand at any moment that everything goes. It does not say that an angry customer can empty your entire client file with a single sentence. The right is strong, but it hangs on a ground, and paragraph 3 of the same article sets out exceptions alongside it.

Why "erasing" means something different in an AI environment

When customer contact lived in one inbox and one folder in the bookkeeping, deletion was straightforward. With an AI assistant handling email, WhatsApp or phone calls, the same customer data usually sits in several places at once. Think of the conversation thread in the chat database, the summary the assistant wrote into your CRM, the calendar appointment that followed from it, the transcript of a phone call, the search index the system uses to retrieve older conversations, your supplier's log files, and the backups of all of the above.

Article 17 grants no discount for technology. "Our system can't do that" is not an exception anywhere in the law. When a request arrives, you must be able to show where that person's data lives and how it leaves. That is an inventory question more than a legal one: what you cannot locate, you cannot erase.

There is a further duty that is often forgotten. If you shared the data with others — an accounting package, an invoicing service, a subcontractor of your AI supplier — Article 19 GDPR requires you to notify those recipients of the erasure, unless that proves impossible or involves disproportionate effort. Cleaning up your own database is therefore not automatically the end of the job.

Which exceptions are you allowed to invoke?

Paragraph 3 of Article 17 draws the boundaries. Two of them matter most to a small business.

The first is a legal obligation. Where Union law or Dutch law requires you to keep the data, that duty takes precedence over the request. This is the hook that almost every erasure request about orders, invoices and payments catches on.

The second is the establishment, exercise or defence of legal claims. If there is a dispute, a collection matter, a warranty argument or a complaint that could turn into a claim, you may keep the data you need to support your position. Be careful: that is not the same as "we keep everything because something might happen one day". You must be able to name the reason, and the reason must relate to this particular file.

The article also contains exceptions for freedom of expression, public interest, public health and archiving. Those rarely come up in ordinary small-business customer contact. The point is mainly this: you may only refuse on a ground the law actually contains, not on a ground that happens to suit you.

How does this collide with the tax retention obligation?

This is the heart of the problem. The GDPR says: keep it no longer than necessary. Dutch tax law says: keep it for seven years. That looks contradictory, but it is not — the two rules address different piles of data.

The Dutch Data Protection Authority puts it plainly: the GDPR contains no concrete retention period, organisations set that period themselves, and concrete periods do exist in other laws. The starting point is that you do not keep personal data longer than necessary, and what is necessary depends on your situation. So you have to set the period yourself and be able to explain it.

The hard number comes from Article 52(4) of the Dutch General Tax Act (Algemene wet inzake rijksbelastingen): those subject to the record-keeping duty must retain the relevant records for seven years, unless tax law provides otherwise. For private limited companies, foundations and associations the same seven-year period appears in Article 2:10 of the Dutch Civil Code, and for sole traders and freelancers it applies through Article 3:15i of the Civil Code. It is not a tax-office habit you can negotiate away with a customer.

This matters especially if you run AI in email and WhatsApp: the Dutch tax authority treats ordinary communication tools as part of your business records as soon as they are used for business. A WhatsApp exchange in which a price is agreed or an order is confirmed is then not a throwaway message but a piece of your administration. In that respect your AI channel is no different from a folder of quotations.

The practical conclusion: an erasure request almost always splits in two. The marketing part goes. The administrative part stays for as long as the period runs. And you explain which part stays and why.

What may you refuse, and on what ground?

Common erasure requests in AI-driven customer contact, set against what you may refuse and the legal ground for refusing

The request	May you refuse?	Ground	What you do instead
"Take me off your newsletter and mailing list."	No	Article 21(2) and Article 17(1) GDPR	Act on it immediately and confirm. Keep at most the minimum needed to make sure the person is not contacted again.
"Erase my entire conversation history."	Partly	Article 17(3)(b) GDPR	Erase whatever is not covered by a retention duty. Explain which part remains, why, and until when.
"Delete my invoices and order records."	Yes	Article 17(3)(b) GDPR read with Article 52 of the General Tax Act	Retain until the period expires, but restrict access to those who genuinely need it and stop using the data for other purposes.
"Erase everything about my complaint", while a dispute is running.	Yes	Article 17(3)(e) GDPR	Keep only the file you need for that legal claim, and clear out the rest.
A request from someone whose identity you cannot establish.	Do not act yet	Article 12(6) GDPR	Ask for additional information to confirm identity. Never act on a sender name alone.
The tenth identical request this month, with nothing new in it.	Possibly	Article 12(5) GDPR	Set out in writing why you consider it manifestly unfounded or excessive. Use this sparingly: the burden of proof sits with you.
"Delete the recording of my phone call", now that the question is resolved.	Usually not	Article 17(1)(a) GDPR	Act on it, unless the recording itself forms part of a file you must retain or of a live dispute.

The thread running through that table: refusing is allowed, but never silently and never without naming the article. In practice, a refusal without an explanation is the same as no answer at all.

What can and cannot be pulled out of an AI system?

An erasure request is only handled once the data is genuinely gone from every place it sits. Walk through this list before you confirm that it is done.

• The conversation database. Usually the easiest part. Check whether "delete" in your system means actual erasure or merely hiding the record from the user.
• Derived records. The CRM summary, the task that was created, the calendar entry, the support ticket. These often contain the same personal data and are the items most frequently skipped during a deletion run.
• The search index. Systems that retrieve older conversations keep a processed copy of the text. If you erase only the source and never rebuild the index, that copy stays.
• Backups. A backup is part of your processing. You do not have to crack open every old tape, but you do have to record how you handle them — for instance, that a restored backup is run past the deletion list again before it goes back into use.
• Whatever sits with your supplier. Log files, queues, transcripts, error reports with message content inside them. Your data processing agreement under Article 28 GDPR must ensure the supplier erases on your instruction. The tax authority adds that data third parties hold about your business also falls under your retention duty — so you need both access to it and the ability to have it removed.
• A trained model. If your conversations were used to train or fine-tune a model, you will not lift one person back out of it with a button. You solve this in advance, in the contract, not after the first request lands.

The practical advice is dull but effective: make sure there is one place where you can look up, per person, where their data lives. Without that overview every erasure request becomes a search, and a search rarely fits inside a month.

What is the difference between erasing and anonymising?

This distinction often rescues you from the collision between erasing and retaining.

With erasure, the record is gone. The rule is satisfied, but you also lose everything: the number of conversations, the handling time, the reason behind the complaint.

With anonymisation, you strip out everything that leads back to a person, to the point where the person can no longer be identified by any reasonable means. Data that is genuinely anonymous is no longer personal data and therefore falls outside the GDPR — that follows from recital 26 of the Regulation. A conversation stripped of name, phone number, address, order number and every unique detail can survive as anonymised statistics.

Watch out for the halfway house. Pseudonymisation — replacing the name with a customer number while you keep the key — is explicitly not anonymisation. Article 4(5) GDPR treats pseudonymised data as personal data. It is an excellent security measure, but it is not an answer to an erasure request.

Mind the context too. A single conversation that says "the engineer who was at the clinic on the high street last Thursday" has not become anonymous by removing a name. Anonymising is work, not a find-and-replace.

The sensible route for a split request: keep the part you must retain unchanged, erase the free part, and anonymise whatever you only wanted for figures or quality improvement.

How quickly must you respond, and what if you say no?

The clock sits in Article 12 GDPR. You must provide the data subject, without undue delay and in any event within one month of receiving the request, with information on the action taken on it. If the request is complex, or if there are many of them, you can extend that period — but you must notify the extension within that first month, together with the reason.

The Dutch Data Protection Authority translates this into plain language: the organisation must respond within one month and tell the person whether the requested information is coming, or that the request is being refused in whole or in part, and why. A "no" is therefore just as much a response that has to fall within the deadline, with reasons attached. You also tell the person that they can lodge a complaint with the Data Protection Authority and can go to court.

For an AI mailbox this is the real risk. The clock starts when the request arrives, not when you read it. An assistant that answers "delete my data" with a friendly stock sentence and closes the conversation lets the deadline run without anyone noticing. Make sure words such as erase, delete, forget, withdraw, object and access always reach a human being, with a timestamp attached.

What should you put in place now to be ready?

1. A map of your data. Per system: which customer data sits here, for how long, and who is able to delete it.
2. A retention period per type of data. Not one period stretched across everything. Business records follow the statutory period; loose conversation history, recordings and marketing data are periods you set and justify yourself.
3. A fixed route for requests. Who receives it, who decides, where the date is recorded, who sends the answer.
4. An identity check. Light, but present. Never act on an email address or phone number alone.
5. Standard wording for yes, partly and no. With the article named and, where a retention duty applies, the date on which the data does go.
6. Agreements with your supplier. In the processing agreement: erasure on instruction, within what period, including log files and backups, and what happens when the contract ends.
7. A log of requests. Date received, date answered, decision and ground. That log is your evidence that you handled it properly.

Anyone with those seven points in order has nothing left to work out when a request arrives. That does not only reduce risk; above all it saves time at the moment you have none.

Where does this go wrong in practice?

Three patterns keep recurring at businesses that put AI into customer contact.

The first is all or nothing. The owner refuses the entire request because part of it falls under a retention duty, or erases everything and loses records the law required them to keep. Both are wrong. Split the request.

The second is the silent refusal. Nobody replies, because it is awkward, or because the request disappeared into a busy channel. That is precisely what Article 12 forbids: a no must also arrive on time and with reasons.

The third is half-erasure. The customer is told everything has been deleted while their name still sits in the search index, the CRM summary or the transcript. That is an inaccurate statement about your own processing, and it surfaces sooner or later — usually in the next conversation, when the assistant greets them by name after all.

This page is general information about legislation and not legal advice. For your own situation — certainly in sectors with their own retention rules, such as healthcare and financial services — take advice from a lawyer who knows your file.