What is the right to be forgotten?
The right to erasure in engineering terms. Deleting the row is an afternoon's work; deleting everything derived from it — embeddings, summaries, edges, caches, logs — is the project, and you can only do it if you recorded what came from what.
The right to be forgotten is the popular name for the right of erasure, set out in Article 17 of the UK and EU GDPR. A person asks an organisation holding personal data about them to delete it; where no exemption applies, the organisation must, normally within a month, and must pass the request on to anyone it shared the data with.
The name comes from a 2014 Court of Justice ruling about search results, which is why many people still hear it as "take my name out of the index". The engineering obligation is broader and duller: whatever you hold about an identifiable person, in whatever store, you must be able to find and then remove.
Deleting the row is the easy part
Finding the record and issuing a delete is an afternoon's work. The difficulty is that the person is not only in that record. In any system that has done something with the data, they are also in:
- Embeddings computed from their records, which cannot be found by name because they are vectors.
- Summaries, rollups and generated descriptions written over those records, each personal data in its own right once it can be traced to a person.
- Graph edges linking them to a company, a ticket, a deal, a colleague.
- Caches, queues, search indexes and request logs, each holding a copy with its own lifetime.
- Backups, which hold everything, by design.
None of it is reachable from a foreign key, and a delete that leaves the derivatives produces a system that still answers questions about somebody who has been erased.
Erasure is a provenance capability before it is a privacy one
Deletion can only propagate if something recorded what was derived from what. An embedding with no record of the row it came from is undeletable in practice; so is a nightly summary mentioning a customer, unless something wrote down which records it read. Provenance is normally sold as a way to check an answer. It is also the only thing that makes an erasure complete.
The consequences are architectural rather than legal. Derived artefacts are far easier to erase when they live beside the row they came from — a column on the record rather than a separate vector store to sweep. Every derived fact should carry the source record's identifier, not merely a label naming the system. And lineage has to be captured at write time by every path that writes; a pipeline that did not capture it cannot have it added later.
The exemptions, and why "delete everything" is the wrong default
Erasure is not absolute, and a system that deletes whatever it is asked to delete will eventually breach a different obligation. Article 17(3) carves out processing necessary for a legal obligation, for legal claims, for public-interest archiving and research, and for freedom of expression. Tax, employment and anti-money-laundering rules impose retention periods that outlast any request, and a contract you are still performing is not erasable because one party asked.
The sharpest version of the tension is with audit and record-keeping. An audit log exists precisely because it does not change, and erasure asks you to change it. The practical resolution is to hold almost nothing erasable in it — a verb, an actor, a timestamp, and the before and after of whatever changed, not content and not the person's own words — and then to keep the record of the erasure itself. An erasure that deletes its own evidence cannot be proved to have happened.
What a defensible erasure produces
Deletion cannot be tested by repeating it, so it has to carry its own proof: a preview of what the identifier actually reaches; a count per store rather than a single success flag; a verification pass run after the deletes and before the work is committed, so a claim that nothing remains was checked rather than assumed; and a receipt holding no erased content, since a receipt quoting what it deleted has recreated it.
Where erasure stops
Erasure stops at the boundary of what you control. Upstream systems are untouched: if the person is still in the CRM or the mailbox, the next sync records them again, so the source has to go first. Backups hold the data until they age out, and requests already sent to a model provider fall under that provider's retention. Content-free fingerprints — a hash kept so the same thing is not processed twice — hold nothing to erase and cannot be searched by name. And an identifier too short to search safely is a real gap rather than a bug: a two-letter alias matches so much unrelated text that erasing on it would take other people's records with it.
One more cost is worth naming. Erasure is the only operation that genuinely destroys history, so it sits against bitemporal storage and every audit guarantee built on it. A record removed for a person is gone from every date, including dates you may later be asked about.
Memtro treats this as one workflow rather than a delete endpoint: a search showing what is held about a person before anything goes, erasure across entities, relationships, facts, recorded values, conversations and cached tool results, verification inside the same transaction as the deletes, and a downloadable receipt. Search and erase a person's data sets out which stores are reached and what erasure cannot touch.