Are AI embeddings personal data?

Very often yes. An embedding is a numerical representation derived from source text, and where that source contains personal data and the embedding can be linked back to an identifiable person, whether through the stored pairing with the original chunk, attached metadata, or re-identification from the vector itself, the UK GDPR definition of personal data is engaged. The ICO's position on anonymisation asks whether re-identification is reasonably likely, not whether the data merely looks scrambled, and a vector that sits alongside its source text or a lookup key clears that bar easily.

The question matters because embeddings sit underneath almost every retrieval-augmented AI system deployed in 2026, and treating them as a mere technical artefact rather than a data protection object leaves a gap regulators and claimants are increasingly alert to.

Why does an embedding count as personal data at all?

Because it is derived data, not raw data stripped of meaning. An embedding encodes the semantic content of the text it came from closely enough to support search and retrieval, which is precisely why it is useful, and precisely why it can carry the identifying signal of its source along with it. A vector that lets you find the passage about a named individual's medical history is functionally still about that individual, even though no human can read the numbers directly.

Can an embedding be re-identified from the vector alone, without the source text?

This is an active area of research, and no court has settled it, so it should be treated as regulatory-risk analysis rather than established law. What is not in dispute is the more common and mundane case: most production systems store the embedding alongside its source chunk or a pointer back to it, which makes re-identification trivial regardless of what is theoretically extractable from the vector in isolation.

Is sending embeddings to a vendor cloud a personal data transfer?

Where the embeddings relate to identifiable people, yes, in substance if not always in the vendor's own framing. A vector database hosted by a third party is a processor relationship like any other, engaging the same UK GDPR obligations around lawful basis, contract terms and, where the vendor or its infrastructure sits outside the UK, international transfer rules. Treating a vector store as somehow outside data protection scope because it holds numbers rather than words is the mistake.

Do subject access and erasure requests reach the embedding layer?

They should, wherever the embedding relates to an identifiable person. A DSAR under UK GDPR Article 15 in principle reaches any personal data held about the requester, including derived data such as embeddings, and an erasure request under Article 17 should in principle be able to remove a vector along with its source chunk. Erasure of a vector plus its associated text is technically feasible and should be designed into the system from the start, rather than discovered as a gap when the first request arrives.

What does an incomplete DPIA on an AI system usually miss?

The vector store itself. Data protection impact assessments for AI systems routinely cover the model, the prompts and the outputs, and stop before reaching the embedding layer that sits underneath retrieval. A DPIA that does not ask where embeddings live, how long they are retained, who can query them and how they would be found and deleted on request is incomplete, whatever else it covers well.

How does retention policy apply to embeddings?

The same way it applies to any other personal data: a defined retention period tied to purpose, not indefinite storage because the format is unfamiliar. An organisation that has a clear retention schedule for documents but an undefined one for the embeddings generated from those documents has, in effect, two retention policies for the same underlying personal data, and only one of them is enforced.

Where does keeping the embedding store inside the operator's own boundary help?

It turns a vendor negotiation into an engineering task. When the vector store lives inside infrastructure the operator controls, questions about international transfer, sub-processor authorisation and vendor retention windows do not arise in the first place, because there is no third party in the chain. On Mickai, a Sovereign Intelligence Operating System, the embedding layer runs offline on operator-owned hardware, and we seal what was embedded, when, and what touched it to the audit ledger, so a DSAR or an erasure request can be answered from one queryable place rather than chased across a vendor's infrastructure.

“An embedding you cannot find and cannot delete is still personal data, it is just personal data you have lost control of.”

How the embedding layer sits inside a single operator-owned boundary with a sealed record is set out at /sovereign-ai, and the film at /film shows the interface in operation.

Frequently asked questions

Are embeddings always personal data?

Not always, only where they are derived from content containing personal data and can be linked back to an identifiable person through the stored pairing, metadata or re-identification. Embeddings of purely non-personal technical or public content generally fall outside the definition.

Can I anonymise embeddings by stripping the source text after generating them?

Removing the paired source text reduces risk but does not automatically achieve anonymisation, since the ICO's test asks whether re-identification remains reasonably likely by any means, including from the vector itself in some research contexts. Treat this as risk reduction, not a guaranteed fix, until the law and the research settle further.

Does a DSAR require us to search our vector database?

Where the vector database holds personal data about the requester, an Article 15 request in principle extends to it, and being unable to search the store is not a defence to the obligation, only evidence that the search capability needs building.

Is sending text to a third-party embedding API a data protection risk?

Where the text contains personal data, sending it to any third-party processor engages the usual UK GDPR obligations: lawful basis, processor contract terms, and international transfer rules if the provider or its infrastructure sits outside the UK. This applies to embedding APIs exactly as it applies to any other processing service.

How long should embeddings be retained?

For no longer than the purpose that justified creating them, mirrored to the retention period of the source data wherever practical. An embedding store with no defined retention period, sitting alongside a document store that does have one, is a gap worth closing before a regulator or a requester finds it first.