Right to Be Forgotten Across Data and Models

What does the right to be forgotten require?

Under the GDPR, individuals have a right to erasure of personal data in certain circumstances, and controllers must act without undue delay when it applies. It is not absolute: exceptions exist, for example where retention is required by law or needed for legal claims. Other regimes frame deletion differently. Canada's PIPEDA, for instance, centers on consent, accuracy, access and limits on retention, and provincial laws add their own provisions. Which rules apply to a given request is a question for counsel.

Why is AI harder?

Personal data in AI systems is copied, transformed and distributed. A single record can appear in a source table, a feature store, a training snapshot, evaluation sets, logs, embeddings and prompts. Beyond that sits a harder question: whether a trained model itself contains personal data, and what removal would mean. Researchers are working on unlearning methods, and regulators and courts are still forming views. Anyone who claims a settled answer should be questioned.

What can you do in practice?

Location	Typical action
Source systems	Delete or anonymize records; propagate to downstream copies
Features and training sets	Remove the subject and rebuild from the cleaned source on the next cycle
Vector stores and caches	Locate by source record key and delete embeddings and cached outputs
Logs and evaluation sets	Delete or redact within the stated retention period
Backups	Apply retention schedules; document handling until backups expire
Trained or fine-tuned models	Exclude from future training; retrain or fine-tune again where feasible; assess legal position

How do you reduce the problem before it starts?

• Record provenance: know which personal data entered which training set and on what basis.
• Apply minimization: keep identifiers and unneeded personal data out of training data.
• Prefer retrieval over training for personal or fast-changing information, since deletion from an index is tractable.
• Plan retraining cadence so exclusions take effect on a known schedule.
• Set retention limits for logs, prompts and evaluation data.
• Keep a register of decisions where full removal is not possible, with the reasoning and counsel's view.

A hypothetical walk-through

A telecom receives an erasure request from a former customer. This example is hypothetical, and the legal assessment comes first.

1. Legal confirms the request applies, with one retention exception for billing records.
2. The lineage graph lists every system holding the customer's data: CRM, a churn-model feature table, a support-transcript index, and logs.
3. Records are deleted or anonymized where permitted; the transcript embeddings are removed from the vector store.
4. The customer is excluded from the next training snapshot, and the churn model is scheduled for retraining.
5. The case file records what was done, what remains and why, ready for review.

The model retraining step is dated, not instant. Say so in the record.

Why does lineage decide the outcome?

Without data-to-AI lineage, every erasure request becomes a manual investigation. With it, the question "where did this person's data go?" is a query. Retrieval systems add indexes and caches that need the same treatment; see governing agents and RAG.

What should you tell the person who asked?

Clarity matters. Respond within the time your counsel advises, confirm what was done, and be honest about what could not be done and why. Where a model has been trained on data that cannot yet be removed, explain the steps you have taken, such as excluding the data from future training, and avoid claims that the model has been cleansed. An accurate, documented answer is more defensible than a confident one that cannot be verified.

How should you prepare before requests arrive?

Run a rehearsal. Pick a synthetic subject, seed their data into a test copy of your pipelines, and run the erasure process end to end. Note where it stalled: systems nobody owned, copies in analyst sandboxes, embeddings with no link back to source keys. Fix those gaps first. Agree service levels with the teams involved and put the process in the same case-management tool you use for access requests, so effort is not duplicated.

Finally, monitor the legal and technical picture. Regulator guidance, court decisions and unlearning research are all moving, and your approach should be reviewed on a schedule with counsel. What is acceptable documentation of a limitation today may need to be replaced by a technical fix tomorrow.

Where aerais fits

aerais builds privacy operations into data and AI systems: request intake, data mapping, deletion workflows that reach features and vector stores, and the records that show what happened. Our data governance practice covers privacy operations, and this capability is one of the five on The Chain. We do not offer legal advice or promise that trained models can be cleansed of personal data.

This article is for general information only and is not legal advice.