
Every time an employee uploads a resume to an AI hiring tool, feeds a customer transcript into a support chatbot, or connects a company knowledge base to a Retrieval-Augmented Generation (RAG) system. That data gets converted into a string of decimals called an embedding. The string of decimals may look meaningless, since it includes no personal identifiers such as name, email or biometrics. Many organisations treat this conversion as anonymisation, assuming that once personal data becomes a vector, data protection law no longer applies.
That assumption is misplaced and increasingly expensive to get wrong. Regulators, courts and security researchers have converged on the same conclusion: a vector is not automatically anonymous. Embeddings can, and often do, remain personal data under the GDPR, so obligations around lawful basis, data subject rights, retention and security don't disappear just because the data has been mathematically transformed. This article explains what embeddings are, why organisations use them, and when they continue to fall within data protection law.
An embedding is a numerical representation of data text, images, audio, or other inputs generated by a machine learning model. The model converts an input into a vector, which is an ordered list of numbers that represents certain characteristics or meaning of the original information. These vectors can then be compared to determine how similar different pieces of information are.
Embeddings allow systems to search for information based on similarity. Two inputs that mean similar things are able to produce vectors that sit close together in this space without having to share a word or pixel. This lets a chatbot "understand" that a "refund" query and a "getting my money back" query mean the same thing. The same principle allows a facial recognition system to compare a new photo against a database of stored facial representations to identify a potential match.
Embeddings are typically stored in vector databases, which are designed to efficiently store and retrieve these numerical representations. They are now used across a wide range of AI applications, including search, recommendations, and enterprise RAG deployments.
For example, a shopping platform can use embeddings to identify products that are similar to what a customer has viewed or searched for, even when the products do not share the same keywords.
Traditional search can find information based on exact words, tags, or predefined categories. Embeddings take a different approach: they allow systems to compare information based on its meaning or underlying characteristics, even when the wording is different.
For example, a keyword search for “refund” may look for documents containing that exact word. An embedding-based search can recognise that “I want my money back” is closely related, even though the word “refund” does not appear.
This makes embeddings particularly useful for applications where the meaning of information matters more than an exact word match. Organisations use them for semantic search, recommendations, document retrieval, RAG systems, and other AI applications where large volumes of information need to be compared efficiently.
This distinction is important for privacy because the fact that embeddings are useful precisely because they capture characteristics or meaning from the underlying data also raises the question of what happens to the personal information represented by those embeddings.
Common commercial uses include:
The appeal lies in the fact that embeddings allow systems to compare information based on meaning or other underlying characteristics, rather than relying solely on exact words or predefined labels. The privacy risk, however, is that this transformation does not necessarily strip the data of its personal character.
Article 4(1) GDPR, defines personal data as information relating to an identified or identifiable natural person. Recital 26 says data is only outside the law's scope once the data subject is no longer identifiable "by all the means reasonably likely to be used," considering cost, time and available technology.
Embedding text or an image does not meet this bar by default. The vector is mathematically derived from the original input, and that derivation is frequently reversible.
This is the core misconception organisations need to correct: embeddings behave more like pseudonymisation than anonymisation. Pseudonymised data identifiers replaced by codes that can still be linked back to a person remains personal data under the GDPR. An embedding similarly replaces a name or face with numbers, but the mathematical relationship between the two often stays intact and exploitable.
Researchers have demonstrated this repeatedly. The landmark Vec2Text study by Morris et al . demonstrated that text embeddings could be inverted to recover 92% of 32-token inputs exactly, under the study's experimental conditions. In a 2025 study, Cyborg reported achieving 99.38% content reconstruction from stolen embeddings in a production-like vector database in under five minutes. Where embeddings remain linked to the underlying information or to identifiable individuals, their transformation into vectors should not be treated as making that information anonymous.

Whether it remains personal data depends on the information surrounding the embedding, how it is used, and whether an individual can reasonably be identified from it.
An embedding is more likely to remain personal data where:
Whether an embedding constitutes personal data can depend on who holds it, what other information they have access to, and what means are reasonably available to identify the individual.
The CJEU's 2025 decision in EDPS v SRB (C-413/23 P) illustrates this distinction. The case concerned pseudonymised comments transferred by the Single Resolution Board to Deloitte.
The Court confirmed that whether individuals are identifiable depends on the circumstances of the processing and the means reasonably available to the recipient. But pseudonymisation does not automatically remove data from the GDPR's scope. Nor does the recipient's inability to identify individuals retrospectively displace the controller's obligations: for the SRB's information obligation, identifiability was assessed at the time of collection and from the controller's perspective, before the transfer to Deloitte.
Applied to embeddings, this means the same vector may raise different questions at different points in the data flow. An organisation that creates an embedding and retains the underlying customer record may be able to link the vector to an individual. A third party that receives only the vector, with no access to identifiers or other information that could reasonably enable identification, may be in a different position.
The important point is therefore not simply who has the vector, but what that party can reasonably do with it using the information and means available to them. Organisations should assess the embedding together with its identifiers, source data, access arrangements and intended use rather than treating the vector as either inherently personal or inherently anonymous.
Organizations discover a compliance gap at this juncture. When a data subject exercises the right to erasure under Article 17. An organisation may delete a source record from its CRM or document store while retaining the corresponding embedding in a vector database, search index, cache, or backup. If the embedding remains reversible or linked to retrievable metadata, the personal data continues to exist despite deletion of the source record.
This creates a structural risk in RAG architectures, where embeddings are often generated once and retained separately from the retention lifecycle of the underlying data. For example, a bank may delete a customer's closed support tickets while retaining their embeddings in the vector database powering its RAG chatbot, leaving the information retrievable through similarity search.
The same lifecycle gap extends to rectification, data portability, and the storage limitation principle under Article 5(1)(e), requiring organisations to account for personal data throughout its lifecycle, including its vectorised form.

Where an embedding is, or may be, personal data, full GDPR obligations apply to it just as they would to the source data:
A defensible assessment should sit inside a Data Protection Impact Assessment (DPIA) for any AI or RAG deployment, and work through the following checklist.
Quick Compliance Checklist
This assessment is important because an embedding that appears meaningless in isolation may still form part of a larger dataset that identifies, profiles or distinguishes an individual. The relevant question is “Can this vector reasonably be linked to a person in the context in which we hold and use it?”
Where the answers point to a real possibility of re-identification, the embedding should be treated as personal data throughout logged in the Record of Processing Activities, subject to the same rights procedures, and protected with equivalent security controls.
Commercial pressure to adopt AI quickly has led many organisations to treat embeddings as a compliance shortcut a way to use personal data for AI products without carrying forward the obligations attached to it. Regulatory guidance and case law point firmly the other way. The CJEU held, in Breyer and EDPS v SRB, that identifiability must be assessed in context, having regard to the means reasonably likely to be used for identification and the information available to the relevant party.
For businesses using embeddings, vector databases and RAG architectures, privacy assessment must extend to the vector itself. Identifiability, retention, security and data-subject rights must be addressed at the embedding layer, and anonymisation must be demonstrated, not assumed.
We at Data Secure (Data Privacy Automation Solution) DATA SECURE - Data Privacy Automation Solution Solution can help you to understand Privacy and Trust while lawfully processing the personal data and provide Privacy Training and Awareness sessions in order to increase the privacy quotient of the organisation.
We can design and implement RoPA, DPIA and PIA assessments for meeting compliance and mitigating risks as per the requirement of legal and regulatory frameworks on privacy regulations across the globe especially conforming to GDPR, UK DPA 2018, CCPA, India Digital Personal Data Protection Act 2023. For more details, kindly visit DPO India – Your outsourced DPO Partner in 2025 (dpo-india.com).
For any demo/presentation of solutions on Data Privacy and Privacy Management as per EU GDPR, CCPA, CPRA or India DPDP Act 2023 and Secure Email transmission, kindly write to us at info@datasecure.ind.in or dpo@dpo-india.com.
For downloading the various Global Privacy Laws kindly visit the Resources page of DPO India - Your Outsourced DPO Partner in 2025
We serve as a comprehensive resource on the Digital Personal Data Protection Act, 2023 (Digital Personal Data Protection Act 2023 & Draft DPDP Rules 2025), India's landmark legislation on digital personal data protection. It provides access to the full text of the Act, the Draft DPDP Rules 2025, and detailed breakdowns of each chapter, covering topics such as data fiduciary obligations, rights of data principals, and the establishment of the Data Protection Board of India. For more details, kindly visit DPDP Act 2023 – Digital Personal Data Protection Act 2023 & Draft DPDP Rules 2025
We provide in-depth solutions and content on AI Risk Assessment and compliance, privacy regulations, and emerging industry trends. Our goal is to establish a credible platform that keeps businesses and professionals informed while also paving the way for future services in AI and privacy assessments. To Know More, Kindly Visit – AI Nexus Your Trusted Partner in AI Risk Assessment and Privacy Compliance|AI-Nexus