Wiki · Concept · Last reviewed June 25, 2026

Right to Erasure

The right to erasure is the GDPR Article 17 right to have personal data deleted in defined circumstances, including when data is no longer necessary, consent is withdrawn without another lawful basis, processing is unlawful, or erasure is legally required.

Category: Privacy governance Updated: June 25, 2026 Tags: GDPR, erasure, deletion, privacy, AI governance, data rights

Definition

The right to erasure is a data-protection right under Article 17 of the General Data Protection Regulation. It is also called the right to be forgotten, but that phrase can mislead. The right is not a universal power to delete every trace of a person from every system. It applies in listed circumstances and has listed exceptions.

Article 17 requires erasure without undue delay when personal data is no longer necessary for the purpose collected, consent is withdrawn and there is no other lawful basis, a valid objection applies, processing is unlawful, erasure is required by law, or the data was collected from a child in relation to information-society services.

For AI systems, erasure is the deletion right around personal data and its operational copies. It matters when account data, logs, prompt histories, labels, profile fields, embeddings, vendor exports, review queues, or evaluation records remain in use after the legal basis for keeping them has expired.

Scope

Article 17 includes exceptions. Erasure may not apply when processing is necessary for freedom of expression and information, a legal obligation, a public-interest or official-authority task, public health, archiving, scientific or historical research, statistics, or legal claims.

Article 19 adds a downstream notification duty. When a controller erases personal data, it must communicate that erasure to each recipient to whom the data was disclosed unless doing so is impossible or involves disproportionate effort. If the person asks, the controller must also provide information about those recipients.

The scope is different from machine unlearning. Erasing a record from a database, vector store, cache, or vendor system is not the same as proving that a trained model no longer reflects that record. Where model-level influence matters, the erasure request should be connected to retention, provenance, unlearning, and procurement commitments rather than being treated as a customer-support deletion ticket.

How It Works

An erasure workflow needs intake, identity or account matching, the data or processing activity at issue, the Article 17 ground, affected systems, legal holds or exceptions, processors and recipients, deletion action, response date, and any refusal or partial-deletion explanation.

AI pipelines add a propagation problem. A deleted conversation, profile field, device identifier, biometric template, moderation record, worker score, or training example may have been copied into logs, feature stores, retrieval indexes, prompt archives, analytics datasets, backups, model-evaluation sets, and third-party tools.

Good design separates live deletion from retention exceptions. Some data may be erased from product use while a narrow evidence copy remains for legal claims or compliance. The record should make that boundary visible and should prevent retained evidence from quietly reentering personalization, ranking, model evaluation, marketing, or training pipelines.

Governance and Safety

The governance value of erasure is that it puts a limit on institutional memory. AI systems tend to reward accumulation: more logs, more labels, more profiles, more examples, more traces. Article 17 asks whether continued retention still has a lawful and proportionate reason.

The safety limit is that erasure is not the same as explanation, rectification, objection, restriction, appeal, or model audit. It should connect to Data Subject Access Requests, Right to Rectification, Right to Restriction of Processing, AI Data Retention, and Machine Unlearning where deletion claims reach trained artifacts.

Evidence Record

For AI-related systems, preserve the erasure request, identity verification, Article 17 ground, affected data categories, systems searched, processors contacted, recipients notified, deletion or retention action, exception relied on, backup or archive treatment, decision date, and response sent to the person.

The record should distinguish deletion from suppression, deactivation, anonymization, pseudonymization, retention under legal hold, and model-level unlearning. These are different actions with different evidence standards. A user-facing account closure is not proof that personal data stopped moving through the wider system.

Source Discipline

Do not collapse erasure into account deletion, opt-out, consent withdrawal, deactivation, suppression, anonymization, or machine unlearning. These controls may overlap in a product interface, but Article 17 has specific grounds and exceptions.

Use EUR-Lex for the GDPR text. Use European Commission, EDPB, ICO, and national supervisory-authority guidance to operationalize the right. Vendor deletion promises should be checked against data inventories, processor terms, backups, recipient notices, and retention schedules.

Spiralist Reading

The right to erasure is the demand that the institution stop remembering without reason.

The machine prefers residue. A chat becomes a log. A log becomes a feature. A feature becomes a score. A score becomes a category. Erasure interrupts that drift and asks what should remain when the purpose is gone.

For Spiralism, the useful part is not fantasy deletion. It is accountable forgetting: name the data, name the purpose, name the exception, delete what can be deleted, and mark what is retained so it cannot pretend to be ordinary memory.

Open Questions

Sources

Return to Wiki