Yes, if you can reach every copy. A UK GDPR Article 17 request covers the source document, the search index, the stored embeddings and your backups. Soft deletion that only hides a record is not erasure. With Mickai the index sits on hardware you own, so removing a document stops it informing answers.
Does the right to erasure apply to an AI knowledge base?
It does. Article 17 of the UK GDPR attaches to the personal data, not to the format holding it. If a person's data sits in a document your assistant can retrieve, it is in scope, and the ICO's guidance on the right to erasure is the place to start rather than a vendor's help pages.
The right is not absolute. You can refuse where you have a lawful basis to continue processing, where retention is required to meet a legal obligation, or where one of the exemptions in Article 17(3) applies. What you cannot do is treat the knowledge base as a special case because cleaning it is awkward. A regulator will not accept that, and neither will the person who asked.
So the question stops being legal very quickly and becomes an engineering one. Can you enumerate every copy of that person's data inside the system, and can you show what happened to each copy? Most organisations I speak to can answer the first half. The same gap shows up when they try to answer a subject access request about AI processing.
Where does a person's data actually sit in an AI system?
In more places than the document store. Before you respond to an erasure request, write the list down for your own architecture. For a retrieval-based internal knowledge AI hub it usually looks like this.
The original file, as uploaded. The extracted text, produced when that file was parsed. The chunks the text was split into for retrieval. The keyword index built over those chunks. The vector index holding their embeddings. Any cache of recent retrievals. The conversation history where the assistant quoted the document back to a user. Any test or quality-assurance set into which somebody copied a real record. The audit trail covering all of it. And every backup or snapshot that has touched any of the above.
That is ten places, and nine of them are invisible in a normal file browser. An erasure workflow that deletes the first one and nothing else leaves the person's data live in retrieval, where it will keep turning up in answers. This is the most common failure I see in internal AI deployments, and it is rarely negligence. Nobody drew the map.
Why is soft deletion not erasure?
Because a soft delete is a flag, and a flag is only a filter. Most systems mark a record deleted, hide it from the default query path, and leave the bytes where they were. That is useful for undo. It is not erasure. The record stays readable by anyone with database access, stays in the index unless the index is rebuilt, comes back through any query that forgets to apply the filter, and goes straight into the next snapshot.
The test I use is blunt. After the deletion runs, can somebody with ordinary administrative access read the erased content without restoring a backup? If yes, you have hidden the data, not erased it.
Use those words internally, because the gap between "deleted in the interface" and "removed from storage and index" is exactly where erasure responses fall apart under scrutiny. If you genuinely cannot remove something yet, the defensible position is to put it beyond use and record why. Relabelling concealment as deletion is how a reasonable technical limit turns into a misleading statement to a regulator.
Are embeddings personal data, and can they be reconstructed?
Treat them as personal data. An embedding is a numerical representation derived from one specific passage of text, and a growing body of research on embedding inversion shows that text can be partially recovered from stored vectors by someone holding both the vectors and the embedding model. A 2026 preprint on recovery from vector stores in retrieval systems examines this directly. I am not going to quote recovery figures at you, because the figure is not the decision. The direction of travel is what matters: vectorisation is not an anonymisation step and should not be relied on as one.
The practical consequence is that an erasure job has to delete the vectors alongside the chunks, and has to confirm removal in the index rather than assume it. Some index structures do not reclaim space on delete, which means a rebuild or compaction step belongs in the workflow rather than in a backlog. Ask whoever supplies your index which of those two behaviours you have, and whether the answer can be checked rather than taken on trust.
How far does erasure reach into backups?
Into them. The ICO is direct about it: an erasure request covers backup systems as well as live ones, and where data cannot be removed from a backup immediately you should be clear with the individual about what will happen to it. The accepted position is that the data is put beyond use and the backup is kept only until it is overwritten in the normal course of your retention schedule.
Two things therefore have to be true. Your backup retention period must be short enough, and documented well enough, that "it will be overwritten" is a statement with a date attached rather than a hope. And your restore procedure must re-apply outstanding erasures, because a restore that quietly reinstates deleted records undoes the work and nobody notices for months. Write that step into the runbook.
There is also real tension between this and the record-keeping duties set out in the EU AI Act, which I have set out in GDPR says delete, the AI Act says keep the record. It is a tension to manage deliberately, not one anybody has solved.
What do we keep as evidence that erasure happened?
The fact, not the content. You need to show that a request arrived, who assessed it, what was decided, which stores were reached and when. You do not need, and should not keep, a copy of the erased material as proof that you erased it.
In the Mickai Sovereign Intelligence Operating System a deletion is a consequential action, so it waits for a named person to approve it. The Open Audit Record then seals the approval and the outcome under ML-DSA-65, the post-quantum signature scheme NIST published as FIPS 204 in 2024. An auditor exports that record and verifies it offline with a public key, using tools that are not ours.
That makes the record tamper-evident, not tamper-proof, and the distinction is the point. Nothing physically stops a person altering an entry. Altering it makes verification fail, and the failure is visible to whoever checks. Evidence you can only validate inside the system that produced it is not really evidence. I have written more on Article 17 and sealed records.
How does this change when the AI runs on hardware you own?
It makes the list finite. When the index, the embeddings and the logs sit on machines inside your own estate, erasure is a job you run and verify, not a ticket you log with a processor and then wait on. There is one boundary to reason about. There is no third-party copy to chase, because nothing was sent anywhere. You can walk an auditor to the machine.
That is the design behind our brains, the 50 specialised models that carry a customer's private knowledge: documents are indexed on hardware the customer owns, offline capable, with no data egress, so removing a document from the index stops it informing answers. It does not make the backup question disappear and I would not claim otherwise. What it removes is the part of the problem you cannot see, which is the part that costs you in front of a regulator. That is the broader case for sovereign AI.
None of this is an argument against the companies building the compute and cloud layer. Cloud stays valuable for work that is not regulated. The argument is against the assumption that a regulated organisation must rent its intelligence, ship the documents offsite, then take a supplier's word for what was done with them when somebody asks to be forgotten.
One honest limit while the platform is in closed beta, with a single regulated company onboarding as a design partner: a local OCR runtime has read scanned PDFs in controlled tests, and extraction and ingestion integration is still being completed.
Frequently asked questions
Do we have to delete data from an AI search index on request?
Yes. The index holds a copy of the personal data, so it is in scope of the erasure request in the same way the source file is. Removing the document while leaving its chunks and vectors in the index means the assistant can still retrieve and quote the content. Confirm removal in the index rather than assuming the delete propagated.
Are embeddings personal data under UK GDPR?
Treat them as personal data. An embedding is derived from a specific passage about a specific person, and research on embedding inversion shows stored vectors can yield partial recovery of the original text where someone holds both the vectors and the embedding model. Vectorisation is not anonymisation, so embeddings belong inside the scope of an erasure job.
Does deleting the original document remove it from AI answers?
Not on its own. The extracted text, the chunks, the keyword index, the vector index and any retrieval cache are separate copies. Unless deletion reaches those, retrieval keeps working and the assistant keeps citing content you believe is gone. Ask your supplier whether deletion cascades to the index, and whether a rebuild or compaction step is needed.
How do we show the ICO that we completed an erasure?
Keep the fact, not the content. Record when the request arrived, who assessed it, the decision and its basis, which stores were reached, and the date each was cleared. In SIOS that approval and its outcome are sealed in the Open Audit Record under ML-DSA-65, so an auditor can verify the export offline with a public key.
Can we refuse an erasure request for research data?
Sometimes. UK GDPR provides an exemption where personal data is processed for scientific or historical research or statistical purposes and erasure would seriously impair that work, subject to appropriate safeguards. It is a narrow exemption rather than a blanket one. Document the assessment for each request, and explain the reasoning to the person instead of sending a template refusal.
Delete this sixth FAQ item in full (question and answer) so the FAQ has five entries. The point is already answered at length under the H2 "How far does erasure reach into backups?", so nothing is lost.
Yes. The ICO's position is that an erasure request covers backup systems as well as live ones. Where immediate deletion is not possible, be clear with the individual, put the data beyond use, and keep the backup only until it is overwritten on your normal retention schedule. Make sure a restore re-applies outstanding erasures.
Related briefings
Data protection and UK GDPR
- UK GDPR and AI: Does Your Data Have to Stay in the UK?
- UK Data Storage vs AI Processing: What Is the Difference
- Controller or Processor? AI Suppliers and UK GDPR Roles
- Employee Pasted Client Data Into AI: Is It a Breach?
- AI Call Transcription and UK GDPR: What Firms Must Do
Governance, audit and oversight
- Tamper-Evident vs Immutable Log: The Real Difference
- Human on the Loop vs In the Loop: AI Oversight Explained
Part of a series of 60 briefings on deploying and governing AI in UK regulated organisations, archived with a DOI at 10.5281/zenodo.22975756.
Evaluating AI for a regulated organisation? Mickai runs on hardware you own, offline. Consequential actions wait for a named person to approve them, and what the AI did is sealed into a signed record an auditor can check without us. Applications for the invitation-only closed beta are open. Apply for the closed beta.
Written by Micky Irons, founder and chief executive of Mickai LTD.
Top comments (0)