# How Do You Make AI Agent Memory GDPR Compliant? Erasure That Reaches Derived Facts, Embeddings and Backups

> AI agent memory is personal data, so GDPR applies to every fact, summary and embedding it keeps. What compliance takes in practice: a lawful basis per memory purpose, minimisation on the write path, retention limits, erasure that reaches derived facts, embeddings and backups, access and portability exports, processor contracts with the memory vendor and the LLM provider, transfer safeguards, a DPIA where risk is high, and where the EU AI Act fits after the July 2026 changes. Read against the GDPR text and EDPB guidance on 28 October 2026.

_Gaurav Dadhich · 2026-10-28_

\# How Do You Make AI Agent Memory GDPR Compliant? Erasure That Reaches Derived Facts, Embeddings and Backups \*Published 28 October 2026. Every GDPR and AI Act article quoted here was read from the Official Journal text, and every regulator document and provider policy was read on 28 October 2026. This is an engineering guide, not legal advice; take your specific case to your DPO or counsel.\* You make AI agent memory GDPR compliant by treating the memory layer as a personal-data processing system in its own right: every stored fact, summary and embedding about a person needs a documented purpose and lawful basis, a retention limit, and a path by which that person can see it, correct it, export it and have it erased. Erasure is the hard part, because a memory layer copies one thing a user said into several derived records (an extracted fact, a profile field, a summary, an embedding, a cached prompt, a backup), and deleting the source conversation deletes none of them. The European Data Protection Board's \[2025 coordinated enforcement report on the right to erasure\](https://www.edpb.europa.eu/system/files/2026-02/edpb\_cef-report\_2025\_right-to-erasure\_en.pdf), adopted on 10 February 2026 after 32 supervisory authorities questioned 764 controllers, found failures exactly where agent memory is weakest: backups excluded by default, anonymisation used in place of deletion, and no way to show that an erasure happened. ## Is agent memory personal data, and are embeddings? Both are, in almost every agent that remembers a user. \[Article 4(1) GDPR\](https://op.europa.eu/en/publication-detail/-/publication/3e485e15-11bd-11e6-ba9a-01aa75ed71a1) defines personal data as "any information relating to an identified or identifiable natural person", and a memory such as "prefers Python examples" or "is moving to Berlin in March", stored against a user ID, is exactly that. Embeddings get the same answer for a different reason. Recital 26 says "Personal data which have undergone pseudonymisation, which could be attributed to a natural person by the use of additional information should be considered to be information on an identifiable natural person", and an embedding row carries the user ID that attributes it. The vector is not opaque either: \[Morris and co-authors\](https://arxiv.org/abs/2310.06816) recovered 92% of 32-token inputs exactly from their embeddings and pulled full names out of clinical notes. The EDPB has not ruled on memory embeddings as such, but its \[Opinion 28/2024\](https://www.edpb.europa.eu/system/files/2024-12/edpb\_opinion\_202428\_ai-models\_en.pdf) says AI models "trained with personal data cannot, in all cases, be considered anonymous", and a vector filed next to a user ID is a weaker case for anonymity than a model. ## Who is the controller, and who are your processors? The company deploying the agent is normally the controller; the memory vendor, the LLM API, the embedding API and the vector database host are normally processors. \[Article 28\](https://op.europa.eu/en/publication-detail/-/publication/3e485e15-11bd-11e6-ba9a-01aa75ed71a1) lets you use "only processors providing sufficient guarantees", under a contract that requires them to help you respond to rights requests and, when the service ends, to delete or return the data and delete "existing copies". A vendor that uses your users' memories for its own purposes, such as training, is treated under Article 28(10) as a controller for that processing. The EDPB's \[Opinion 22/2024\](https://www.edpb.europa.eu/system/files/documents/2024-10/edpb\_opinion\_202422\_relianceonprocessors-sub-processors\_en.pdf) says controllers "should have the information on the identity (i.e. name, address, contact person) of all processors, sub-processors etc. readily available at all times". If your memory vendor cannot name the model that extracts facts from your users' conversations, you cannot meet that. ## Which lawful basis covers a memory? You document one basis per memory purpose under \[Article 6(1)\](https://op.europa.eu/en/publication-detail/-/publication/3e485e15-11bd-11e6-ba9a-01aa75ed71a1). Remembering an open ticket so support does not ask twice usually fits contract. Cross-session personalisation often rests on legitimate interests, which Opinion 28/2024 tests in three steps: an interest that is lawful, clearly articulated and "real and present (i.e. not speculative)", necessity, and a balancing test. A consumer assistant building a long-lived profile is where consent is the honest basis, and Article 7(3) then requires that it be "as easy to withdraw as to give consent", which means a memory-off switch that actually stops the writes. The choice decides later duties: portability exists only for consent and contract, the general right to object only for legitimate interests and public tasks. ## Minimise on the write path, not after \[Article 5(1)(c)\](https://op.europa.eu/en/publication-detail/-/publication/3e485e15-11bd-11e6-ba9a-01aa75ed71a1) requires data "adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed", and Article 25(2) makes that the default for "the amount of personal data collected, the extent of their processing, the period of their storage and their accessibility." For memory this is a write-path rule, because anything never written never has to be found, exported, transferred or erased. Keep the durable, purpose-relevant fact ("prefers invoices in EUR"), drop the rest of the turn, and run the sensitive-data filter before anything is stored. That filter carries \[Article 9\](https://op.europa.eu/en/publication-detail/-/publication/3e485e15-11bd-11e6-ba9a-01aa75ed71a1), which prohibits processing data "revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership" and "data concerning health", among others, unless an Article 9(2) condition applies. An extraction model will turn "I cannot do Thursday, I have chemo" into a health fact unless told not to. "Revealing" also covers inference: a memory that concludes a health condition from a run of questions is special-category data the user never stated. Secrets deserve a hard floor, not a setting. ## Purpose limitation: memory built for one job stays in that job \[Article 5(1)(b)\](https://op.europa.eu/en/publication-detail/-/publication/3e485e15-11bd-11e6-ba9a-01aa75ed71a1) requires data "collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes", and Article 6(4) lists what a compatibility check weighs, including "the possible consequences of the intended further processing for data subjects". Enforce the boundary in the data model: scope memories by purpose as well as by user, give each agent read access only to the scopes its purpose covers, and treat a new agent reading an old scope as a new purpose to assess. ## How long can a memory live? Only as long as its purpose needs. \[Article 5(1)(e)\](https://op.europa.eu/en/publication-detail/-/publication/3e485e15-11bd-11e6-ba9a-01aa75ed71a1) limits storage to "no longer than is necessary for the purposes", and Recital 39 says "time limits should be established by the controller for erasure or for a periodic review." Give each memory class its own clock (raw turns in days, a task until it closes, a preference until it is superseded or the account goes quiet), and treat keeping every superseded version as the retention decision it is. Article 15(1)(d) obliges you to tell people the period or "the criteria used to determine that period", so the clocks must be written down. ## Right to erasure: deleting the source is not deleting the memory \[Article 17(1)\](https://op.europa.eu/en/publication-detail/-/publication/3e485e15-11bd-11e6-ba9a-01aa75ed71a1) gives a person the right to erasure "without undue delay" on grounds that include the data being "no longer necessary", consent being withdrawn, or an objection with "no overriding legitimate grounds". The Article 17(3) exceptions, such as a legal obligation or "the establishment, exercise or defence of legal claims", rarely cover agent memory, so the duty reaches every place the person's data went: | Where one sentence ends up | What erasure has to do | |---|---| | Raw conversation log | Delete the turns, or the user's whole log | | Extracted facts and profile fields | Delete every fact sourced from that user, including merged ones | | Summaries and compacted context | Regenerate or delete; a summary that mentions the person is their data | | Embeddings and keyword indexes | Delete, then confirm retrieval no longer returns them | | Caches | Expire; a cached context block outlives the source by its TTL | | Processor copies | Instruct deletion under the Article 28 contract | | Backups | Track the request and reapply it on restore | Doing this reliably needs lineage: every derived record points to the source records it came from, so an erasure walks forward from the person's raw data and removes everything downstream. Deleting vectors by user ID leaves the summary that mentioned them, a gap I covered in \[Can a Vector Database Be Agent Memory?\](https://www.maximem.ai/blog/can-a-vector-database-be-agent-memory). \[Article 19\](https://op.europa.eu/en/publication-detail/-/publication/3e485e15-11bd-11e6-ba9a-01aa75ed71a1) adds that erasure must be communicated "to each recipient to whom the personal data have been disclosed, unless this proves impossible or involves disproportionate effort", so memories that flowed to an analytics tool or a partner agent have to be followed. \*\*Backups.\*\* The EDPB report found "many controllers also excluded back-up data by default, without providing a justification for doing so." It does not demand rewriting every backup: "it might not always be advisable to modify or delete information from back-ups. But, in that case, organisations should have appropriate procedures to keep track of erasure requests and comply with them on restored systems". For memory that means an erasure ledger replayed after any restore, and a backup retention short enough to stay defensible. \*\*Soft delete and anonymisation.\*\* A \`deleted = true\` flag is restriction, not erasure, and the report warns that some controllers "only apply basic pseudonymisation or partial masking, although such a process would not fulfil the requirements of the GDPR regarding deletion." Stripping the user ID from an embedding while keeping the vector is partial masking. \*\*Deadline and proof.\*\* \[Article 12(3)\](https://op.europa.eu/en/publication-detail/-/publication/3e485e15-11bd-11e6-ba9a-01aa75ed71a1) requires action "without undue delay and in any event within one month of receipt of the request", extendable "by two further months where necessary" if you tell the person within the first month. The report recommends that controllers "Verify that erasure has been carried out and be able to demonstrate such erasure." For memory, the demonstration is a test: plant a unique string in a test user's conversation, let it spread into facts, summaries and vectors, erase the user, then search every store and probe retrieval for it. That is the deletion test in \[How Do You Test Agent Memory Before You Ship?\](https://www.maximem.ai/blog/how-to-test-agent-memory), with a pass bar of zero leaks. ## Access, portability, rectification and objection Access under \[Article 15\](https://op.europa.eu/en/publication-detail/-/publication/3e485e15-11bd-11e6-ba9a-01aa75ed71a1) means "a copy of the personal data undergoing processing" plus purposes, recipients, retention and, where data did not come from the person, "any available information as to their source". For memory, the copy includes inferred memories, and provenance is what answers the source question. Portability under Article 20 covers data the person "has provided", "in a structured, commonly used and machine-readable format", only under consent or contract; a JSON export of memories with timestamps and scopes serves both rights, filtered per request. Rectification under Article 16, together with Article 5(1)(d)'s duty to correct inaccurate data "without delay", applies when a memory decides a user is a student because she said she teaches students. Corrections need erasure's lineage, or the old value returns from a summary. Where memory rests on legitimate interests, Article 21 lets a person object "at any time", and the control is the same switch as consent withdrawal: stop writing, then erase or restrict what exists. ## Your LLM provider sees every memory you put in a prompt Every model call that carries retrieved memories discloses them to the provider, whose retention becomes part of yours. As of 28 October 2026, OpenAI's \[data controls page\](https://developers.openai.com/api/docs/guides/your-data) says "abuse monitoring logs are generated for all API feature usage and retained for up to 30 days, unless longer retention is required by law", and that "the Responses API has a 30 day Application State retention period by default, or when the store parameter is set to true"; objects in its Conversations endpoint are kept until deleted. Anthropic's \[privacy centre\](https://privacy.claude.com/en/articles/7996866-how-long-do-you-store-my-organization-s-data), updated 1 July 2026, says "we automatically delete inputs and outputs on our backend within 30 days of receipt or generation", with retention "for up to 2 years" if content is flagged for a Usage Policy violation. Both offer zero-data-retention by agreement. Name the model provider as a recipient with its retention in your records and privacy notice, and either rely on its deletion window in your erasure process (and say so) or arrange zero retention. A provider-hosted conversation object used as memory is a memory store, and every duty above applies to it. ## Cross-border transfers and data residency \[Article 44\](https://op.europa.eu/en/publication-detail/-/publication/3e485e15-11bd-11e6-ba9a-01aa75ed71a1) allows transfers outside the EEA only under Chapter V, "including for onward transfers", so an EU-hosted memory vendor that calls a US model for extraction still makes a transfer you must cover, by adequacy (Article 45) or safeguards such as standard contractual clauses (Article 46). The EU-US Data Privacy Framework is still in court: the General Court rejected the challenge in Latombe v Commission (T-553/23) on 3 September 2025, and the \[appeal lodged on 31 October 2025\](https://juris.curia.europa.eu/juris/document/document.jsf?docid=307389&pageIndex=0&doclang=EN&mode=req&dir=&occ=first&part=1), C-703/25 P, asks the Court of Justice to annul the adequacy decision and was listed as a case in progress on 28 October 2026, which is a reason to know each vendor's fallback. Ask where the store, the extraction and embedding models, the backups and support staff each sit; "EU region" on the storage line answers one of those. Running \[local embedding models\](https://www.maximem.ai/blog/local-embedding-models) removes one transfer entirely. ## Do you need a DPIA? For most memory layers that profile people, you do. \[Article 35\](https://op.europa.eu/en/publication-detail/-/publication/3e485e15-11bd-11e6-ba9a-01aa75ed71a1) requires one "prior to the processing" where it is "likely to result in a high risk to the rights and freedoms of natural persons", naming profiling-based decisions with significant effects and "processing on a large scale of special categories of data". Cross-session profiling in health, finance, HR or with children should assume one, covering what the extractor may infer and how erasure reaches derived records. ## Where the EU AI Act fits in October 2026 The AI Act sits beside the GDPR. \[Article 2(7)\](https://op.europa.eu/en/publication-detail/-/publication/dc8116a1-3fe6-11ef-865a-01aa75ed71a1), as reworded by \[Regulation (EU) 2026/1744\](https://op.europa.eu/en/publication-detail/-/publication/b459c07f-86fb-11f1-bf5e-01aa75ed71a1), says "Union law on the protection of personal data, privacy and the confidentiality of communications applies to personal data processed in connection with the rights and obligations laid down in this Regulation." For most agents with memory, the duty in force today is Article 50(1), applicable since 2 August 2026: systems "intended to interact directly with natural persons" must be designed so "the natural persons concerned are informed that they are interacting with an AI system", unless that is obvious. For high-risk uses such as hiring and credit, the Digital Omnibus on AI of 8 July 2026 moved the high-risk obligations to 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems, so older guides that give August 2026 are out of date. Memory matters there because what an agent remembers about a person becomes an input to a decision about them, which is also where GDPR \[Article 22\](https://op.europa.eu/en/publication-detail/-/publication/3e485e15-11bd-11e6-ba9a-01aa75ed71a1) applies to decisions "based solely on automated processing" with legal or similarly significant effects. The GDPR itself has not changed. The Digital Omnibus proposal (2025/0360 (COD)) would amend it, and the Council's \[mandate for negotiations with the European Parliament\](https://data.consilium.europa.eu/doc/document/ST-14756-2026-INIT/en/pdf) was agreed by the Permanent Representatives Committee on 21 October 2026, so the text is still being negotiated and the GDPR as published applies until an amendment is adopted and in force. ## Questions to ask a memory vendor | Question | Basis | A good answer | |---|---|---| | Can you erase one person across logs, facts, summaries, embeddings and caches, and show what will go? | Art. 17, 28(3) | One call per person, previewed, with a completion record | | Does every memory trace to its source? | Art. 15(1)(g), 16, 17 | Provenance on every memory, including what it replaced | | What happens to erased data in backups? | EDPB CEF 2025 | Stated backup retention and replay on restore | | What sensitive data can you keep out, and what is never stored? | Art. 5(1)(c), 9, 25(2) | Per-type controls plus a fixed floor for secrets | | Can retention differ by memory type, and can I export one person as JSON? | Art. 5(1)(e), 15, 20 | Yes to both | | Who are all your sub-processors, including extraction and embedding models, and where? | Art. 28(2), 44, Opinion 22/2024 | A named, current list with locations and transfer mechanism | | Do you train on customer memories, and can it run in our environment? | Art. 28(10), residency | No training, in the contract; a self-hosted option if your risk needs it | ## Where Maximem Synap fits \[Maximem Synap\](https://www.maximem.ai/synap) is a memory layer, so it is one of the processors above, and using it does not make an agent compliant; the controller duties stay with you. Erasure is per person and previewed before it runs. Every memory carries provenance: where it came from, what it replaced, why it changed and what it used to say. Sensitive data follows your PII posture, with 27 kinds of sensitive value detected, per-key reveal set to full, masked or none, and a floor of seven field types destroyed on detection; payment card details, security codes, PINs, passwords, API keys, private keys and raw biometric data are never stored, with no setting that turns that off. Managed cloud is the default, and self-hosted and air-gapped deployment is available for enterprise engagements. ## Frequently asked questions ### Is AI agent memory personal data under GDPR? Agent memory is personal data whenever it relates to an identifiable person, which covers extracted facts, summaries, profiles and the source conversations. ### Are vector embeddings personal data? Treat them as personal data when they derive from a person's words and sit against their ID; Recital 26 treats attributable pseudonymised data as personal data. ### How does the right to be forgotten work for LLM memory? Erasure has to reach every derived record (facts, summaries, embeddings, indexes, caches, processor copies and backups) within one month, extendable by two, and a test should prove nothing still retrieves. ### Do I have to delete data from backups? You do not have to rewrite them. The EDPB's 2025 report accepts that editing backups is not always advisable, but expects erasure requests to be tracked and reapplied on restored systems. ### Does the EU AI Act apply to an agent with memory? Usually through Article 50's disclosure duty, in force since 2 August 2026; listed high-risk uses follow from 2 December 2027, and the GDPR applies either way. ## Sources - \[Regulation (EU) 2016/679 (GDPR)\](https://op.europa.eu/en/publication-detail/-/publication/3e485e15-11bd-11e6-ba9a-01aa75ed71a1): Articles 4, 5, 6, 7, 9, 12, 15 to 21, 22, 25, 28, 35, 44 to 46; Recitals 26 and 39. - \[Regulation (EU) 2024/1689 (AI Act)\](https://op.europa.eu/en/publication-detail/-/publication/dc8116a1-3fe6-11ef-865a-01aa75ed71a1): Articles 2(7), 50(1), 113. - \[Regulation (EU) 2026/1744 (Digital Omnibus on AI)\](https://op.europa.eu/en/publication-detail/-/publication/b459c07f-86fb-11f1-bf5e-01aa75ed71a1), 8 July 2026. - \[EDPB, 2025 Coordinated Enforcement Action on the right to erasure\](https://www.edpb.europa.eu/system/files/2026-02/edpb\_cef-report\_2025\_right-to-erasure\_en.pdf), adopted 10 February 2026. - \[EDPB Opinion 28/2024 on AI models\](https://www.edpb.europa.eu/system/files/2024-12/edpb\_opinion\_202428\_ai-models\_en.pdf), 17 December 2024. - \[EDPB Opinion 22/2024 on processors and sub-processors\](https://www.edpb.europa.eu/system/files/documents/2024-10/edpb\_opinion\_202422\_relianceonprocessors-sub-processors\_en.pdf), 7 October 2024. - \[Morris et al., Text Embeddings Reveal (Almost) As Much As Text\](https://arxiv.org/abs/2310.06816). - \[OpenAI, Data controls in the OpenAI platform\](https://developers.openai.com/api/docs/guides/your-data), read 28 October 2026. - \[Anthropic, How long do you store my organization's data?\](https://privacy.claude.com/en/articles/7996866-how-long-do-you-store-my-organization-s-data), updated 1 July 2026. - \[Court of Justice, Appeal brought on 31 October 2025 by Philippe Latombe, Case C-703/25 P\](https://juris.curia.europa.eu/juris/document/document.jsf?docid=307389&pageIndex=0&doclang=EN&mode=req&dir=&occ=first&part=1). - \[Council of the EU, Digital Omnibus mandate for negotiations, document 14756/26\](https://data.consilium.europa.eu/doc/document/ST-14756-2026-INIT/en/pdf), 22 October 2026.

---

Source: [https://www.maximem.ai/blog/gdpr-compliant-agent-memory](https://www.maximem.ai/blog/gdpr-compliant-agent-memory)