DocsSign inJoin the beta
All articles
GDPR erasure

Does the right to erasure apply to what a company AI learned about you?

A former customer exercises her right to erasure, and legal answers for the CRM and the mailbox. The AI plugged into those same tools is rarely part of that answer, until it has to be.

By Alexis PratSeptember 11, 20265 min read
The short answer

Partly. A GDPR erasure request covers everything your Kastel holds about the person concerned: their raw copies, the index built from them, and any fact an AI had drawn from them comes back for human review. It does not reach the sealed audit chain that proves the operation happened, your backups outside Kastel, or the source system itself for as long as it still holds the document.

What legal handles, and what nobody thinks to handle

A former customer writes to your company one day asking for her personal data to be erased, under Article 17. Legal answers within days for the systems it knows by heart: the CRM, billing, the mailbox. Nobody thinks, on their own, of the AI assistant that customer support plugged into those same tools last year.

That is not negligence. That assistant never had a folder labelled “this person’s data”. It read scattered copies across several connectors, kept answers that mention her, built up a history of questions asked about her. None of that has an obvious owner, and an AI that answers wrong with confidence about someone the company believed it had erased is a far costlier incident than a missed administrative step.

A company that only handles the systems it can name has half-answered an erasure request, and the missing half is exactly the one a regulator looks at first.

Two requests that get merged, and should not be

“Cut this person’s access” and “she is exercising her right to erasure” sometimes land the same day, and they do not call for the same answer. Cutting access - an employee’s, when they leave - erases nothing: what that person wrote stays, because that knowledge belongs to the company, not to them. We cover that exact gesture, what it removes at once and what it deliberately leaves in place, in when someone leaves, what happens to what they knew.

A GDPR erasure is a different request, and it is often raised by someone outside the company: a customer, a candidate who was not hired, a former employee coming back to her own personal data after leaving. It is not about an access to remove, but a trace to make disappear. Merging the two into one gesture produces the wrong answer every time: either you erase company knowledge that never belonged to the person, or you believe you have answered an Article 17 request by resetting a password.

A human decision, never a silent automation

When a document disappears at its source - a file removed from a shared drive, a message deleted in a mailbox - your Kastel does not delete its own copy on its own initiative. It flags it in a queue of pending deletions, reserved for owners and administrators, and waits for an explicit decision: erase it for good, or do not erase it. An automation that deleted everything by itself would be as dangerous as one that never deleted anything at all.

For an actual GDPR erasure naming a person, a mailbox, or an entire connector, a separate lever covers everything in one pass: raw copies, the question history, feedback left on answers, the consultation record, and work traces attributed to that person. The operation is sealed into your audit chain, with the name of whoever requested it, never the content of what was erased.

A nuance few products settle honestly: a department can place a hold on one of its own pages to protect it from deletion or rewriting, for its own retention reasons. That hold never blocks a GDPR erasure, and a GDPR erasure never lifts that hold as a side effect. These are two mechanisms answering two different questions, and neither overrides the other by accident.

Document disappeared at its sourceFlagged in the pending queueDecision: erase, or do not eraseSealed into the audit chain
An erasure decision, like every decision in your Kastel, gets sealed into the audit chain rather than disappearing silently.

Check it yourself, before a real customer asks

None of this should be evaluated on a live request. Kastel’s core installs for free on your own infrastructure. Create a fictional person, let a test connector read a handful of documents that mention her, ask the plugged-in AI a question about her, then trigger a full erasure for that person.

Then check your audit chain: the operation is there, sealed, with its author and its date. Separately, delete a document elsewhere in the test connector, and watch the pending-deletions queue flag it instead of letting it vanish silently. The full detail of the screens and commands lives in the GDPR erasure guide.

An erasure policy that holds up to a regulator

A regulated account needs more than a local audit chain: a signed attestation you can check without taking our word for it, and a compliance file built decision by decision. That is what the Enterprise plan adds.

See the Enterprise plan