Access and deletion requests against LLM logs and vector stores

An access or deletion request against an LLM feature is an ordinary GDPR request with an unusual number of places to look. Most of those places are easy if you planned for them and painful if you did not. One of them, the model's weights, is hard either way.

This article assumes you already run a request workflow (intake, identity verification, deadlines, response). If not, start with handling data subject requests and the DSR automation guide. Here we cover the LLM-specific stores, in rough order of difficulty, and close with what a defensible response says. It is general information, not legal advice.

The clock and the scope do not change

Under Article 12(3) of the GDPR you have one month to respond, extendable by two further months where requests are complex or numerous, as long as you tell the person within the first month. An LLM feature does not buy extra time. Nor does it narrow scope: the right of access in Article 15 covers all personal data you hold about the person, including the chat transcripts, the traces, the eval rows and anything inferred about them that you store.

What does change is the number of systems. A typical LLM feature adds several new stores to the data map (see the inventory table in the AI privacy guide). If those stores are not in the map with a lookup method, the first DSAR becomes an engineering project.

Step one: find the person

The single design decision that makes LLM requests tractable is tagging every stored record with a stable identifier: user ID, customer ID, tenant ID. With that, most lookups are queries. Without it, you are full-text searching prompts for an email address and hoping the person always typed it the same way.

Plan for two classes of data:

• Data about the requester as a user. Conversations they had, traces of their sessions, feedback they gave. Findable by user ID.
• Data about the requester as a subject. Mentions of them in other people's conversations, in indexed documents, in tickets about them written by staff. Findable only by searching content for their identifiers (name, email, phone, account number). This is the same problem as searching email or file shares, and the same reasonableness standard applies: search the systems where you would expect to find them, with the identifiers you have, and document what you did.

For the second class, a search across trace content and the RAG source corpus by email, phone and name is usually proportionate. Searching every vector by semantic similarity to the person's name is not a reliable lookup method and is not what a regulator would expect; search the source text and metadata instead, then map hits to the vectors derived from them.

Chat history, traces and logs

Access. Export the person's conversations with timestamps. From traces, include the content fields (prompts, completions, retrieved snippets, tool outputs that relate to them) in a readable form. You do not have to hand over raw span JSON, but the content has to be there. Redact other people's personal data that appears in the same records, as you would for any access request.

Deletion. Delete by user ID from the conversation store and the tracing backend. Check:

• whether the tracing tool supports deletion by user or session ID through its API, or only by trace ID, in which case you query first and delete second;
• whether deletions are hard or soft, and when soft deletes are purged;
• whether traces were exported to a warehouse or data lake, which then needs its own deletion;
• general application and gateway logs, which usually cannot be selectively deleted and should therefore have short retention so that time does the deletion for you.

Short trace retention is the best deletion strategy. If content expires after fourteen days, most deletion requests are satisfied for traces before you have finished verifying identity, and you can say so in the response.

Vector stores and RAG indexes

A RAG index holds three things: source documents, chunk text, and embeddings derived from chunks. Deleting a person's data means removing all three for affected documents, or editing the source and re-indexing.

Delete by ID or metadata

If each chunk carries metadata linking it to its source document and, where relevant, to the customer or person it concerns, deletion is a filtered delete. Most vector databases support deleting points by ID and by metadata filter; Postgres with pgvector is a plain DELETE ... WHERE. Design the schema for this from the start: source_doc_id, tenant_id, subject_ids[] where you can derive them.

Edit, re-chunk, re-embed

Often the request does not cover a whole document, only a person mentioned in it: a support ticket that names a third party, a contract with a signatory. Then the source document is edited (or redacted), its old chunks deleted, and the edited version re-chunked and re-embedded. This is the same pipeline you use when a document changes; if you have no update path, only append, you need one before the first such request.

Physical removal

Approximate nearest-neighbour indexes often mark deleted vectors and remove them later during compaction, optimization or vacuum. Postgres removes dead tuples, including from HNSW and IVFFlat indexes, on VACUUM. Find out how your engine handles it, and whether snapshots or replicas hold copies. For the response, "deleted from the live index; physically purged at the next compaction, within N days" is an honest and acceptable statement if N is short and known.

Provider-hosted vector stores and files

If you use a model provider's hosted file or vector store, deletion goes through its API. These objects persist until you delete them. As of October 2026, OpenAI's documentation says vector stores and Assistants objects are retained until deleted and that Assistants-related objects are removed 30 days after deletion (OpenAI, Your data). Anthropic's Files API keeps files until explicitly deleted or until a configured expiration (Anthropic, API and data retention). Keep a mapping from your document IDs to the provider's file IDs so you can find them.

Eval sets, caches and agent memory

Eval datasets are the store most likely to be forgotten. Rows copied from production into an eval tool, a spreadsheet or a test fixture in git rarely carry a user ID. Two fixes: require an origin field (trace ID or user ID) on every row imported from production, and run a scheduled scan for identifiers. For git, deleting a file does not remove it from history; rewriting history across forks and clones is disruptive, which is why production data should not go into repositories in the first place.

Caches. Semantic and exact-match response caches key on prompt content and store completions. Give them short TTLs and either key them per user (so deletion by user is possible) or confirm they hold nothing user-specific. Provider-side prompt caches are short-lived and governed by provider terms.

Agent memory. Long-term memory features store facts about users across sessions, which makes them a profile. They are in scope for access (the person is entitled to see what the system "remembers") and deletion, and should be keyed by user ID.

Fine-tuned models: the hard case

If production data containing the person's information was used to fine-tune a model, deleting the training file is easy. Removing the person's influence from the weights is not. There is no reliable, verifiable way to make a trained neural network forget specific training examples short of retraining without them. Machine unlearning techniques exist as research, but none offers a guarantee you could put in a response letter.

The regulatory position is still developing:

• Is the model personal data at all? The EDPB's Opinion 28/2024 (adopted December 2024) says AI models trained on personal data cannot in all cases be considered anonymous. For a model to be anonymous, both the likelihood of extracting personal data about training subjects from the model and the likelihood of obtaining it through queries should be insignificant. That is a case-by-case assessment the controller has to document. The Hamburg data protection authority took a different line in its July 2024 discussion paper, arguing that LLMs do not store personal data and that rights should be exercised against the inputs and outputs of the AI system instead. The EDPB opinion came later and is the board-level view.
• What can regulators order? The same opinion says that where training data was processed unlawfully, supervisory authorities may order erasure of part of the dataset or, where that is not possible and depending on proportionality, erasure of the whole dataset or the model itself, taking into account remedies such as retraining.
• What mitigations does the EDPB point to? Among measures that can support a legitimate-interest balance, it lists allowing erasure even where the Article 17(1) grounds do not strictly apply, letting people submit claims of regurgitation or memorization so the controller can reproduce and assess them, and output filters that prevent the generation of personal data.

For most companies, the practical answers are:

1. Do not fine-tune on raw personal data unless you need to. Scrub training files with the detection layers described in the prompts and traces article. A model trained on de-identified data makes the weights question largely moot.
2. Keep a lineage record. For each fine-tuned model, record which training files went in and where their rows came from. When a deletion request arrives you can say whether the person's data was used.
3. Delete the training data and suppress outputs. Remove the person's rows from training files, and add output filtering for their identifiers if there is a realistic risk of regurgitation.
4. Retrain on a schedule. If you retrain periodically anyway, commit to excluding deleted data from the next run and say so in the response.

Provider-side copies

Your model provider may hold prompts and completions in abuse-monitoring logs, stored responses, files or batch jobs. As a processor under your DPA, it should help you meet requests (Article 28(3)(e) requires processors to assist with data subject rights). In practice:

• Stored objects you created (files, vector stores, stored responses, threads) are yours to delete through the API.
• Abuse-monitoring logs are usually not selectively deletable by customers. They expire on the provider's schedule. As of October 2026, Anthropic's commercial retention article states inputs and outputs are deleted within 30 days for API users, with up to two years for content its automated systems flag as violating its Usage Policy (Anthropic Privacy Center); OpenAI states abuse-monitoring logs are kept for up to 30 days unless longer retention is legally required (OpenAI, Your data). Cite the provider's stated period in your response.
• If you have zero data retention, say so; there is nothing at the provider to delete for eligible endpoints.
• Litigation holds and legal obligations can override provider retention. Provider terms typically reserve longer retention where required by law; OpenAI's and Anthropic's documentation both say so.

Details per provider are in the vendor comparison.

Backups

Backups of the conversation database, trace store and vector database will hold deleted data until they rotate out. Regulators generally accept this if the data is put beyond use. The UK ICO's right to erasure guidance describes the test as putting backup data "beyond use" even if it cannot be immediately overwritten, and expects you to tell the person what will happen to backup copies. Two practical rules: never restore a backup without re-applying deletions logged since it was taken, and keep backup retention short enough that you can state it in the response.

Rectification and objection

Chatbots raise a request type that classic systems rarely see: "your assistant said something false about me." Article 16 gives a right to rectification of inaccurate personal data. If the inaccurate statement is in stored output (a summary saved to a CRM, a generated profile), correct or delete it like any other record. If it is generated fresh each time from model knowledge, you can filter outputs about that person, fix the retrieval sources that feed the error, or both. Objections under Article 21 to processing based on legitimate interest, for example to having conversations used for evaluation or fine-tuning, should be honoured by flagging the user and excluding their data from those pipelines going forward.

What a reasonable response looks like

A good response to a deletion request touching an LLM feature says, plainly:

1. which stores were searched and with which identifiers;
2. what was deleted, and when: conversations, traces, eval rows, indexed documents and their embeddings, agent memory, provider-hosted files;
3. what remains temporarily and why: backups until rotation on a stated schedule, provider abuse logs until their stated expiry, vector index entries until compaction;
4. for fine-tuned models: whether the person's data was used, that it has been removed from training data, what output safeguards apply, and when the next retraining will exclude it;
5. what was not deleted under an exemption (legal claims, legal obligation) and the basis;
6. how to complain to the supervisory authority.

For access requests, the same list in reverse: what you hold, where, for what purpose, from what source, with which recipients (name the model provider and observability vendor), for how long, and whether automated decision-making is involved.

The theme across every store is the same. Tag records with an identifier, set retention short, and keep personal data out of the places where deletion is hardest. Done up front, an LLM feature adds rows to a request runbook. Done later, it adds weeks.