Managing personal data in vector databases: why embeddings are not anonymous storage

Treat embeddings as a processing of personal data, not as anonymous storage: recent research shows embeddings can be traced back to the source text. Limit what you embed, scan exported vectors for hidden personal data, restrict access and retention periods, and demonstrably record deletion or re-embedding.

The occasion is concrete. IronCore Labs announced VectorLens in late June 2026, a tool with which security teams can scan exported embeddings locally for hidden personal data in vector databases, including unmanaged or orphaned vectors. The message behind such a product is more relevant to privacy professionals than the tool itself: the idea that data is "gone" after embedding does not hold up. Anyone working with confidential case files must treat the embedding layer as part of the data processing.

Can embeddings really contain personal data that is traceable?

Yes, and this is not merely theoretical. An embedding is a numerical representation of text, but that representation is not a random hash. Researchers show that embeddings can be reverse-engineered back to the original text through so-called embedding inversion. In the arXiv paper Does Vec2Text Pose a New Corpus Poisoning Threat? the authors show that reconstructing source text from vectors can, moreover, strengthen corpus-poisoning attacks against dense retrievers.

In practice this means two things. First: if the source text contains personal data, the embedding can contain an approximate copy of it. Second: a vector database is not only a privacy risk in the event of a leak, but also an attack surface that can be manipulated. In our estimation, the most common misconception is that teams regard embeddings as anonymous derivatives, when they are in fact a compressed version of the content.

What does the EDPB opinion on AI models mean for my vector database?

In Opinion 28/2024, the European Data Protection Board states that the development and deployment of AI models may involve personal data, that controllers must be able to demonstrate lawful processing and accountability, and that anonymity must be proven case by case rather than assumed. In doing so, the EDPB explicitly names web scraping, output filters and documentation as relevant safeguards.

Extended to embeddings, this means: you cannot claim that vectors are automatically anonymous. If source text containing personal data ends up in the vector database, that processing falls within the scope the EDPB describes. This calls for demonstrability: can you show what has been embedded, where it is stored and whether it is traceable? Our editorial reading is that the opinion effectively pulls the vector database into the GDPR lifecycle, even though the document does not mention embeddings in so many words. Anyone who wants to assign responsibilities per phase will find a usable framework in the discussion of GDPR responsibilities per phase of your AI workflow, and the broader topic hub on AI privacy and GDPR bundles adjacent questions.

Which controls do I use to find and remove hidden personal data in embeddings?

The practical core of this article: treat the embedding layer as a processing in its own right with its own controls. We recommend, as an editorial interpretation based on the sources named, a control set that covers the full lifecycle.

• Embedding minimisation: determine in advance which fields and document parts are embedded at all and keep personal data out of the source text where possible. This aligns with the data-minimisation principle that also appears in providers' privacy policies.
• Export-and-scan controls: export embeddings periodically and scan them for traceable personal data, including vectors that are no longer linked to a known case file. This is exactly the gap IronCore Labs addresses with VectorLens.
• Access control: restrict who can read out or export the vector store, because inversion only works if someone can reach the vectors.
• Retention periods: tie embeddings to retention limits instead of letting them stand indefinitely. Anthropic describes in its privacy policy for consumer services principles such as short retention periods, separated log data and explicit data flows; the same logic can be translated to prompts, chunks and embeddings.
• Documented deletion or re-embedding: record how you delete or regenerate a vector when source data must be corrected or erased, so that a deletion request also reaches the vector layer.

An additional decision is where you generate and store embeddings. Anyone weighing whether that should happen locally or in the cloud will find a concrete audit approach in our explanation of auditing local versus cloud AI per workflow. A second decision sits at the source: if sensitive values never reach the embedding layer in readable form, you structurally reduce the inversion risk. In this light, an architecture that replaces sensitive document values with synthetic, session-only equivalents on EU infrastructure before AI processing is relevant. Vera's anonymisation before processing with the Semantic Privacy Shield is set up so that only anonymised content is sent onward; if the privacy verification fails, the document is not sent onward. That reduces what there is to embed and reconstruct, but the final judgement on which data is sensitive remains with you.

How does this fit into the broader security of my AI pipeline?

Embeddings are not separate from the rest of the pipeline. In July 2026, Hugging Face described in a technical reconstruction of a frontier-lab intrusion how weak spots in datasets and pipelines gave attackers access to internal systems. That case is not specifically about embeddings, but it underlines the broader point: once AI processing layers expose internal artefacts, attackers can move through them. A vector store full of traceable personal data is precisely such an artefact.

Our conclusion, as editorial analysis: the vector database does not make privacy disappear, it merely compresses it. The right question is not whether embeddings contain personal data, but whether you can demonstrate what is in them, who can reach them and how you delete it. Anyone who also wants to treat prompts as personal data will find a matching approach in our analysis on treating prompts as personal data in AI workflows. The controls above are not a watertight guarantee, but they are the basis for making the embedding layer manageable and demonstrable.

Sources: The article draws on the EDPB's Opinion 28/2024, the arXiv paper on Vec2Text and corpus poisoning, IronCore Labs' VectorLens announcement, Hugging Face's intrusion reconstruction and Anthropic's privacy policy.

← All articles in this topic ← All articles