Personal data in AI systems: deletion, anonymisation and access

Where personal data sits in an AI system

An AI system that answers from your own documents is made of several building blocks. The DSK, the joint body of Germany's data protection supervisory authorities, describes the typical set-up in its October 2025 guidance on RAG systems: documents are split into short text sections, called chunks. An embedding model turns each chunk into a vector of numbers, and both are stored together in a vector database. When a question comes in, the system looks up the matching sections and passes them to the language model.

For data protection, this means personal data does not sit in one place but in several.

Two places are often overlooked. First, logs: many systems write questions and answers to log files for troubleshooting and often keep them there longer than the chat history itself. Second, backups: a deleted document can still exist in backups weeks later. Both belong in your record of processing activities and in your deletion policy.

Model weights are a special case. As long as you only use a language model, do not train it further on your own data and no external provider uses your inputs for training, your documents do not end up in the model. If you fine-tune on personal data, however, you may write it into the model, where it can hardly be removed selectively. More on this in the article Train AI on your own data. What the DSK asks for overall is summarised in the guide to the DSK AI guidance.

In shortSeven possible places. Four can be deleted item by item; logs and backups need their own rules, and the model is only affected by fine-tuning.

What GDPR rights mean inside an AI system

The GDPR has no special rules for AI. The familiar rights and duties apply, and you need to be able to honour them in every store. In its RAG guidance, the DSK states that data subjects hold their rights under Articles 15 et seq. GDPR for inputs and outputs, the reference documents and the vector database, and that transparency, access, rectification and erasure can usually be implemented there (section 3.7). The full checklist is in the guide GDPR-compliant AI.

Your reply to the data subject is governed by Article 12(3) GDPR: without undue delay and at the latest within one month. For complex or numerous requests, the deadline can be extended by two further months; you must tell the person within the first month and give the reasons. So decide in advance how you will search every store for one person. A full-text search across documents, history and logs is usually the direct route; the vectors alone are less suitable because they capture meaning rather than exact names.

The language model is a different matter. The DSK calls the implementation of data subject rights in AI models, especially large language models, "largely unsolved". Regulators do not agree on how to classify the models themselves either. In a July 2024 discussion paper, which it called a prompt for debate and which preceded the EDPB opinion, the Hamburg data protection commissioner put forward the thesis that the language model itself does not store personal data, and that data subject rights apply at least to input and output. The paper concerns only the model, not the vector index or documents of a RAG system. In December 2024, the European Data Protection Board (EDPB) stated that AI models trained on personal data cannot, in all cases, be considered anonymous (Opinion 28/2024, para. 34).

In shortAccess, rectification and erasure can usually be handled for documents, index, history and logs, but hardly in the model itself.

Pseudonymous, anonymous, embedded: where the line is

Two terms are often confused. Pseudonymised data can no longer be attributed to a person without additional information, but can be with it (Article 4(5) GDPR). For you as the controller, who can re-link the data, it remains personal data. Information is only anonymous once the person can no longer be identified by the means reasonably likely to be used (Recital 26). Only then does the GDPR not apply.

At first sight, embeddings look anonymous: a sentence becomes a list of hundreds to thousands of numbers. Research shows, however, that the text can often be recovered from them. Morris and colleagues at Cornell University used their Vec2Text method to reconstruct 92% of 32-token text inputs exactly from their embeddings. From embedded clinical notes, they recovered 89% of full names. As early as 2020, Song and Raghunathan recovered 50 to 70% of the words from popular sentence embeddings.

These results were obtained under lab conditions: the attackers had access to the vectors and could query the embedding model as often as they liked. On top of that, many vector databases store the text chunk itself next to each vector, as the DSK also describes. Writing about AI models, the EDPB also stresses that information can relate to a person even when it is only encoded in a machine-readable form (Opinion 28/2024, para. 37); the same logic applies to embeddings.

In practice, this means treating the vector index with the same level of protection as the documents it was built from. It needs a legal basis (DSK, section 3.6), an access concept and a deletion policy. Data minimisation still pays off: according to the DSK, personal data is to be removed or anonymised during data preparation where it is not needed (section 3.1). Where it is needed, pseudonymisation lowers the risk; Article 32 GDPR names it explicitly as a security measure.

In shortEmbeddings are not anonymisation. Pseudonymising lowers the risk, but the data stays personal.

Erasure that reaches every store

An erasure request under Article 17 GDPR is only fully implemented once the data has been removed from every active store and a documented approach covers the backups. In a RAG system this is quite feasible: according to the DSK, entries in the vector database are "directly addressable, so personal data can be deleted selectively" (section 3.5). For this to work reliably, the erasure has to carry through, from the source document to the backup.

With connected sources, the sync is what matters: when a document is deleted in the source system, the next synchronisation has to remove it from the index as well. Check this with a test document before you go live, and record the result.

The GDPR does not regulate backups explicitly. In practice, individual records are rarely deleted from backups. A common approach is to overwrite backups on a fixed rotation, protect them against access and make sure that deleted data does not reappear after a restore, for example by re-applying deletions afterwards. Write this approach into your deletion policy. Statutory retention duties can stand in the way of erasure (Article 17(3)(b) GDPR); in that case, restrict processing to the retention purpose and take the data out of AI use.

Erasure in the model is much harder. The DSK writes that, despite the advantages of a RAG system, "the problems of deleting data in the language model remain" (section 3.5). In its June 2025 guidance on technical and organisational measures, it states that filters are to be used as an interim solution but do not "in themselves" amount to erasure (p. 23).

In shortErasure means source, index, history, logs and backups. Test the path once before you go live.

Access, retention and lean logging

Who may find which content through the AI is not decided in the language model. The DSK points out that the language model itself cannot control who may access what. In the RAG part, by contrast, proven measures apply, such as tenant separation and a rights and roles concept for areas of the vector database and the reference documents (section 3.3). In practice: separate content by purpose, for example HR documents in their own project with a small group of users and manuals in an open one.

Also check whether permissions are carried over from the source system. Not every system takes over the permissions of individual documents from drives, wikis and ticket systems. If it does not, only put content in a shared project that every member may see. The DSK asks you to check, for each new data source of a RAG system, whether everyone with access may also access the new data (guidance on technical and organisational measures, p. 24).

Storage limitation (Article 5(1)(e) GDPR) and privacy-friendly defaults (Article 25(2) GDPR) favour short retention. As an example for employee accounts, the DSK mentions not using inputs for training and not keeping an input history beyond the session (guidance on AI and data protection, May 2024, margin no. 43). Whether your use case also needs a data protection impact assessment is best settled early.

For logs, a simple rule helps. Logs are useful for security (Article 32 GDPR) and troubleshooting, but not necessarily with the wording of every question. Log metadata such as time, user, project and source, and store content only where there is a purpose for it, with its own short retention period.

In shortYou control access through projects and roles, not through the model. Short retention and lean logs belong in the defaults.

Personal data in RAGSuite

RAGSuite is a RAG engine: RAGSuite does not train a model on your data. Documents, text chunks and embeddings live in the search index, where you manage and delete them. The free Community Edition (Apache-2.0) offers automatic deletion with deletion receipts, two-factor sign-in, an audit log of the last 15 days and a basic query history. It runs on your own server, offline too, and sends no telemetry.

For organisations with several teams, Enterprise adds roles and project access, single sign-on, the full audit history with export, and retention policies with legal hold. Important for your access concept: RAGSuite does not take over the permissions of individual documents from source systems; you separate content through projects, and in Enterprise you control which teams can access which project. The page AI data protection shows the data protection features, and the guide RAG pipeline explains how data flows through the system.

In shortIn RAGSuite, your data lives in the index, history and logs, not in the model. Separation via projects; retention policies and legal hold in Enterprise.