compliance

Right to Erasure Under GDPR: Engineering Obligations for AI Products

A GDPR right allowing individuals to request deletion of their personal data, requiring software systems to implement comprehensive data deletion capabilities.

The right to erasure, sometimes called the right to be forgotten, is one of the more technically demanding obligations that GDPR places on AI product teams. Under Article 17, individuals can request that their personal data be deleted, and organisations must act on that request within one month in most cases. This obligation applies under both UK GDPR, which retained the EU framework post-Brexit and is enforced by the Information Commissioner's Office in the UK, and EU GDPR, which applies when you process personal data of people in EEA member states. The ICO has been increasingly active in pursuing organisations that fail to respond to data subject requests on time, issuing enforcement notices and financial penalties to companies of all sizes including early-stage startups. For a traditional database-backed SaaS product, erasure is an engineering challenge but a soluble one: find the records, delete them, confirm deletion. For AI products that have logged prompts containing personal data, indexed personal information in vector stores for retrieval-augmented generation, or incorporated user data into fine-tuned model weights, the challenge is materially harder and requires architectural decisions made early to remain manageable. SpeedMVPs, based in Hemel Hempstead, scopes erasure-ready data architecture into AI MVPs delivered in 2 to 3 weeks at a GBP 8,000 fixed price with full code ownership, so clients are not retrofitting deletion workflows under regulatory pressure after launch. This guide explains the right to erasure precisely, when it applies, the technical obligations it creates, and how to build AI systems that can handle deletion requests without painful retrofitting.

When the Right to Erasure Applies

GDPR Article 17 gives individuals the right to obtain erasure of their personal data without undue delay when one of six grounds applies. The most common grounds for an AI product are: the personal data is no longer necessary for the purpose for which it was collected, the individual withdraws consent and there is no other lawful basis for processing, or the individual objects to processing based on legitimate interests and the organisation has no overriding grounds. The right is not absolute. It does not apply where processing is necessary for compliance with a legal obligation, for the establishment, exercise, or defence of legal claims, or for archiving purposes in the public interest. For AI products, the relevant exceptions are narrow. A backup retention policy does not automatically exempt data from erasure. A legitimate interest claim does not survive simply because deletion is inconvenient. The default position is that a valid erasure request must be acted on, and the burden of demonstrating an exception falls on the data controller, not the individual making the request.

The Database Deletion Problem

Erasure from relational databases is the most straightforward component of right to erasure compliance. The technical steps are identifiable: find all tables containing the user's personal data, delete or anonymise the relevant records, cascade deletions through foreign key relationships, purge soft-delete records from backup cycles within a reasonable window, and confirm deletion to the user. The implementation challenge is completeness. Personal data in a SaaS product tends to scatter across more tables than developers initially expect. User records, audit logs, event tables, analytics tables, email logs, support ticket records, billing records, and exported files all potentially contain personal data that must be addressed by an erasure request. Building a data map that traces where personal data flows within your product is a prerequisite for implementing reliable erasure. Without a data map, deletion requests will always be partially incomplete, which is a compliance risk.

Vector Databases and Prompt Logs

The hardest erasure problems in AI products involve vector stores and prompt logs. If your RAG system has indexed documents uploaded by or about a specific individual, you need to be able to identify and delete those vectors by user identifier. Most vector databases support filtered deletion by metadata field, which means you need to have stored a user identifier as document metadata from the moment you indexed the content. If you indexed documents without user-level metadata, retrospective deletion becomes very difficult. Prompt logs present a similar challenge. If your AI product logs conversation history for evaluation, debugging, or fine-tuning purposes, those logs may contain personal information the user included in their prompts. You need to be able to retrieve and delete all prompt logs associated with a specific user identifier. Log retention policies should define how long prompt logs are kept and include automated deletion at the end of the retention period. An erasure request should trigger immediate deletion of all logs attributable to the requesting user, not just waiting for the next scheduled purge.

Fine-Tuned Models and Training Data Deletion

The most technically intractable erasure problem in AI is the right to erasure applied to data that has been used to train or fine-tune a model. If a user's personal data was included in a fine-tuning dataset, deleting it from your systems does not remove the learned patterns from the model weights. Technically, it is currently not possible to surgically remove the influence of a specific training example from a trained model without retraining the model from scratch or from a checkpoint that predates inclusion of that data. The ICO has acknowledged this technical reality in its guidance on AI and data protection. The practical compliance position is that you should document the limitation, demonstrate that personal data cannot be extracted from the model in identifiable form, ensure the model does not reproduce personal data from training in its outputs, and delete the training data from your source systems. If you intend to fine-tune on personal data, conducting a DPIA before you start is strongly advisable, and your data retention policy for training data should be agreed before fine-tuning begins.

Building Erasure Into Your Architecture

The key to making right to erasure manageable is treating it as an architecture requirement from the first sprint rather than a compliance retrofit. Every table or collection that stores personal data should have a clear user identifier that enables filtering. Vector store document indexing should include a user or customer identifier in document metadata. Prompt logs should be keyed by user ID. Backup and archive cycles should have defined retention limits. Deletion request workflows should be defined in your product requirements, not added in response to a user complaint. A data map documenting every location where personal data is stored should be maintained as a living document updated whenever new data flows are introduced. When SpeedMVPs scopes AI products, data flow and erasure architecture are considered during discovery, ensuring the product is built with user data keyed and tracked in ways that make deletion requests technically executable.

Responding to Erasure Requests: Process and Timelines

Under UK GDPR and EU GDPR, organisations must respond to erasure requests without undue delay and within one month of receiving the request. The month can be extended by two further months in cases of complexity or multiple requests, but the individual must be informed of the extension within the first month. The response must either confirm that erasure has been completed or explain which exception applies and why. ICO enforcement of response timelines has been increasing, with fines and enforcement notices issued for failures to respond to data subject requests in time. Building an erasure request workflow into your product, even if it is initially handled manually by your team, is essential. As volume grows, automate the workflow. The response should be documented internally with a record of what data was deleted, what was retained and on what legal basis, and when the deletion occurred. This documentation is your evidence in the event of an ICO investigation.

Frequently Asked Questions

Do we have to delete data from backups immediately when we receive an erasure request?+

Not immediately from all backups, but your backup retention policy must have a defined limit, and personal data in backups must not be restored into live systems after an erasure request has been completed. The ICO's position is that it is acceptable for backup deletion to follow your normal backup rotation cycle, provided that cycle has a defined end point and personal data is not actively used from those backups. You should document in your privacy notice that data may persist in backups for a defined maximum period, for example 30 or 90 days.

What if someone's personal data is mixed into shared content in our system?+

Where personal data is intertwined with data of other users or organisational data, you may need to anonymise rather than delete. Anonymisation under GDPR means the data can no longer be linked to an identifiable individual by any reasonable means. Pseudonymisation, where a key exists to re-identify the data, does not satisfy erasure. If you replace a user's name with an anonymised token in a shared document or audit log, you have effectively erased their personal data if the token cannot be traced back to them without a key that you also delete.

How do we handle erasure requests for data in vector databases?+

Vector databases like Pinecone, Weaviate, and pgvector support filtered deletion by metadata fields. The requirement is that you indexed documents with a user identifier or customer identifier in the document metadata at the time of ingestion. A deletion request then becomes a filtered delete operation on all vectors where the user ID metadata matches the requesting user. If you did not store user identifiers in metadata, you may need to maintain a separate index mapping document IDs to user IDs to enable deletion. Implement this from the start of your RAG architecture.

Can we refuse an erasure request because it would degrade our AI model?+

No. Model performance is not a recognised exception under Article 17. If the personal data is no longer necessary for the stated purpose, or if the individual withdraws consent, you must act on the erasure request regardless of the impact on model quality. If your model was fine-tuned on personal data and you cannot remove that data from the model weights, document the technical limitation in your DPIA, delete the data from your source systems, and demonstrate that the model does not reproduce identifiable personal data in outputs. The ICO expects honest engagement with the technical constraints, not refusal on commercial grounds.

What is the ICO's position on AI systems and right to erasure?+

The ICO has published guidance specifically addressing AI and data protection, including the right to erasure. The ICO acknowledges that certain technical implementations, particularly trained model weights, create practical limits on what erasure can achieve. Their position is that organisations must implement privacy by design, conduct DPIAs before deploying AI systems that process personal data at scale, and have documented responses to the known technical limitations. Simply saying it is technically impossible is not sufficient without accompanying evidence that personal data cannot be extracted and that source data has been deleted.

Building an AI product that needs to handle GDPR data subject rights from day one? We architect erasure-ready systems during the initial build. Get a free consultation at speedmvps.co.uk

Get a Free Quote