Yes — in practice you should treat vector embeddings of personal data as personal data. Embedding inversion research has shown that the original text can be reconstructed from dense text embeddings, including names from clinical notes. If a vector can be turned back into the sentence that produced it, the vector still relates to an identifiable person. That means your vector store carries the same duties as the documents it indexes: lawful basis, access control, erasure, residency, and breach response.
Whether a given embedding is personal data under GDPR is ultimately a legal assessment of identifiability for your context, and regulators have not issued embedding-specific guidance that settles every case. But the engineering evidence points one way, and designing as if embeddings were anonymous is the riskier bet.
What Embedding Inversion Shows
The intuition many teams hold is that an embedding is a one-way hash: 768 or 1,536 floating-point numbers that capture "meaning" but cannot be read back. That intuition is wrong.
In Text Embeddings Reveal (Almost) As Much As Text, Morris et al. frame inversion as controlled generation: generate text, embed it, compare to the target vector, correct, repeat. The authors report that this iterative method recovers 92% of 32-token text inputs exactly against the embedding models they trained on, and that it recovers personal information such as full names from a dataset of clinical notes. Their code is public.
Three implications follow:
- Embeddings are not anonymisation. They are an encoding. A good encoding of text is, by design, informative about that text.
- The attacker needs the vectors and access to the embedding model, or a close substitute. Widely used hosted and open embedding models make the second part easy.
- Short chunks are the most exposed. RAG pipelines typically split documents into short chunks, which is the regime where the published reconstruction results are strongest.
Why This Puts Vector Stores in GDPR Scope
GDPR applies to information relating to an identified or identifiable person. A vector from which a name, diagnosis or email address can be recovered relates to that person. Even before inversion, most vector stores keep the source chunk text alongside the vector for retrieval, so the store usually holds personal data in plain form anyway.
Once you accept that, the duties line up:
| GDPR duty | What it means for a vector store |
|---|---|
| Lawful basis and purpose limitation | Embedding customer data for a support bot needs a basis that covers that use, not only the original collection purpose |
| Data minimisation | Embed only fields the retrieval use case needs; strip identifiers that add nothing to relevance |
| Right to erasure (Art. 17) | Deleting a subject's documents must also delete every chunk, vector, summary and cached result derived from them |
| Storage limitation | Retention rules on source records must apply to their vectors |
| Security of processing (Art. 32) | Vector stores need encryption, access control and audit like any database holding personal data |
| International transfers and residency | Where the vectors and the embedding API live matters, not only where the source database lives |
| Breach notification | A leaked vector dump is a personal data breach to assess, not "just numbers" |
Erasure is where most pipelines break. See GDPR for AI systems and erasure rights for the wider problem of deleting a person from logs, memory and model context.
Erasure in a Vector Store
You cannot "find the vectors about Alice" by similarity search reliably. Erasure needs lineage:
- Store the source document ID (and ideally the data subject ID where known) as metadata on every chunk and vector.
- Map subjects to documents in the source system or a privacy index.
- On an erasure request, delete by metadata filter, not by similarity. Delete the chunk text, the vector and any derived summaries.
- Purge caches: semantic caches, retrieval caches and conversation memory that captured retrieved chunks.
- Handle backups and snapshots according to your documented backup policy, and record that you did.
- If you fine-tuned a model on the same data, note that deleting vectors does not remove anything memorised by the model. That is a separate problem, covered in can LLMs leak their training data.
Residency Applies to Vectors and the Embedding Call
Two data flows are easy to miss in a residency review. The first is the embedding API call itself: sending text to a hosted embedding model transfers that text to the provider's region. The second is the vector store: a managed vector database may replicate across regions by default. Both need to sit inside the boundary you promised customers. The broader residency picture for agents is in data residency for AI agents.
Controls That Reduce Exposure
Ordered from cheapest to most involved:
- Redact before embedding. Run PII detection on chunks and replace names, emails, account numbers and similar entities with typed placeholders before they reach the embedding model. Retrieval quality rarely depends on the literal identifier. See PII detection and redaction in AI pipelines.
- Do not store raw chunk text you do not need. If retrieval only needs a pointer back to the source system, store the pointer and fetch text under the caller's permissions at query time.
- Restrict vector exports. Bulk read access to the vector collection is equivalent to bulk read access to the text. Limit it to the retrieval service.
- Separate collections by sensitivity. Keep embeddings of special-category data (health, biometrics) in their own collection with tighter access and retention.
- Encrypt at rest and in transit, and treat vector store credentials as production database credentials.
- Record the embedding model and version per collection, so you know which inversion models would apply if a dump leaks.
Research also explores adding noise to embeddings to resist inversion. It trades away retrieval quality and should not be your primary control; minimisation and access control come first.
Vector Store Privacy Checklist
How Praesidia Fits
Praesidia's guardrails evaluate content in both directions of a governed request with block, redact, or warn dispositions, so PII patterns can be removed from text before it leaves for a model and from responses on the way back. When retrieval happens as an MCP tool call through Praesidia, the call is recorded with the agent, task and arguments, subject to redaction, which helps reconstruct which runs touched which collections.
Praesidia does not manage or erase data inside your vector store; erasure of vectors remains the store's and your pipeline's responsibility. For Praesidia's own records, its GDPR erasure workflow destroys a subject's encryption key and removes plaintext personal data after two authorised operators confirm, as described in the erasure post linked above.