--- title: "The right to be forgotten in AI agent memory" description: "GDPR Article 17 gives people the right to be forgotten. What erasure means for AI agent memory, where derived facts hide, and how deletion by source works." canonical: https://past.dev/guides/gdpr-memory-deletion last-updated: 2026-09-02 --- # The right to be forgotten in AI agent memory Source: https://past.dev/guides/gdpr-memory-deletion The right to be forgotten, Article 17 of the GDPR, lets a person require erasure of their personal data without undue delay. For AI agent memory the request has three parts: delete the person's source records, delete the facts derived from them, and leave everything else intact. Deletion by source achieves this: removing a source erases the facts that only it supported, while facts corroborated by other sources remain, because they have other support. ## What Article 17 requires Article 17 of [Regulation (EU) 2016/679](https://eur-lex.europa.eu/eli/reg/2016/679/oj) obliges a data controller to erase personal data without undue delay when one of its grounds applies, for example when the data is no longer necessary or consent is withdrawn. The article also lists exceptions, such as data kept to comply with a legal obligation. The obligation sits with the controller: the company operating the agent. A memory vendor supplies the erasure mechanism; the customer owns the duty, decides which requests are valid, and answers to the regulator. ## Where erasure fails: derived facts Deleting the raw record is the easy half. An agent memory system extracts structure from what it ingests: facts, entities, relationships. After the source email is gone, the extracted fact "Ana's phone number is +31 6 ..." can survive in the graph, in an embedding, or in a cached summary. An erasure that removes the document and keeps the derivation has not erased anything a recall can still surface. - **Extracted facts** carry the personal data forward in structured form. - **Entity records** aggregate identifiers: names, addresses, handles. See [entity resolution](/guides/entity-resolution). - **Derived artifacts** such as embeddings and summaries can reproduce content their source no longer backs. The design requirement is bookkeeping: every derived fact must know which sources support it. That is the same provenance record an [audit trail](/guides/ai-audit-trail) needs, doing double duty. ## Deletion by source past.dev implements erasure at the source level. `DELETE /api/v1/ingest/{ingestionId}` forgets a source record and erases what only it supported. A fact supported by three sources survives the deletion of one of them, with its evidence reduced accordingly; a fact whose only support was the deleted source is erased with it. This behavior is worth stating plainly to whoever files the erasure request: erasing one email removes what that email alone established, and information the organization also holds elsewhere persists until those sources are deleted too. Erasing one person end to end therefore means deleting each of their source records. A stable source identifier assigned at ingestion makes this tractable: the application can enumerate a person's sources and delete them one by one. The [quickstart](/docs/memory-api/quickstart) shows where the identifier is set. ## Verifying that erasure holds Erasure that cannot be verified is a promise. The test is mechanical and belongs in a regression suite. 1. Ingest a source containing a distinctive personal fact and wait until ingestion reports `settled: true`. 2. Recall it and confirm the fact comes back with the source as evidence. 3. Delete the source by its ingestion id. 4. Recall again. The expected status value is `NoKnownSupport`: the stored evidence no longer establishes an answer. 5. Repeat with a fact deliberately corroborated by a second source, and confirm it survives with the remaining evidence. Recall behavior on erased and unsupported questions is part of what the [benchmarks](/benchmarks) evaluate: a system that answers confidently from deleted support fails more than a privacy test. ## Erasure, retention, and audit together Erasure is demand-driven; [retention](/guides/ai-data-retention) removes data on a schedule; the [audit trail](/guides/ai-audit-trail) records what happened, including that an erasure happened, without keeping the erased content. The three policies interlock and are best written together. In self-hosted deployments the memory lives in the customer's Postgres, so erasure and retention run inside the customer's own infrastructure; see [self-hosting](/docs/memory-api/self-hosting). ## Frequently asked questions ### Does deleting a chat delete what the AI learned from it? Only if the memory layer tracks which facts each source supports and erases the facts whose support is gone. Deleting the transcript while keeping the extracted facts does not satisfy an erasure request. ### Who is responsible for GDPR erasure when using a memory API? The company operating the agent is the data controller and owns the obligation. The memory provider supplies the deletion mechanism and, in a self-hosted deployment, the data never leaves the customer's own database. ### What happens to facts that other sources also support? They remain, with the deleted source removed from their evidence. Erasing a person completely means deleting each of their source records, which a stable source identifier makes enumerable. ## Related - [Data retention policies for AI memory](https://past.dev/guides/ai-data-retention) - [Audit trail for AI agent decisions](https://past.dev/guides/ai-audit-trail) - [Data provenance for AI agents](https://past.dev/guides/data-provenance) - [Designing a forgetting policy](https://past.dev/guides/forgetting-policy) - [Quickstart](https://past.dev/docs/memory-api/quickstart)