Does AI Memory Require a DPIA? Yes. Here's What Yours Has to Actually Cover.

If you're shipping persistent memory in an AI assistant, agent, or copilot that touches personal data of EU residents, the question "does AI memory require a DPIA" has a short answer: almost certainly yes. Article 35 of the GDPR was written for exactly this kind of processing. New technology, systematic profiling potential, data accumulation over time. Persistent memory checks every box. The longer answer is that most teams either skip the DPIA entirely or produce one that covers the wrong risks. This piece is the one we wish someone had written before we built our own memory layer.

Key Takeaways

• Persistent AI memory triggers GDPR Article 35 (DPIA) in nearly every deployment that handles personal data. The combination of new technology, automated profiling risk, and large-scale data accumulation meets the threshold criteria with room to spare.
• A DPIA for memory must treat different memory tiers (ephemeral working memory, long-term persistent store, vector embeddings) as separate risk classes with separate lawful bases, retention schedules, and erasure mechanics.
• Article 15 (right of access) and Article 17 (right to erasure) create hard engineering requirements that most memory architectures cannot satisfy today, because no commercially available vector database offers provable deletion of embedded data.
• The EU AI Act introduces a 10-year audit trail requirement for high-risk systems that directly conflicts with GDPR erasure rights, and your architecture has to resolve that tension at the schema level.
• Memory itself is an attack surface. Research has demonstrated that ordinary user queries can poison a persistent memory store with injection success rates above 95 percent against production architectures. Your DPIA needs to account for this.

Why Does Persistent Memory Trigger Article 35?

Because Article 35 requires a DPIA whenever processing is "likely to result in a high risk to the rights and freedoms of natural persons," particularly when it involves new technologies, automated decision-making, or systematic monitoring. Persistent memory in an AI system hits at least two of these, usually all three. The standard DPIA screening test asks whether the processing uses innovative technology, whether it involves evaluation or scoring, and whether data is collected on a large scale or combined from multiple sources. A memory-enabled assistant that recalls your preferences, past queries, and contextual details across sessions is doing all of those things simultaneously.

The EDPB's own criteria list nine indicators. If your processing meets two, you should do a DPIA. Persistent memory typically meets four or five: new technology, systematic storage of personal data, data concerning vulnerable persons (if your user base includes them), and innovative use of data. The AEPD's February 2026 guidance on agentic AI made this explicit, mapping GDPR obligations directly to agent characteristics like memory and adaptability.

If you are reading this and your team has shipped memory without a DPIA, you are not unusual. You are also not compliant.

What GDPR Articles Does Agent Memory Actually Trigger?

More than you'd expect. Here is the real list, not the abbreviated version most compliance decks present.

Article 6: Lawful Basis

You need a lawful basis for storing personal data in memory. "It makes the product better" is not a lawful basis. Consent is one path, but consent for memory needs to be granular (what gets remembered, for how long, for what purpose) and withdrawable. Legitimate interest is another path, but it requires a balancing test documented in your DPIA. Most teams default to legitimate interest and never do the balancing test.

Article 13/14: Transparency

You must tell the user what you're storing before or at the point of collection. If your memory system infers facts about a user from their queries and stores those inferences, Article 14 applies because you're processing data not obtained directly from the data subject. The practical implication: your privacy notice needs to describe the memory feature, what categories of data it retains, and for how long.

Article 15: Right of Access

This one breaks most memory architectures. A data subject can ask "what do you know about me?" and you have to answer with specifics. Not "we store conversation context." You need to return the actual data. If your memory is stored as vector embeddings, producing a human-readable answer to an Article 15 request is a genuine engineering problem, not a legal formality. The access requirement applies to conversation histories, retrieved content, stored preferences, and embeddings alike.

Article 16: Right to Rectification

The user can tell you a stored fact is wrong and demand correction. If your assistant remembered that someone lives in Berlin and they've moved to Lisbon, you need a mechanism to update that. In a key-value memory store, this is tractable. In a vector embedding, correcting a single fact without recomputing the entire embedding is, at present, somewhere between difficult and impossible.

Article 17: Right to Erasure

Delete means gone. Actually gone. Not "marked as inactive." Not "excluded from future retrieval but still present in the index." The EDPB ran a coordinated enforcement action on erasure in February 2026, signaling that regulators are actively testing whether companies can operationalize deletion. The uncomfortable fact: no commercially available vector database currently provides a provable deletion mechanism for data that has been embedded. If your memory layer uses embeddings, your Article 17 compliance is, at best, aspirational.

Article 35: The DPIA Itself

This is the meta-obligation. You need to assess the necessity and proportionality of the processing, evaluate the risks to data subjects, and document the measures you're taking to address those risks. More on what this actually needs to contain below.

What Does a DPIA for Memory Actually Have to Cover?

A DPIA that treats memory as a single processing activity will miss most of the risk. The core insight is that different memory tiers carry fundamentally different risk profiles and need separate treatment.

Tier 1: Ephemeral Working Memory

This is the context window. Data that exists for the duration of a single session or inference call and is discarded afterward. The risk here is lower, but not zero. The data still reaches the inference provider. If you're routing requests through a frontier model's API, the contents of that context window leave your infrastructure during processing. Your DPIA should document: what personal data can appear in the context window, what contractual and technical controls govern the provider's handling of that data, and what the retention period is on the provider side. "Short retention window" is the honest answer for most API providers, not zero.

Tier 2: Persistent Structured Memory

Key-value stores, user profiles, explicit preference records. Data that survives across sessions. The risk is higher because the data accumulates over time, creating an increasingly detailed picture of the data subject. Your DPIA should document: the lawful basis for each category of stored data, the retention schedule (not "indefinite"), the mechanism for Article 15 access (can you export a user's complete memory in a readable format?), and the mechanism for Article 17 deletion (does deleting a user's record actually remove it from all indices and caches?). This tier is where most teams do reasonable work. It looks like a database. People understand databases.

Tier 3: Vector Embeddings and Derived Representations

This is where things get hard. If your memory system converts user data into vector embeddings for semantic retrieval, those embeddings are personal data under GDPR if they relate to an identifiable person. The EDPB's Opinion 28/2024 established that AI models trained on personal data generally cannot be considered anonymous. The same logic applies to memory embeddings. Your DPIA for this tier needs to address: whether you can map a specific embedding back to the personal data it encodes (necessary for Article 15), whether you can delete a specific person's contribution to an embedding without corrupting the rest of the store (necessary for Article 17), and what happens when an embedding encodes inferred data that was never explicitly provided by the user (relevant to Article 14 and potentially Article 22 on automated decision-making).

If the answer to any of these is "we can't," that is itself a DPIA finding. It doesn't mean you can't ship the feature. It means you need to document the risk and the mitigations you're applying, and those mitigations might be architectural (don't embed personal data at all, or embed it in per-user scoped namespaces with independent deletion) rather than procedural.

How Does the EU AI Act Change the DPIA Calculus?

It makes it worse. The EU AI Act, with transparency obligations enforceable from August 2, 2026, introduces a Fundamental Rights Impact Assessment (FRIA) that is distinct from the GDPR DPIA. You cannot satisfy both with one document. They cover different risks, have different scope, and serve different purposes.

The more structurally interesting conflict is between the AI Act's audit trail requirements and GDPR erasure rights. For high-risk AI systems, the AI Act requires retaining operational logs for up to 10 years. GDPR Article 17 gives users the right to demand deletion. These two obligations are in direct tension when an audit log contains personal data, which, if the system has memory, it almost certainly does.

The architectural resolution is to separate audit-log retention from user-facing memory retention at the schema level. Audit logs should contain enough to reconstruct what the system did and why, without containing the raw personal data that drove the decision. Pseudonymization with separately stored mapping keys, where the mapping key can be deleted on erasure request while the pseudonymized audit record survives. This is not a legal opinion. It is a design pattern. Your legal team and DPO need to validate it for your specific use case.

What About the ICO's Position on Agentic AI?

The ICO's 2026 guidance on agentic AI treats most agentic deployments touching personal data as warranting DPIA scrutiny. Two points from that guidance deserve particular attention from anyone building memory.

First, the ICO flagged that organizations risk defining the agent's purpose too broadly. "Help the user" is not a specific enough purpose to ground a lawful basis analysis. If your memory system exists to "improve the user experience," you need to decompose that into specific processing purposes, each with its own lawful basis and retention justification.

Second, and this is the one that keeps me up at night: the ICO states that a DPIA for an agent must address what happens when a hallucinated fact cascades across tools and downstream decisions. In a memory-enabled system, a hallucination that gets stored as a "memory" is no longer a transient error. It is a persistent false fact about a data subject, one that will influence every future interaction. This is an Article 16 (rectification) problem, an Article 5(1)(d) (accuracy principle) problem, and a fundamental trust problem. Your DPIA needs to document how the system detects and corrects stored hallucinations. If the answer is "it doesn't," document that too.

Is Memory Itself an Attack Surface the DPIA Should Address?

Yes. This is not theoretical. Research presented at NeurIPS 2025 (the MINJA attack) demonstrated that an attacker can poison an agent's persistent memory using only ordinary queries, with no direct access to the memory store, achieving injection success rates above 95 percent against production architectures.

We have dealt with variants of this in our own systems. When a stored memory becomes an attack vector, the threat model changes fundamentally. The memory is no longer just a data protection concern. It is a prompt injection surface that persists across sessions. An attacker who successfully plants a poisoned memory has, in effect, installed a persistent backdoor in the user's assistant. Every future session loads that poisoned memory into context.

Your DPIA needs a section on adversarial risks to the memory store. What validation happens before data is written to memory? What detection exists for memory entries that resemble injection patterns? What is the blast radius if a single memory entry is compromised? These are not hypothetical risks you can defer. They are demonstrated attacks against shipping systems.

What Does a Complete DPIA for Memory Look Like in Practice?

Here is the structure we think works. Not a template. A minimum viable scope.

1. Processing description per memory tier. Ephemeral, persistent structured, and vector/embedding, each documented separately. What data enters each tier, how long it stays, who can access it, where it is processed.
2. Lawful basis per tier. Not one blanket basis for "memory." Ephemeral context might rely on contractual necessity. Persistent profile data might require consent or legitimate interest with a documented balancing test. Embeddings of personal data need their own analysis.
3. Necessity and proportionality. For each tier: is it necessary to store this data to achieve the stated purpose? Could a less invasive approach achieve the same result? If you're storing everything because it might be useful, that fails proportionality.
4. Data subject rights implementation. How does Article 15 access work for each tier? Can you produce a complete, readable export? How does Article 17 deletion work? Is deletion provable or best-effort? How does Article 16 rectification work for embeddings? Document what you can and cannot do. The DPIA is not a marketing document.
5. Retention policy per tier. "Until the user deletes it" is lazy. Specify maximum retention periods, automated purge schedules, and the criteria for determining when data is no longer necessary for its original purpose. A memory that never forgets is a memory with no retention policy, and no retention policy is itself a DPIA finding.
6. Accuracy and hallucination controls. How do you prevent false data from entering the memory store? How do you detect it after the fact? What is the correction mechanism? Document the residual risk of stored hallucinations influencing future outputs.
7. Security measures. Encryption at rest, access controls, inference-time exposure. If memory content reaches a frontier provider's API during inference (and if you're calling an external model, it does), document that data flow and the contractual controls around it.
8. Adversarial risk assessment. Memory poisoning, persistent injection, cross-session manipulation. What controls exist? What is the residual risk?
9. AI Act alignment (where applicable). If your system might qualify as high-risk under the AI Act, document the audit trail strategy and how it coexists with GDPR erasure rights. Separate the retention schemas.
10. Third-party processor documentation. If memory data is processed by a frontier model provider, that provider is a processor under GDPR. Document the contractual arrangements, the data flows, and the provider's own retention and deletion commitments.

Why Did Nobody Ship This DPIA?

Because it is hard, and because the regulatory guidance lagged the technology by about 18 months. Teams shipped memory features in 2024 and early 2025 without DPIAs because there was no specific guidance saying persistent AI memory required one. The AEPD, ICO, and EDPB have now closed that gap. The AEPD's agentic AI guidance from February 2026 explicitly names memory. The EDPB's coordinated erasure enforcement action signals where investigative attention is heading.

There is also a structural reason. The people building memory features are engineers. The people writing DPIAs are lawyers and DPOs. The gap between "we store user preferences in a vector database with semantic retrieval" and "we process special categories of personal data using automated means with profiling implications" is mostly a translation problem. But it is a translation problem that can result in seven-figure fines. EU regulators issued approximately €2.1 billion in GDPR fines during 2025 alone, with increased focus on AI and automated systems.

The DPIA most teams need to ship is not a legal document with engineering implications. It is an engineering document with legal implications. Start from the architecture. Map the data flows. Identify the tiers. Then hand that to your DPO and ask them to apply the Article 35 framework. Not the other way around.

What Should You Do This Week?

If you have a memory feature in production or in development:

• Audit your memory store. What personal data is in it? Can you enumerate it per user? If not, you have an Article 15 problem before you have a DPIA problem.
• Map your memory tiers. Distinguish ephemeral context from persistent storage from embeddings. If you have been treating them as one thing, stop.
• Test your deletion path. Issue an Article 17 request against your own system. Does the data actually disappear from all tiers, all indices, all caches? If you are using vector embeddings, be honest about whether deletion is provable or best-effort.
• Start the DPIA. Use the ten-point structure above. It does not need to be long. It needs to be honest.
• Check whether the EU AI Act applies. If your system could be classified as high-risk (particularly if it is used in employment, education, credit, or public services), you have a FRIA obligation on top of the DPIA, and the two are not interchangeable.

Memory is what makes an AI assistant feel like it knows you. That is the feature. That is also the risk. The DPIA is the document where you prove you understand the difference.

We built Selina's memory layer to be adaptive and encrypted at rest, with scoped deletion and per-user access controls, because we went through exactly this exercise. Memory is not end-to-end encrypted (a slice of each request reaches a frontier provider at inference), and we think stating that clearly is more useful than pretending otherwise. If you want to see how it works in practice: start a free 7-day trial, no card required.

Michael C.

Founder & Principal Engineer, Selina Labs

Michael builds Selina, a privacy-first AI that remembers you across conversations. He ships security-sensitive AI in production — real attacks, real fixes, measured in minutes and dollars — and writes about privacy, security, and LLMs from that seat. Top Rated Plus and expert-verified on Upwork.

• www.upwork.com
• x.com
• medium.com
• selinalabs.io