An erasure request must reach the derived copy
An erasure request may affect training extracts, retrieval indexes and stored AI outputs as well as the source record. Map the derived copies, assess their status and record the decision for each relevant location.
Keep development and test groups separate before comparing performance. No measured results are shown.
Consider a customer record copied into a retrieval index. Deleting it from the application database may leave the indexed passage available to an assistant. The request therefore needs an assessment of the processing chain, including derived copies that remain personal data.
Map the copies and transformations relevant to the request. Training extracts, embedding stores, caches, profiles, review queues and saved outputs can have different owners and retention rules. A source-table deletion cannot establish what happened elsewhere in that chain.
Follow the person, not the file name
The ICO’s AI and individual-rights guidance distinguishes personal data in training data, outputs and, in some cases, the model itself. The right to erasure is not absolute. The ICO also says that erasing an individual’s training data does not automatically require deleting every model trained on it, unless the model contains the data or it can be inferred from the model. The duty is to assess the actual processing and any applicable exception, not to choose between deleting everything and deleting only the source record.
That distinction makes data lineage operational. A derived representation may no longer look like the original row, yet still link to a person or reproduce their information. Conversely, a statistical model need not contain a recoverable copy of every training example. The team needs to know which artefacts remain personal data in its context and how a request can identify them.
Begin with the identifiers carried forward. Does a training extract retain an account key? Does a retrieval index retain document IDs that can be joined to the customer? Can a saved prediction be found through the profile to which it was attached? If a pipeline strips direct identifiers, record how it was tested for indirect identification and what additional information a requester could supply. The ICO notes that an inability to identify somebody in training data can change when the person provides information that makes identification possible.
Design a request as a traversal
Write a data map from source to extract, transformation, index, model, prediction and downstream action. For each node, record the purpose, owner, retention rule, identifier or lookup path, and whether deletion can be propagated. Where a supplier processes a node, record how it assists the controller. The ICO says a controller’s choice of a service that makes rights requests difficult does not remove its obligations.
Test a representative request against the map and record the locations checked, actions taken, applicable exceptions and remaining questions. A cleaned source may support a future index rebuild, but the organisation must also assess the current searchable copy. A model that contains personal data may require a different remedy from a model that does not.
Take a customer whose support conversation was copied into a search index and later quoted in a saved assistant answer. The request handler should start from the account record, follow the document identifier into the index and look for stored answers that refer to that document. Removing the source conversation does not remove a cached passage. Rebuilding the index next month does not settle whether the current index can still return it today.
The closure record should name the copy, action, owner and date for each location. It should also say where the organisation concluded that an item was outside scope or that an exception applied, with the reason available to the privacy lead. This is more useful than a single “deleted” flag because it shows which branches of the pipeline were actually visited. A processor’s confirmation should identify the affected service and version, not merely assert that it follows a deletion policy.
Review the request path when a pipeline changes. New caches, evaluation stores or derived profiles may create additional processing locations. The data-flow owner should update the inventory and test whether the request handler can reach them before relying on the existing closure process.
The earlier article on re-embedding as a migration asks how to preserve retrieval quality and version boundaries when vectors change. A rights request asks a different question: which person can still be represented or retrieved, and what processing must stop? The same inventory can support both, but the acceptance test is different.
The limit of the map
A lineage diagram does not decide whether erasure applies to a particular record, model or output. Identifiability, lawful basis, exceptions and the person’s actual request need legal and factual assessment. This article does not promise that a single technical deletion will settle those questions.
The data owner and privacy lead should be able to explain how a request travelled through the system and why each branch ended where it did. The lineage map supports that explanation, while the legal and factual assessment determines the remedy.