CanAI

AI Embeddings and Personal Data: When Vector Representations Fall Under Data Protection Laws

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.


What are AI Embeddings?

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.


Why Organizations use Embeddings Instead of Traditional Search?

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:

  • Semantic search across contracts, policies or support tickets, retrieving relevant content without exact keyword matches.
  • Recommendation engines in retail and streaming, matching customer behaviour against a product or content catalogue.
  • Customer support chatbots and RAG systems that embed a company's knowledge base so an assistant can answer with context.
  • HR and recruitment tools that convert resumes into vectors to match candidates against job descriptions.
  • Biometric systems facial or voice recognition that convert a person's physical characteristics into a "faceprint" or "voiceprint" for matching.
  • Fraud detection models that embed transaction histories or behavioural patterns to flag anomalies.

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.


DOES TURNING DATA INTO AN EMBEDDING MAKE IT ANONYMOUS?

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.

CanAI

WHEN CAN AN EMBEDDING STILL BE PERSONAL DATA?

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:

  • It can be linked to an identifiable individual: Vector databases rarely contain embeddings in complete isolation. An embedding may be stored alongside a customer ID, account number, email address, document ID, timestamp or other metadata. Where these identifiers can be used to connect the embedding to an individual, the embedding cannot be assessed independently of that surrounding information.
  • It was created from personal data that the organisation continues to hold: Consider a customer support system that converts a customer's conversations into embeddings to enable semantic search. If the original conversations remain accessible and can be connected to the corresponding embeddings, converting the conversations into vectors does not, by itself, make the resulting embeddings anonymous.
  • It represents information about a particular person: An embedding created from a generic product description raises a different question from one created from an employee's performance review, a customer's support history or a person's facial image. The distinction is particularly significant in biometric systems, where specific technical processing of facial images to extract features or create templates for identification or matching can constitute the processing of biometric data.
  • It can reasonably be used to identify or single out an individual: An organisation does not necessarily need to reconstruct the original text or image for an embedding to be relevant to an identifiability assessment. If the embedding can be used, together with information reasonably available to the organisation, to associate information with a particular person, that capability may be relevant. The assessment is therefore not simply whether an embedding can theoretically be “reversed”, but whether identification is reasonably possible in the circumstances.
  • It is used to create or maintain a profile about an individual: For example, a recommendation system may generate embeddings representing a user's interests, preferences or behaviour. Even if the vector itself does not contain a person's name, it may still be linked to their account and used to make predictions or recommendations about them.


WHY THE WAY AN EMBEDDING IS STORED AND USED MATTERS

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.


WHAT HAPPENS TO EMBEDDINGS WHEN THE ORIGINAL DATA IS DELETED?

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.

CanAI

WHAT DO DATA PROTECTION LAWS REQUIRE?

Where an embedding is, or may be, personal data, full GDPR obligations apply to it just as they would to the source data:

  • Lawful basis: A valid legal basis is needed before generating embeddings from personal data, not just before collecting the original data. The EDPB's Opinion 28/2024 confirms legitimate interest can support AI development and deployment, but only after a documented three-step balancing test.
  • Data minimisation and purpose limitation: Embedding entire datasets for potential future use can conflict with data minimisation and purpose limitation where the data is not necessary for the stated purpose.
  • Special category data: Biometric embeddings used to uniquely identify an individual, as well as embeddings derived from health records, may constitute special categories of personal data under Article 9 GDPR. Their processing therefore requires not only a valid legal basis under Article 6, but also a separate applicable exception. This distinction was central to several regulatory decisions concerning Clearview AI, where the processing of biometric data for identification purposes was assessed under both provisions.
  • Data subject rights: Access, rectification, erasure and objection rights extend to embeddings that remain personal data, so organisations need to be able to locate and act on vectors, not just source records.
  • Security: Given how easily embeddings can be inverted, encryption, access controls and monitoring around vector databases need to match the sensitivity of the original data.
  • Transparency: Privacy notices should disclose that personal data may be converted into embeddings for AI processing, including any sharing with third-party AI vendors.


HOW SHOULD ORGANISATIONS ASSESS WHETHER AN EMBEDDING IS PERSONAL 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

  • What data was used to generate the embedding, and did it include personal data?
  • What data was used to generate the embedding, and did it include personal data?
  • What is the embedding used for, and who can access or receive it?
  • Does the embedding, alone or in combination with other information, present a risk of revealing or reconstructing information about an individual?
  • How is the embedding retained and managed when the underlying personal data is deleted or amended?
  • Have the relevant legal, transparency, security, and risk considerations been addressed in relation to the embedding?

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.


CONCLUSION

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