GDPR and AI Memory: What Self-Hosting Solves, and What It Doesn't

Updated on 17 October 2026: the paragraph on ZenBrain now describes v0.6.0, whose forget() follows the derivation edge.

Rewritten on 11 October 2026. The earlier version from April was a general guide. It described transfers to the United States as a grey area after Schrems II, although an adequacy decision has applied since July 2023. This version is checked against the legal texts as of 11 October 2026. It is not legal advice; it names the provisions so that you can read them yourself.

TL;DR

• "Is this AI GDPR-compliant?" cannot be answered about a product. Compliance is a property of an operation; the controller is whoever decides on purposes and means.
• Self-hosting takes processors and third-country transfers out of the part you run yourself. Legal basis, purpose limitation, erasure and documentation remain your job.
• AI with memory makes copies: embeddings, summaries, facts drawn from conversations. Erasure therefore means finding every derivation, and something is erased only when a query no longer finds it in any store.
• Since the Digital Omnibus, the AI Act's high-risk obligations apply only from 2 December 2027. Transparency duties and AI literacy already apply.

The wrong question to ask of a product

Under the GDPR, the controller is whoever determines the purposes and means of processing (Art. 4(7)). That is the organisation deploying an AI system, not the vendor of the software. No product can therefore carry a "GDPR-compliant AI" certificate. The useful question is a different one: what does the architecture have to allow so that the operation can meet its duties?

For AI with memory, that question has a point general guides rarely cover. A system that remembers makes copies, and every copy is a place where personal data lives.

What self-hosting solves

If the memory runs on your own hardware under your own administration, that part needs no processor under Art. 28 and no transfer to a third country under Chapter V. How long something is kept and when it is erased is your decision, without asking a vendor.

You draw that boundary yourself, and it often runs differently than expected. Host in an EU cloud and the cloud provider is still your processor. Connect the language model through an external API and the content of every request goes to that provider, even if the memory stays in house. Our memory library ZenBrain makes no network calls of its own; the embedding model and the language model are optional and your choice. Whether data leaves the building is decided by the configuration, not by the library.

What self-hosting does not solve

Self-hosting changes none of the GDPR's duties. You still need a legal basis (Art. 6); purpose limitation and storage limitation apply (Art. 5(1)(b) and (e)); data subjects must be informed (Art. 13 and 14); the record of processing activities must be kept (Art. 30); and where a high risk is likely, a data protection impact assessment is due (Art. 35). Self-hosting makes some of these duties easier to meet. It does not meet them.

For AI with memory, one data-subject right weighs most: erasure under Art. 17.

Erasure in a memory that makes copies

Agent memory derives. A sentence becomes an embedding, a conversation becomes a summary, an episode becomes a fact. Each derivation is a store of its own. Art. 17 requires erasure of the personal data, not only of the one row someone pointed at.

In our specification Four Governance Invariants for Organisational Agent Memory (Zenodo, 16 August 2026, doi:10.5281/zenodo.21964563) we set a criterion for this. Every derivation is recorded as an edge when it is written. An erasure follows those edges into every derived store. And it counts as done only when a query for the erased scope returns zero rows in every derived store. That query is the evidence: a third party can re-run it, whereas a confirmation of deletion can only be believed.

We apply this criterion to our own library. In ZenBrain, consolidate() turns an emotionally weighted episode into a fact; the episode records in its metadata which fact it became (consolidatedInto). Up to v0.5.2, forget(id, layer) deleted exactly one memory and did not follow that edge: forget only the episode and the fact stayed, and the content remained retrievable. The criterion made that gap visible. Since v0.6.0 of 17 October 2026, forget() follows the edge in both directions by default: the episode takes the fact it became, such a fact takes the episodes it was made from, and both take their copies in working memory. The evidence is the query from the specification: after the erasure the tests read the tables directly and expect zero rows, on SQLite and on PostgreSQL. One limit remains: consolidate() has written the note since v0.4.8; an episode promoted earlier is linked only once a later run finds its verbatim fact among the 100 most recent episodes.

The specification names one limit explicitly. If an erased statement returns as a paraphrase, for instance because a language model carried it into another fact, that is a separate and harder problem. The criterion covers only derivations recorded as edges.

Erasure duty against record-keeping duty

The AI Act requires high-risk AI systems to allow the automatic recording of events over the lifetime of the system (Art. 12). Providers and deployers keep these logs for at least six months, "unless provided otherwise in applicable Union or national law, in particular in Union law on the protection of personal data" (Art. 26(6); to the same effect for providers, Art. 19(1)). Where the two collide, the regulation itself gives data protection precedence.

In practice the tension remains: a log should show what happened without keeping the erased content. The specification resolves it by separating the record of events from the recoverability of content. That a flow and an erasure occurred remains in a tamper-evident history; the content becomes unrecoverable. A redacted history is still a history, and that residue cannot be removed without abandoning the record-keeping duty.

What the AI Act requires, and when

The Digital Omnibus, Regulation (EU) 2026/1744 of 8 July 2026, in force since 27 July 2026, moved the dates:

• Since 2 February 2025: the prohibitions under Art. 5 and AI literacy under Art. 4. Providers and deployers take measures to support the AI literacy of their staff; since the July 2026 revision they are not required to guarantee a particular level.
• Since 2 August 2026: the transparency duties under Art. 50. People who interact with an AI system must be informed of it, unless that is obvious.
• From 2 December 2026: two prohibitions newly inserted by the Omnibus, among them AI systems that generate intimate depictions of an identifiable person without that person's explicit consent.
• From 2 December 2027: the obligations for high-risk systems under Annex III, including logging, human oversight and data governance.
• From 2 August 2028: high-risk systems embedded in products under Annex I.

Whether a particular use is high-risk depends on the use case, not on the technology behind it.

Transfers to the United States: status October 2026

Since 10 July 2023, Commission Implementing Decision (EU) 2023/1795 on the EU-US Data Privacy Framework has applied. Transfers to organisations on the Data Privacy Framework List need no further safeguards under Art. 46. The General Court dismissed the action against the decision on 3 September 2025 (T-553/23, Latombe v Commission). An appeal is pending before the Court of Justice (C-703/25 P); no judgment has been published as of 11 October 2026.

If you use US services, you rely on a decision that is valid but under challenge. Self-hosting takes that dependency out of the part you run yourself.

Five steps for the operation

1. Map the data flows. Where do the memory, the embedding model and the language model run, and which request leaves the building?
2. Name the derived stores. Embeddings, summaries, facts drawn from episodes, caches. Record each derivation as an edge when it is written, or you will not find it later.
3. Define erasure as a query. After an erasure request, a query for the erased scope returns zero rows in every derived store. That query belongs in the pipeline as a test.
4. Log events, not content. Reads, writes and erasures are recorded tamper-evidently; the content itself stays out of the log.
5. Clarify role and risk class. Provider or deployer under the AI Act, Annex III or not, check the impact assessment, update the Art. 30 record, AI literacy under Art. 4.

How we accompany companies and public bodies through these steps, from adoption to co-determination, is set out under How to adopt AI the right way.