How to Handle Right-to-be-Forgotten in AI Memory
Why Erasure Is Hard in AI Memory Systems
In a traditional database, deleting a customer's data means running DELETE WHERE customer_id = X across the relevant tables. In an AI memory system, personal data exists in multiple forms across multiple storage layers. The original memory text is stored as a document or record. Vector embeddings are generated from that text and stored in a vector index. Entities extracted from the text become nodes in the knowledge graph, connected by relationship edges to other entities. Query results that included the memory may be cached. Consolidated memories may have merged the person's data with other information. Each of these layers must be addressed during erasure.
The fundamental challenge is that AI memory systems are designed to connect information, not to isolate it. When a memory about "customer Sarah who uses the premium plan and has integration issues with Salesforce" is stored, the system extracts entities (Sarah, premium plan, Salesforce), creates relationships (Sarah uses premium plan, Sarah has issues with Salesforce integration), and generates embeddings that encode the semantic content. Erasing Sarah means unraveling all of these connections without destroying the organizational knowledge about the premium plan's Salesforce integration that other memories may also reference.
Step-by-Step Process
Verify the identity of the person making the erasure request. GDPR requires you to process erasure requests but also requires you to verify identity to prevent unauthorized deletion. Accept requests through your established data subject rights channel (typically a web form, email address, or in-app interface). Confirm the requester's identity through the same authentication method they used to create their account, or through an alternative identity verification process if they cannot authenticate. Log the request immediately with a timestamp, because GDPR gives you 30 days to complete the erasure, and the clock starts at receipt.
Search every storage layer for data relating to the requesting individual. This means: searching memory content for the person's name, identifiers, and known aliases; querying the data subject index (if you tagged memories with data subject identifiers at ingestion, as described in the GDPR compliance guide); checking the knowledge graph for entity nodes that represent the individual; and searching for cached or pre-computed results that reference any of the identified memories. Create a manifest of everything found before starting deletion, because you need to verify completeness afterward.
def identify_affected_data(data_subject_id):
manifest = {
"memories": [],
"embeddings": [],
"graph_nodes": [],
"graph_edges": [],
"cache_entries": []
}
memories = search_by_data_subject(data_subject_id)
manifest["memories"] = [m.id for m in memories]
for memory in memories:
manifest["embeddings"].extend(
get_embedding_ids(memory.id))
nodes = find_graph_nodes_for_subject(data_subject_id)
manifest["graph_nodes"] = [n.id for n in nodes]
edges = find_edges_involving_nodes(
[n.id for n in nodes])
manifest["graph_edges"] = [e.id for e in edges]
cache_keys = find_cache_references(
manifest["memories"])
manifest["cache_entries"] = cache_keys
return manifestDelete in the correct order to avoid orphaned references. Start with cached results (they reference memories that are about to be deleted). Then delete knowledge graph edges (they reference nodes that are about to be deleted). Then delete knowledge graph nodes for the data subject. Then delete vector embeddings (they are derived from memory content that is about to be deleted). Finally, delete the memory content itself. Execute this as a transaction where possible, or implement compensating actions if any step fails so that a partial deletion is retried rather than left incomplete.
def execute_erasure(manifest):
results = {"deleted": {}, "errors": []}
try:
results["deleted"]["cache"] = purge_cache(
manifest["cache_entries"])
results["deleted"]["edges"] = delete_graph_edges(
manifest["graph_edges"])
results["deleted"]["nodes"] = delete_graph_nodes(
manifest["graph_nodes"])
results["deleted"]["embeddings"] = delete_embeddings(
manifest["embeddings"])
results["deleted"]["memories"] = delete_memories(
manifest["memories"])
except Exception as e:
results["errors"].append(str(e))
schedule_retry(manifest, results)
return resultsSome memories contain personal data about the requesting individual mixed with organizational knowledge or personal data about other individuals. "Sarah and James reviewed the Q3 roadmap and decided to prioritize the checkout refactor over the payment migration" contains personal data about both Sarah and James, plus organizational knowledge about the Q3 roadmap decision. If Sarah requests erasure, you have three options: delete the entire memory (simplest, but loses organizational knowledge and James's data), redact Sarah's personal data while preserving the rest ("A team member and James reviewed the Q3 roadmap..."), or determine that the organizational knowledge is not personal data and can be retained without the personal elements. The right choice depends on your privacy policy and how intertwined the personal data is with the organizational content.
After executing all deletions, run verification queries to confirm that no traces of the data subject remain. Search memory content for the person's name and identifiers. Check the vector index for any embeddings that were missed. Query the knowledge graph for any nodes or edges that reference the individual. Check the cache for any stale entries. If any references are found, investigate why they were missed (they may be in consolidated memories that were not tagged with the data subject identifier) and delete them.
Log the completed erasure in the audit trail. The audit record must document that an erasure request was received, when it was received, when it was completed, how many records were affected across each storage layer, and whether the erasure was complete or partial (and if partial, why). Critically, the audit record must not contain the deleted personal data. Record the data subject identifier (which becomes orphaned after deletion) and the categories of data deleted, not the data itself.
Preventing Future Accumulation
After processing an erasure request, prevent the system from re-accumulating data about the individual. If the person continues to interact with your service under a different identifier, or if team members store new memories that mention the person, the erasure is effectively undone. Implement a blocklist of erased data subject identifiers that the ingestion pipeline checks before storing new memories. When a new memory mentions a blocklisted individual, either reject the storage or automatically redact the personal data before storing.
Adaptive Recall handles right-to-be-forgotten requests through a single API call that cascades deletion across all storage layers, including embeddings, graph connections, and cached results. The system verifies completeness automatically and logs the erasure in the audit trail without retaining deleted content. Blocklist support prevents re-accumulation after erasure.
Handle erasure requests with one API call. Adaptive Recall cascades deletion across every storage layer and verifies completeness automatically.
Get Started Free