Can Your Company Brain Actually Forget? What the Right to Erasure Really Means for AI Memory

On 18 February 2026, the European Data Protection Board published the results of its largest coordinated audit of the right to erasure ever conducted: 764 organisations examined across 32 authorities in the European Economic Area, with nine authorities opening or continuing formal investigations as a result¹. The verdict on how European companies handle deletion requests was blunt - overall compliance is only “average,” with recurring failures in procedures, retention, backups, and the misuse of anonymisation as a stand-in for deletion¹.

That report landed at an awkward moment. The same companies being audited are racing to build AI memory - a company brain that remembers every email, every ticket, every customer note, so that AI can actually know the business. A memory that remembers everything is exactly what the right to erasure was written to interrupt. When a customer, an employee, or a job applicant asks you to delete their data, a system designed never to forget has a problem it was not built to solve.

This article is for the CTO, data protection officer, or Geschaeftsfuehrer who is building an AI knowledge layer and needs it to survive contact with Article 17. It covers what erasure legally requires, why it is genuinely hard when personal data is encoded across embeddings, backups, and derived context, and how to architect a company brain that can forget one person on request without wiping out what the whole company knows.

The Forgetting Problem Nobody Designed For

The whole promise of a company brain is that it does not forget. Staff leave, memories fade, files get lost, but the brain keeps the process, the decision, and the context. That is a genuine advantage right up until a person exercises a right that the law has guaranteed them since 2018 - the right to have their personal data erased.

• A memory layer copies data everywhere - One customer email does not sit in one place. It is stored, embedded into vectors, summarised into context, cached for speed, and written into logs. A deletion request has to reach every one of those copies.
• The link back to the person is often missing - Once text becomes an embedding in a vector index, there is frequently no identifier tying that vector to the individual, which makes finding their data a search problem rather than a lookup.
• Anonymisation is quietly overused - The EDPB found controllers relying on weak or reversible anonymisation instead of real deletion, which does not satisfy Article 17 if the person can still be re-identified¹.
• Backups are treated as untouchable - Half of the participating authorities flagged deleting data from backups as a specific weak point, because teams assume an archive is out of scope. It is not¹³.
• Nobody tests it until it is real - Most teams discover the gaps in their erasure process only when the first serious request arrives and they cannot answer it within the one-month legal window⁷.

The uncomfortable truth is that most AI memory is built for accumulation, not subtraction. Deletion was an afterthought, if it was thought of at all. That gap is what the rest of this article closes.

What Article 17 Actually Requires

Before solving the technical problem, it helps to be precise about the legal one. The right to erasure is Article 17 of the GDPR, and it is narrower and more specific than the popular phrase “right to be forgotten” suggests⁶.

When a person can demand erasure

Article 17(1) gives a person the right to have their data deleted without undue delay in six defined situations⁶.

• No longer necessary - The data is no longer needed for the purpose it was collected for.
• Consent withdrawn - Processing relied on consent and the person takes that consent back.
• Objection upheld - The person objects under Article 21 and there is no overriding legitimate ground to continue.
• Unlawful processing - The data was processed unlawfully in the first place.
• Legal obligation - Erasure is required to comply with an EU or member-state legal duty.
• Children’s data - The data was collected from a child in the context of online services.

The exceptions that let you keep data

Erasure is not absolute. Article 17(3) lets you retain data where it is genuinely needed, and getting these boundaries right matters as much as deleting⁶.

• Freedom of expression - Where processing is needed for the right to free expression and information.
• Legal obligation or public task - Where a law requires you to keep the data, such as tax or accounting retention periods.
• Public health - Certain processing in the public interest in the area of public health.
• Archiving, research, statistics - Where deletion would seriously impair legitimate archiving or scientific work.
• Legal claims - Where the data is needed to establish, exercise, or defend legal claims.

The clock and the cost

• One month to respond - You must act on a request without undue delay and in any case within one month, extendable by two further months for complex cases if you tell the person why⁷.
• No charge in normal cases - You cannot charge a fee for a standard erasure request.
• You have to confirm it is done - The person is entitled to know their request has been actioned, which means you need to be able to show it.
• The fines are top-tier - Breaching Article 17 falls in the higher GDPR penalty band, up to 20 million euros or 4 percent of total worldwide annual turnover, whichever is higher⁸.

Why Erasure Is Genuinely Hard in an AI Memory Layer

The law says delete the personal data. The engineering reality is that a company brain does not store personal data as one tidy row you can drop. It transforms and scatters it, and each transformation creates a new place a person can hide.

Embeddings are personal data you cannot read

When your brain ingests a document, it converts the text into embeddings - long lists of numbers that capture meaning so AI can search by concept. That vector looks anonymous. It is not.

• Embeddings can be inverted - Cornell researchers showed a method that reconstructs up to 92 percent of short texts exactly from their embeddings alone, and recovered full names from clinical notes⁹. An embedding of someone’s data is their data.
• The link to the person is usually absent - Vectors are stored for similarity search, not for lookup by individual, so there is often nothing that says “these 40 vectors belong to this customer.”
• Soft deletes leave ghosts - Marking a vector as deleted without removing it can leave it reconstructible in the index, so the data is still there for anyone who can read the store.
• Re-embedding does not help - If the source is gone but the vectors remain, the personal data remains. Deletion has to hit the vectors, not just the file they came from.

Derived context bakes the name in

A company brain does not just store data, it generates new text from it - summaries, briefings, answers - and a person’s name or details can be welded into that generated content.

• Summaries inherit the personal data - A summary of a customer thread contains the customer. Delete the thread and the summary still names them.
• Fine-tuned models memorise - If personal data was baked into a fine-tuned model, IBM Research notes that the sheer size of these models makes isolating and removing specific facts especially difficult¹⁰.
• Unlearning is not deletion - Recent research shows models can appear to forget while their original behaviour is restored with minimal fine-tuning, meaning unlearning often obscures rather than erases¹¹.
• Filtering the output is not erasure - Blocking a name from appearing in answers is not deleting the underlying data, and regulators treat it as an imperfect workaround, not compliance¹².

This is why erasure has to be an architecture decision, not a script you write after the fact. If you did not plan for it, the data may not be removable at all without rebuilding the store.

What the EDPB Found in 2026

The right to erasure was the topic of the EDPB’s 2025 Coordinated Enforcement Framework action, and the results published on 18 February 2026 turned a legal principle into a concrete enforcement agenda for the year ahead¹⁵.

• The scale was unprecedented - 764 controllers, from SMEs to multinationals, assessed by 32 authorities across the EEA in the largest coordinated erasure audit to date¹.
• Compliance was rated average - Not failing, but far from good, with the same problems appearing across countries and sectors¹.
• Procedures were missing - A large share of authorities found controllers had no documented internal procedure for handling erasure requests¹³.
• Backups were a common gap - Half of the participating authorities flagged unclear or absent processes for deleting data held in backups¹³.
• Anonymisation was misused - Controllers leaned on weak anonymisation as a substitute for deletion, which fails if data can be re-identified¹.
• Follow-up is real - Nine authorities opened or continued formal investigations, and 23 ran fact-finding exercises, so this was not a paper exercise¹.

The message to any company building AI memory is direct: regulators are now actively checking whether you can delete a person on request, and “we anonymised it” or “it is only in backups” are the exact answers they have marked down.

Deletion by Design: Architecting a Brain That Can Forget

The fix is not a clever delete script. It is designing the memory so that removing a person is a planned, routine operation from the first day, the same way you design for security or backups. Here is what that looks like in practice.

1. Tag identity at ingestion - The moment any personal data enters the brain, attach the person and source it belongs to. Every embedding, summary, and cache entry inherits that tag, so later you look data up instead of hunting for it.
2. Attach a retention rule to everything - No piece of personal data enters without a defined lifetime and a lawful basis. Data with no reason to exist expires on its own, shrinking the surface a request has to cover.
3. Make derived data point home - Summaries, embeddings, and generated context keep a reference to their source records, so deleting the source cascades to everything derived from it.
4. Delete hard, not soft - Removal means the vector and the text are gone from the index, not flagged as hidden, so nothing reconstructible is left behind.
5. Give backups a beyond-use rule - You cannot always edit an archive, so mark the data to be excluded from any restore and re-deleted if a backup is ever brought back, then let the backup age out¹⁵.
6. Keep humans and AI reading the same store - When there is one governed memory rather than ten shadow copies in inboxes and chat tools, there is one place to delete from.
7. Test erasure like you test restores - Run a real deletion end to end on a schedule. An erasure process you have rehearsed is one you can complete inside the one-month window.

None of this makes the brain worse at its job. It makes the brain trustworthy, which is the precondition for putting real company knowledge into it at all.

Forgetting One Person Without Losing Institutional Knowledge

Here is the fear that makes companies hesitate: if we delete a customer, do we lose everything we learned from working with them? The answer, with the right design, is no - because the person and the knowledge are two different things.

Separate the individual from the institutional

• Personal data is the person - Their name, contact details, the content of their messages, anything that identifies them. This is what Article 17 requires you to erase.
• Institutional knowledge is yours - The process your team followed, the reason a decision was made, the general lesson learned. Stripped of identifiers, this is usually not personal data at all.
• The pattern survives the person - “Customers in this segment churn when onboarding takes over two weeks” is knowledge you keep. The specific customer who taught you that can be erased.
• An exception becomes a rule - How your team handled an unusual claim is a reusable process. It does not need the claimant’s identity to remain valuable.

Where this makes the difference

1. A departing employee - Their personal file is erased, but the process they documented, the supplier quirks they logged, and the way they solved a recurring problem stay in the brain for the next person.
2. A former customer - Their contact history and personal details go, while the anonymised insight about how that type of deal was won or lost remains.
3. A rejected applicant - Their application data is deleted on schedule, but the calibrated understanding of what a strong profile looks like is retained without any identifiers.
4. A closed supplier relationship - Personal contacts are removed, while the negotiated terms and the lessons about that category of supplier persist.

Provable Erasure, Retention Policies, and EU Soil

Deleting the data is half the job. The other half is being able to show you did it, on the terms the regulator now expects after the 2026 report singled out weak procedures and evidence¹.

Prove it with an erasure log

• Record the event, not the person - Log that a request arrived, what categories were deleted, from which systems, and when - using a reference rather than storing the personal data again.
• Make deletion auditable - An erasure log turns an unverifiable claim into an event a supervisory authority can check, which is what most audited controllers could not produce¹³.
• Confirm back to the person - Article 17 expects you to action the request and be able to confirm it, so the log doubles as your response evidence⁶.
• Track the cascade - The log should show the delete reached derived data, not just the source record.

Retention policies do half the work for you

• Define a lifetime per data type - When data expires automatically, most personal data never lives long enough to become an erasure problem.
• Map lawful basis to retention - Tax and accounting data has a legally required retention period; a casual enquiry does not. Encode that difference.
• Default to delete - Keep data because a rule says to, not because deleting it never occurred to anyone.
• Review retention as an operation - Retention that is written down but never enforced is exactly the gap the EDPB found across sectors¹.

How Superkind Fits

Superkind builds a company brain and AI employees on top of the systems you already use, and the brain is architected so that forgetting a person is a routine operation rather than a rebuild. Deletion, retention, and provable erasure are part of the design, not features bolted on after an audit.

• Deletion by design - Personal data carries an identity tag and a retention rule from the moment it enters the brain, so a request becomes a lookup, not a hunt.
• Cascading erasure - Removing a person clears the source, the embeddings, the derived summaries, and the caches together, not just the obvious copy.
• Institutional knowledge preserved - The anonymised process and lesson stay in the brain when the individual is deleted, so you forget the person and keep what you learned.
• Provable erasure - An erasure log records what was deleted, from where, and when, giving you the evidence the EDPB found most controllers lacked.
• Retention built in - Every data type has a defined lifetime and a lawful basis, so most personal data expires long before anyone has to request it.
• Runs on EU soil - The knowledge layer can run on EU infrastructure under your governance, so the deletion keys and retention rules stay with you.
• Sits on top of your stack - It connects to email, Teams, SharePoint, CRM, and ERP as one governed memory, so there is one place to delete from instead of ten shadow copies.
• No rip-and-replace - Nothing gets torn out; the brain is a layer over the systems you already run, and it gets sharper as your team uses it.

Is Your Company Memory Erasure-Ready? A Decision Framework

Use these signals to judge how exposed your AI memory is to the next erasure request, and what to do about it.

Frequently Asked Questions

Henri Jung

Co-founder of Superkind, where he helps SMEs and enterprises deploy custom AI employees that actually fit how their teams work. Henri is passionate about closing the gap between what AI can do and the value it creates in real companies. He believes the Mittelstand has everything it needs to lead in AI - it just needs the right approach, built on a company brain that is trusted enough to hold real knowledge, which means it has to be able to forget on request as cleanly as it remembers.