GDPR's data subject rights — including the right to erasure — apply to AI systems just as they apply to any other system that processes personal data. The difference is that AI pipelines scatter personal data across more places than a traditional application does: conversation histories, retrieval stores, embedded representations, audit events, and agent task logs can all contain information that belongs to an identifiable individual. Designing for GDPR compliance in an AI system means thinking through all of those surfaces before you need to respond to a deletion request.
Why AI Systems Complicate Data Subject Rights
Traditional applications store personal data in a small number of well-defined tables. When a deletion request arrives, you locate the records, delete them, and document the action. That model breaks down in AI systems for several reasons.
First, personal data enters AI pipelines indirectly. A user's name and preferences may appear in a prompt constructed dynamically, in a retrieval context fetched from a vector store, or in the message history passed to an agent. None of those locations is a simple row in a users table.
Second, AI systems generate derivative data. An agent that processes a support ticket may write a summary, a classification, and a suggested response — each of which may contain personal information from the original ticket. Erasing the source record does not automatically erase the derivatives.
Third, audit trails and interaction logs are themselves personal data. The record that a specific user sent a specific message at a specific time is information about that person. Comprehensive audit logging — which is a compliance requirement in its own right — creates a body of personal data that must itself be managed under GDPR retention and erasure rules.
None of this makes GDPR compliance impossible for AI systems. It does mean the design work needs to happen before you receive your first Article 17 request, not after. For a practical checklist covering AI-specific compliance obligations, see the AI agent compliance checklist for 2026.
The Data Subject Rights That Matter Most for AI Systems
GDPR grants data subjects six main rights. Four have the most direct engineering implications for AI systems.
Right of access (Article 15). Individuals can request a copy of all personal data you hold about them — not just their profile record but agent interaction logs, task histories, and any derived records that identify them.
Right to rectification (Article 16). Incorrect data must be corrected. In an AI context, rectifying source data may not automatically correct derived outputs an agent produced from it.
Right to erasure (Article 17). Personal data must be deleted when the subject requests it and one of the statutory grounds applies. This is the most technically demanding right for AI systems, and it is addressed in detail below.
Right to restrict processing (Article 18). Under certain conditions, you must stop processing a subject's data while retaining it. Real-time AI pipelines need a mechanism to honour these restrictions without full deletion.
Rights to portability (Article 20) and to object (Article 21) apply as well, requiring structured data export and a clear mechanism to stop processing for personalisation or targeting use cases.
Engineering for data subject rights means treating each as a first-class requirement at design time, not as an edge case to handle in support tickets.
What Right to Erasure Actually Requires
Article 17 requires erasure "without undue delay" when the subject withdraws consent, when the data is no longer necessary for the purpose for which it was collected, or when the data has been unlawfully processed, among other grounds.
"Erasure" does not necessarily mean deleting every bit. Regulators and technical guidance broadly accept two approaches:
Direct deletion. Locate and delete the records. This is straightforward for structured data in relational databases. It becomes harder for data spread across document stores, vector databases, caches, and backup sets.
Cryptographic erasure. Encrypt personal data under a per-subject key and destroy the key when erasure is requested. The ciphertext becomes permanently unreadable — functionally erased — even if it persists in physical storage. This approach is particularly useful for data that is expensive to locate and delete in every location, such as records in append-only audit logs or backup archives.
In practice, a robust approach combines both: direct deletion of plaintext records you can locate, and cryptographic erasure for encrypted records where key destruction achieves the same result. The key requirement is that you can demonstrate the data is unrecoverable — both to satisfy yourself and to document the action for regulatory purposes.
Designing Erasure Into Your AI System
Retrofitting erasure into a running AI system is expensive. A few design decisions made early make it significantly more tractable later.
Map personal data locations at design time. Before shipping, identify every place personal data can land: user records, conversation histories, agent task logs, retrieval stores, generated summaries, audit events. This map defines your erasure scope when a request arrives.
Use per-subject encryption where possible. Assigning each data subject a unique per-subject encryption key and encrypting their sensitive fields under it gives you a single-operation erasure path: destroy the key and the encrypted data becomes unrecoverable across every location that holds it.
Separate identity from content in audit logs. Audit logs must be tamper-evident for compliance, but they don't need full personal details in every record. Storing identifying attributes in a reference that can be erased separately leaves the event record intact with anonymized subject references.
Build a two-step confirmation into destructive operations. Erasure is irreversible. Requiring a second authorized operator to confirm prevents accidental deletion and creates an accountability record. The confirmation action and timestamp should be logged to the same tamper-evident trail as the erasure itself. For the tamper-evident audit trail design that makes this log trustworthy, see Audit Trails That Hold Up: Cryptographic Integrity.
Retention Policies and Data Minimization
Article 5(1)(e) of GDPR requires that personal data be kept "no longer than is necessary" for the purpose it was collected. For AI interaction data, this means setting and enforcing retention periods — not just enabling deletion on request but deleting data automatically when the period expires.
Different data categories have different defensible retention periods. Conversation histories may warrant a shorter period than billing records or security audit events. A single retention period applied to everything will either keep some data too long or discard data you still need.
Designing retention means categorizing your data, establishing a defensible period for each category based on processing purpose, and building automated enforcement so expiry results in actual deletion rather than a policy nobody implements. Keeping data indefinitely because it might be useful is the default for many systems and is generally not defensible under GDPR. The data residency and sovereignty guide for AI agents covers the related questions of where data is stored and which jurisdictional rules apply.
How Praesidia Is Designed to Support This
Praesidia's approach to GDPR erasure is built around the two-pronged technical design described above. The platform is designed to protect per-subject sensitive content under individual encryption keys. The erasure workflow — accessible through a platform administration surface — requires two authorized operators: one to initiate and one to confirm. On confirmation, the subject's key is destroyed and plaintext personally identifiable information is removed from the associated records. Authentication events tied to the subject cascade through the same process.
The audit trail that records the erasure itself is append-only and hash-chained, so the record of when erasure was initiated, who confirmed it, and when it completed is independently verifiable and cannot be quietly altered.
For retention, Praesidia is designed to support per-organization retention policies across event categories. Teams can configure explicit periods for each category, with records purged when the period expires rather than accumulated indefinitely.
These design decisions are intended to make the operational response to a data subject request tractable and documentable — not to replace the legal analysis your data protection officer needs to conduct on each request. Read how to audit AI agent activity for guidance on the audit trail practices that sit alongside erasure compliance, or see GDPR erasure and EU AI Act readiness for a combined treatment of erasure workflows and EU AI Act risk classification obligations.
Common questions
Does cryptographic erasure satisfy GDPR Article 17?
Regulatory guidance and technical consensus generally treat the permanent, irreversible destruction of an encryption key as equivalent to erasure of the data it protected, provided no unencrypted copy of the data persists elsewhere. The practical burden is demonstrating both that the key has been irreversibly destroyed and that you have located and handled all plaintext copies. Your data protection officer should confirm the approach for your specific data types and jurisdiction.
How do you handle erasure for data that has already been used to train or fine-tune a model?
This is an area where technical and regulatory guidance is still developing. If personal data was used in training, the trained model weights may reflect that data in ways that are not straightforwardly reversible. The current practical approach is to avoid using personal data in training without a clear lawful basis, to document what was used and why, and to be prepared to retrain or evaluate for removal if a deletion request cannot be satisfied by other means. This is one reason many teams prefer to keep personal data out of training pipelines entirely.
What should the audit record of an erasure contain?
At minimum: the identifier of the data subject, the date and time the request was received, the grounds for erasure, the date and time erasure was initiated, the identity of the operator who initiated it, the date and time it was confirmed, the identity of the confirming operator, and the scope of data that was erased. This record itself must be retained for long enough to respond to regulatory enquiry, but it should contain only the minimum necessary identifying information about the subject.