AI Agents and Data Subject Rights: Memory and Erasure

AI agents copy personal data into places a normal data subject request process never searches: conversation memory, extracted long-term facts, vector stores, tool call logs and traces. A request for access, erasure or objection that only reaches the CRM and the ticketing system is incomplete once an agent has summarised a customer's emails into its memory or embedded their documents for retrieval. This guide covers how to find, export, erase and stop processing personal data across agent memory layers, how to record what you did, and where the hard limits are, such as personal data inside model weights. It is written for privacy engineers, DPOs and platform teams who run agents. It builds on the DSAR Guide, which covers intake, verification and deadlines, and does not repeat them.

Sources: GDPR text, EDPB, ICO and CNIL guidance and platform documentation as cited below, as of November 2026. Confirm against the official text before relying on it.

Key takeaways

Agent memory is personal data processing. Short-term session events, extracted long-term memories, embeddings and traces all fall within Articles 15 to 22 GDPR when they relate to an identifiable person.
Key every memory write to a subject. If memory records and vectors do not carry a subject or actor identifier, you cannot find or delete them within the one-month deadline in Article 12(3).
Erasure has to follow the copies. Deleting the source document is not enough: the derived memory records, chunks, embeddings, caches and log copies must go too, and recipients must be told under Article 19.
Objection changes what the agent may do next. Where processing rests on legitimate interest, an Article 21 objection should stop the agent writing or retrieving that person's data, not only delete what exists.
Models are a separate, harder case. EDPB Opinion 28/2024 and the CNIL's January 2026 recommendations treat a model as in scope unless it is shown to be anonymous; retraining or output filtering are the documented options.

Where agents keep personal data

An agent that reads mail, tickets or documents on a user's behalf creates several layers of derived data. Each layer needs its own search and deletion method. Map them in your data map and ROPA before the first request arrives.

Layer	What it holds	Typical key	Search and delete method
Session or short-term memory	Turn-by-turn messages, tool calls and results within a session	Session ID, actor or user ID	List events by actor and session; delete events or expire them by retention setting
Long-term memory	Extracted facts, preferences and summaries across sessions	Namespace, often templated per actor	Query records in the subject's namespace; delete records individually or the namespace
Retrieval index (vector store)	Chunks and embeddings of documents, mail or tickets	Document ID and metadata such as owner or subject ID	Delete by ID or by metadata filter; confirm by re-query after the store is consistent
Caches	Cached prompts, responses and retrieval results	Prompt hash or session	Flush by key or let short TTLs expire; record the TTL
Traces and observability logs	Full prompts, retrieved context, tool inputs and outputs	Trace ID, user ID attribute	Search by user attribute; delete or redact where the platform allows; otherwise rely on documented retention
Agent outputs written elsewhere	Drafted emails, CRM notes, tickets, files	The target system's record ID	Handled by that system's DSAR process; track the agent as the writer
Fine-tuned or trained models	Possible memorised training examples	None per subject	Retrain, filter outputs, or document why the model is anonymous

Managed agent memory services make the keys explicit. In Amazon Bedrock AgentCore Memory, for example, short-term memory is built from immutable, timestamped events organised by actorId and sessionId, and long-term memory records are stored in namespaces that strategies populate from those events. The DeleteMemoryRecord operation removes one record and takes the namespace as a parameter used for IAM condition authorisation. Other platforms use different names for the same ideas; check the actor and namespace model before you design anything else. For hardening the memory layer itself, see the AI Agent Memory Security Guide.

What the law asks, applied to agents

Right (GDPR)	What it means for agent data	Practical test
Access, Art. 15	A copy of personal data in memory records, retrieved chunks and stored outputs, plus purposes, recipients and retention for each layer	Can you export every memory record and vector payload for a subject in a readable form?
Rectification, Art. 16	Correct wrong facts the agent has stored about a person, such as an extracted preference or summary	Can you edit or replace a single memory record and re-embed a corrected chunk?
Erasure, Art. 17	Delete source-derived memory, chunks, embeddings and log copies without undue delay where a ground applies	Can you delete by subject across all layers and prove it?
Restriction, Art. 18	Keep the data but stop the agent using it while a dispute is resolved	Can you mark records as excluded from retrieval without deleting them?
Notification, Art. 19	Tell each recipient of any rectification, erasure or restriction, unless impossible or disproportionate	Do you know which tools, sub-agents or processors received the data?
Objection, Art. 21	Stop processing based on Art. 6(1)(e) or (f), including profiling, unless compelling grounds; direct marketing objection is absolute under Art. 21(3)	Can you block future memory writes and retrieval for one person?
Automated decisions, Art. 22	Agents that make decisions with legal or similarly significant effects need human intervention and meaningful information about the logic	Is human review real, or does a reviewer just approve the agent's answer?

Article 12(3) requires a response within one month of receipt, extendable by two further months for complex or numerous requests. The ICO's guidance on individual rights in AI systems says difficulty alone does not make a request manifestly unfounded or excessive, and that a controller remains responsible when a processor runs the system, so contracts should require the processor's help. The ICO notes that guidance is under review following the Data (Use and Access) Act 2025, so check its current text. Article 25(2) also matters here: by default, only personal data necessary for each purpose should be processed, which argues against agents that memorise everything they read.

Handling access requests across agent memory

Resolve the subject to agent identifiers. Map the verified requester to every actor ID, user ID, account and email the agent platforms use. Agents acting for colleagues may also hold data about the requester under someone else's actor ID, so search payloads and metadata, not only keys.
Export long-term memory records. Pull every record in the subject's namespaces with its creation time and the strategy or source that produced it. These are the agent's conclusions about the person and are the most likely to surprise them.
Export retrieval content. Query vector stores by metadata filter for the subject's documents and return the text payloads. Raw embedding vectors are not intelligible on their own; provide the text they represent and say that the vectors exist.
Search traces and logs. Include prompts, retrieved context and tool results that contain the subject's data, within the retention window you have documented.
Describe the processing. For each layer give the purpose, recipients (model providers, tool APIs, sub-agents) and retention, as Article 15(1) requires.
Redact third parties. Agent memory often mixes several people in one summary. Apply the same third-party redaction rules as for email.
Address the model. The CNIL's January 2026 recommendations say that if you confirm a person's data was memorised by a model you should tell them and share your findings; if you cannot confirm or rule it out, tell them it is possible. Use this only where you train or fine-tune on personal data.

Erasure: following data through every copy

The EDPB's coordinated enforcement report on the right to erasure, adopted on 18 February 2026 after 32 authorities reviewed 764 controllers, found recurring problems with backups, setting retention periods and using ineffective anonymisation as a substitute for deletion. All three appear in agent systems. The engineering patterns for deletion in general are in the Right to Erasure Engineering Guide; the agent-specific steps are below.

Delete by lineage, not by guess: record, at write time, which source objects each memory record and chunk came from. Erasure then becomes "delete everything derived from these sources and this actor", which is testable.
Vector stores: most stores support deletion by ID, by metadata filter or by clearing a namespace. Pinecone's documentation, for example, offers deletion by up to 1,000 IDs per request, by metadata filter, or by deleting all records in a namespace, and notes that the store is eventually consistent. Re-query after the change is visible before you record completion.
Per-subject namespaces: where a memory or index is scoped to one person, deleting the namespace is the cleanest erasure. Shared indexes need metadata on every chunk.
Summaries that mix people: a long-term memory that says "Alice and Bob agreed the refund" cannot be partly deleted. Rewrite or delete the record, and prefer extraction strategies that write one subject per record.
Logs and traces: where the platform cannot delete individual traces, keep retention short and documented, and restrict access. Do not keep full prompt logs indefinitely "for debugging".
Backups and snapshots: record that erased data will age out of backups by a stated date and must not be restored into live memory. Keep a suppression list so a restore does not reintroduce it.
Re-ingestion: if the agent re-indexes a mailbox or drive nightly, erasure in the index is undone by the next run unless the source is deleted or the subject is suppressed.
Recipients: under Article 19, tell model providers, tool APIs and other controllers that received the data, unless impossible or disproportionate. Contract terms with providers should state retention and deletion support.

Pseudonymised or hashed identifiers in memory are still personal data if you can re-link them. Do not treat embedding a document as anonymising it: OWASP's LLM08:2025 Vector and Embedding Weaknesses entry describes embedding inversion attacks that recover source text. See the OWASP LLM Top 10 LLM08 Vector and Embedding Weaknesses Guide.

Objection and restriction: changing agent behaviour

Objection and restriction are about what happens next, not only what is stored. An agent that keeps learning about a person after they objected breaches Article 21 even if yesterday's memory was deleted.

Suppression list: keep a list of subjects who objected or are restricted, checked by the memory write path and the retrieval path. Writes for those subjects are dropped; retrieval filters exclude their records.
Retrieval filters: apply restriction as a metadata flag that permission-aware retrieval honours, so records are preserved for the dispute but never placed in a prompt. See the Permission-Aware RAG Guide.
Profiling agents: agents that score, segment or personalise based on memory are profiling. Under Article 21(1) objection applies where the basis is Article 6(1)(e) or (f), and EDPB Opinion 28/2024 (para. 65) confirms the right to object must be honoured where legitimate interest is used.
Direct marketing: an objection to marketing use is absolute under Article 21(3). Sales and marketing agents need the same suppression check as email campaigns.

Personal data inside models

Most agents use a provider's model without fine-tuning, so the model itself does not hold your customers' data. Where you do fine-tune or train on personal data, the position is harder. EDPB Opinion 28/2024 (18 December 2024) says a model is anonymous only if the likelihood of extracting training data, directly or by querying, is insignificant, and that a thorough evaluation is very likely to be needed. The CNIL's recommendations of 5 January 2026 set retraining as the default response to erasure where you still hold the training data, batched and possibly taking up to three months with the timeline communicated, and output filters where retraining is disproportionate and the filters are shown to be effective. The ICO says erasure from a training set does not automatically require deleting every model built on it, only models that contain or can infer the data.

Situation	Recommended approach	Record to keep
No fine-tuning; provider model only	Handle memory, index and logs; confirm provider retention and training terms	Provider data processing terms and retention settings
Fine-tuned on personal data, training data still held	Remove from training set; retrain in the next scheduled batch; tell the subject the timeline	Dataset version, removal date, model version that excludes the data
Fine-tuned, retraining disproportionate	Output filters for the subject's identifiers; test regularly for regurgitation	Proportionality assessment, filter tests
Claimed anonymous model	Extraction and inference testing as described by the EDPB	Test results and documentation for accountability

Design choices that make rights workable

Choice	Easier for rights	Trade-off
Per-subject memory namespaces	Access and erasure become one query	Cross-user knowledge has to live elsewhere
Shared index with subject metadata on every chunk	Works if metadata is complete	One missing tag leaves data behind
Short event retention with long-term extraction	Fewer raw transcripts to search	Extracted facts need careful accuracy and rectification
No long-term memory	Smallest rights surface	Less personalisation
Full prompt tracing	Better debugging and incident response	Large, hard-to-delete copies of personal data

Smaller organisations should favour managed memory with clear per-actor scoping and short retention, and avoid fine-tuning on personal data. Larger organisations with several agent platforms need a central rights orchestrator that calls each platform's delete and export APIs and records results, in the same way they already handle SaaS systems. Record the decision in a DPIA for each agent that processes personal data at scale.

Implementing rights handling for agents

Inventory: list every agent, its memory layers, vector stores, trace destinations and the identifiers each uses. Add them to the ROPA.
Key the writes: require subject or actor IDs and source lineage on every memory record and chunk. Reject writes without them in new agents.
Set retention: configure event expiry, cache TTLs and trace retention per layer, and document the values.
Build export and delete connectors: one per platform, called by your DSAR workflow. Start in a test tenant with synthetic subjects.
Add the suppression check: on memory write, retrieval and re-ingestion.
Test end to end: seed a synthetic person across all layers, run an access and an erasure request, and verify nothing remains by searching payloads, not only keys. Repeat after platform upgrades.
Roll out by agent risk: customer-facing and HR agents first, internal coding agents later.
Roll back safely: if a connector deletes too much, restore from backup but re-apply the suppression list and pending erasures before the restored data goes live.

Detection and measurement

Coverage: share of agents whose memory layers are connected to the DSAR workflow.
Key completeness: share of memory records and chunks carrying a subject ID and source lineage.
Residual search rate: results found when re-searching payloads after erasure, target zero.
Time to complete: days from verified request to confirmed deletion across all agent layers, against the one-month limit.
Suppression hits: blocked writes and retrievals for objecting subjects, which show the control is active.
Retention drift: traces or events older than the documented retention.

Framework mapping

Need	NIST SP 800-53 Rev 5	NIST CSF 2.0	ISO/IEC 27001:2022 Annex A
Know what agent data exists	PT-3	ID.AM-07	A.5.34 Privacy and protection of PII
Lawful basis and purpose	PT-2, PT-3	GV.OC-03	A.5.34
Retention and disposal	SI-12, SI-12(3), AU-11	PR.DS-01	A.8.10 Information deletion
Accuracy and rectification	SI-18	PR.DS-01	A.5.34
Backups that respect erasure	SI-12	PR.DS-11	A.8.13 Information backup

Common failure patterns

Searching only systems of record: the DSAR covers the CRM but not the agent's long-term memory, which holds the agent's own conclusions about the person.
Deleting the source but not the embeddings: the retrieval index keeps returning chunks of a document that no longer exists.
Nightly re-ingestion undoing erasure: a connector re-indexes the mailbox and puts the data back.
Treating embeddings as anonymous: inversion attacks and stored text payloads mean vectors are still personal data.
Indefinite trace retention: observability platforms keep full prompts for months with no deletion path.
Rubber-stamp review: the ICO is clear that a human who just approves an agent's decision does not take it outside Article 22.

Practitioner checklist

Add every agent memory layer, vector store and trace store to the data map and ROPA.
Require subject IDs and source lineage on every memory record and chunk.
Set and document retention for events, caches and traces.
Build export and delete connectors for each agent platform and call them from the DSAR workflow.
Implement a suppression list checked on memory write, retrieval and re-ingestion.
Test access and erasure with a synthetic person across all layers after each platform change.
Confirm model provider retention and training terms, and Article 19 notification routes.
Document the model position: no fine-tuning, retraining schedule, or filters with tests.

Standards and references

Related NHI Mgmt Group resources: DSAR Guide: Handling Data Subject Requests · Right to Erasure Engineering Guide · AI Agent Memory Security Guide · Vector Database Security Guide. This guide summarises GDPR obligations and regulator guidance as of November 2026 and is not legal advice.

AI Agents and Data Subject Rights: Finding, Exporting and Erasing Personal Data in Agent Memory