Deleting a customer record can take one database statement. Proving that the same information no longer affects retrieval, cached answers, evaluation sets, model releases, analytics exports, processors or restored backups is a systems problem. The visible record is only the root; AI pipelines create derived objects whose names and owners may no longer resemble it.
The operating decision is which deletion claim applies to each copy or derivative, how quickly it must stop influencing service, and what evidence proves completion without retaining the deleted content. “Deleted” should be a declared state with a scope and test, not a success message returned by the first system in the chain.
The regulatory guidance, standards and research linked below provide the source facts. The propagation graph, state model, evidence receipt and worked example are AIEngine's engineering synthesis. They are not legal advice, and they do not assume that every request requires erasure or model retraining.
Decide the request before executing it
Deletion can begin with a valid data-subject request, a contract ending, a correction, a withdrawn consent, an expired retention period, a security incident or a poisoned training item. Those triggers are not interchangeable. First record the object, authority, purpose and exceptions that define the request.
The UK Information Commissioner's Office says the right to erasure is not absolute and lists circumstances in which it applies and exemptions such as legal obligations and legal claims. Its right-to-erasure guidance also says organisations may need to notify recipients and address backups. An operator should therefore resolve these questions before a destructive job runs:
- What exact data, person, tenant, document or event is in scope?
- Is the instruction erase, correct, restrict, anonymise, expire or preserve under a hold?
- Which controller, processor, system owner or data steward may approve it?
- Which current uses must stop immediately, and which retained copies have a lawful reason and deadline?
- What must remain as minimal evidence of the decision?
A hold should not silently turn into “nothing happened”. It is a separate result with its authority, affected scope, review date and processing restrictions. Likewise, taking data offline is not necessarily deletion: the ICO's storage-limitation guidance distinguishes permanent deletion from offline storage and notes that pseudonymised data can still be personal data.
Follow derivation, not storage names
Build a propagation graph from the source item to everything produced from it. A useful edge names the transformation, system, version, owner and deletion behaviour. The graph may include parsed text, OCR, chunks, embeddings, indexes, features, summaries, cached outputs, evaluation cases, fine-tuning examples, model releases, exports, replicas, processors and backups.
The W3C PROV-O Recommendation models entities, activities, agents and derivation, including the relationship wasDerivedFrom. A deletion service does not need to adopt RDF to use that idea. It does need stable identities and traversable relationships. The AI dependency inventory can supply the system and release layer; the deletion graph adds item-level lineage and removal semantics.
Do not discover the graph during a request. Emit lineage when a pipeline creates a derivative. For a RAG document, retain a non-content source identifier and version on every chunk and vector. For a training build, preserve the immutable dataset manifest used by the release. For an export, record recipient and purpose. If a system cannot answer which source items produced an object, its deletion state is unknown rather than complete.
Give every layer an honest deletion state
One boolean cannot describe a distributed deletion. Use states that match what a system can actually guarantee.
| Layer | Immediate safe state | Completion evidence |
|---|---|---|
| Authoritative record | Restricted or removed from active use | Targeted lookup is absent or access is denied under the recorded rule |
| Parsed text, chunks and features | Tombstoned by source identity | Manifest query returns no active derivatives |
| Retrieval index and embeddings | Excluded from serving, then physically removed or rebuilt | Direct ID lookup and adversarial semantic queries return no scoped item |
| Response and semantic caches | Invalidated across every key variant | Old keys miss and cannot be repopulated from a deleted source |
| Evaluation and training corpora | Quarantined from future builds | New immutable manifests exclude the item and dependent snapshots |
| Deployed model | Assessed: unaffected, suppressed, unlearned or replaced | Named method and release-specific evaluation, not a database receipt |
| Replicas, processors and exports | Notification sent, completion pending or confirmed | Recipient acknowledgement and due date |
| Backups | Beyond use until scheduled overwrite | Restore test reapplies the tombstone before service exposure |
Serving exclusion is often the first safety target because physical compaction or rebuild may take longer. Caches deserve their own branch. HTTP's RFC 9111 requires invalidation of a target URI after a successful state-changing request; AI systems should carry the same consistency principle into semantic caches and materialised answers even though the RFC does not define those products. A deletion event should invalidate keys derived from tenant, source version, prompt package, policy version and model release, not merely the obvious URL.
Treat retrieval removal as a tested behaviour
Deleting the source document does not remove an orphaned vector. Deleting a vector ID may still leave duplicate chunks, an older index generation or a cached answer. The enterprise RAG audit already separates corpus, permission, retrieval and answer tests; deletion should reuse those boundaries.
For each scoped source, test three routes:
- exact source and derivative identifiers no longer resolve in the serving index;
- distinctive phrases and paraphrased semantic queries do not retrieve the content from any active generation; and
- an answer assembled after deletion cannot cite, quote or rely on the removed material.
Keep a known-safe negative fixture so the test distinguishes successful removal from a broken retriever. Then attempt a rollback or restore in a non-production environment. If the deleted item returns, the backup is not yet beyond use and the restore procedure needs a suppression ledger.
Separate model unlearning from row deletion
Removing a training row and removing its influence from a trained model are different claims. The European Data Protection Board's Opinion 28/2024 on AI models says whether a model trained on personal data is anonymous requires a case-by-case assessment. It also discusses retraining as a possible remediation for unlawful processing and identifies erasure, suppression and unlearning measures in its analysis. That does not create one universal retraining rule; it makes a blanket “models contain no personal data” assertion unsafe.
Research also argues against a one-button promise. The original SISA machine-unlearning paper reorganised training into shards and slices to reduce the cost of retraining affected parts. More recent MUSE evaluation research tested forgetting, privacy leakage, retained utility, scale and repeated requests, and found serious trade-offs among the evaluated language-model methods.
Choose a model response from evidence:
- No model action: the item never entered the release's training or adaptation manifest.
- Output suppression: a bounded interim control prevents reproduction while a stronger remedy is assessed.
- Rebuild or retrain: the affected release can be reproduced without the item.
- Validated unlearning: a declared method passes forgetting, leakage and retained-utility tests for this case.
- Retire the release: provenance or evidence is too weak to defend continued use.
Never equate inability to reproduce a string with proof that influence is gone. Conversely, do not trigger expensive retraining merely because an item once passed through a non-learning inference path. The model-release record and the change-control baseline should show which dataset and adaptation package actually shaped the deployed behaviour.
Work a hypothetical RAG erasure
Consider a hypothetical internal policy assistant. An employee's free-text accommodation note was mistakenly ingested with a shared handbook, producing parsed text, six chunks, embeddings, an evaluation example and cached answers. The note was not used to fine-tune the base model. This is a design example, not an AIEngine deployment.
After the organisation validates the erasure decision, the coordinator issues one immutable event. The application immediately restricts the source and invalidates affected answer caches. The ingestion service traverses the source version to its chunks and vectors, tombstones them, and rebuilds the active index generation. The evaluation registry removes the case from future suites but preserves a content-free record that a case identifier was withdrawn. The model registry proves from its dataset manifest that no deployed model action is required.
The request is not marked complete while the analytics export, processor acknowledgement and backup overwrite remain unresolved. Those branches receive deadlines. A restore drill must load the suppression ledger before the recovered index can accept traffic. Completion occurs only when every required branch is confirmed, explicitly exempted or still represented as a visible pending state.
Prove completion without rebuilding the deleted record
A deletion receipt should explain the decision without becoming a new copy of the sensitive content. Retain only what accountability requires: event ID, pseudonymous subject or object reference, request type, authority, scope graph version, system branches, state transitions, exceptions, deadlines, verifier, release impact and evidence locations.
Keep content hashes only when they are necessary and safe; a predictable value may still enable guessing or linkage. Store evidence separately from the operational data path, with narrow access and its own retention rule. The privacy-safe incident replay offers the same principle: joined identifiers and control decisions can support reconstruction without defaulting to indefinite prompt or content capture.
NIST's Privacy Framework frames privacy risk across the complete data lifecycle from collection through disposal. Apply that lifecycle to the receipt itself. Evidence that proves deletion today should not become unjustified personal data tomorrow.
Measure resurrection, not ticket closure
Track the time from approval to serving exclusion, full propagation and backup expiry separately. Also measure incomplete branches, processor overdue rate, orphan derivatives, cache reappearance, restore-test resurrection, releases without immutable training manifests, unlearning test failures and deletion events reopened after verification.
Revisit the design when a new pipeline, cache, index generation, processor, training route or backup class appears. Sample completed events and attempt retrieval from each live path. A zero-error dashboard is not persuasive if the graph omits the system most likely to hold a copy.
The practical standard is not instant physical disappearance everywhere. It is an honest, bounded claim: stop prohibited influence quickly, trace every derivative, expose pending and exempt branches, validate model remedies separately, prevent restoration and keep minimal proof. Deletion is complete only when the system can show what stopped, what remains, why, until when—and why the data cannot quietly return.
