Data Subject Access Requests When You Use AI

A data subject access request lands by email and the clock starts the same day. If your business uses AI tools, the search you run is almost certainly incomplete, because the standard sweep covers your CRM, your inbox and your file store, and personal data has quietly been copied into four places none of those searches touch.

This is about finding those copies and answering inside the deadline.

What a data subject access request obliges you to produce

Under Article 15 of the GDPR, the person is entitled to confirmation of whether you are processing their personal data and, if you are, a copy of it, plus a defined list of information about the processing: the purposes, the categories of data, who you disclose it to, how long you keep it, where you got it if not from them, their rights to rectification and erasure, their right to complain to a supervisory authority, and whether any automated decision-making is involved along with meaningful information about its logic.

That last item is the one AI use makes live. If a model scores, ranks, filters or triages people, you may need to explain the logic and the consequences, not just hand over a data export.

The timing comes from Article 12: without undue delay and in any event within one month of receipt. You can extend by two further months where the request is complex or numerous, but only if you tell the person within the first month and explain why. Responding is free. You can charge or refuse only where a request is manifestly unfounded or excessive, and the burden of showing that falls on you, not on them.

The four places AI puts personal data that you will not search

Chat histories in consumer accounts

Every time someone on your team pasted a customer email into a chat assistant to draft a reply, a copy landed in that account's conversation history. It is personal data, you are the controller, and it sits in a tool your IT inventory probably does not list. Ask each team member to search their own history for the person's name, email and any order or account reference.

Vector stores and embeddings

If you built a retrieval feature over support tickets or documents, the source text usually persists alongside the vectors so it can be returned at query time. A customer's complaint is therefore stored twice, once in the helpdesk and once in the index. Deleting from the helpdesk does not touch the index, and a DSAR search run against the primary database will not see it.

Prompt and completion logs

Application logs capture full prompts for debugging. Prompts contain whatever you put in them. These logs tend to have the longest retention of anything in the stack, often sitting in a log service nobody has reviewed since launch.

The vendor's own retention

Your copy is not the only copy. As a worked example, OpenAI's data controls documentation states that API inputs and outputs are not used for training by default, but that prompts and responses are retained in abuse-monitoring logs for up to 30 days, and that zero data retention requires prior approval rather than being a setting you switch on. Some endpoints keep application state until you delete it. You need to know which arrangement you actually have before you describe your retention periods in writing.

A workflow that fits the month

Front-load the vendor enquiries. They are the step with a dependency on someone else, and a support ticket that takes eleven days to answer is what turns a comfortable month into an extension you have to justify.

What you can withhold, and what you cannot

You can redact other people's personal data. A support thread naming a second customer gets that name removed. You can withhold genuine trade secrets, though the model's general architecture is rarely one, and "the vendor will not tell us" is not a basis for withholding information about processing you are responsible for.

You cannot refuse because the data is inconvenient to retrieve, scattered across tools, or held by a processor rather than by you. If you chose the architecture, the retrieval cost is yours.

Being able to answer these requests at all depends on knowing what each tool retains before you adopt it. Vetting an AI vendor before you hand over data covers the questions to ask at procurement, and telling whether an AI vendor is GDPR compliant covers the paperwork that should exist. The access right's sibling, erasure, has its own implementation problem, worked through in adding GDPR data deletion to an AI-built app.

FAQ

How long do I have to respond to a data subject access request?

One month from receipt. You may extend by two further months for complex or numerous requests, provided you inform the person within the first month and explain the reason.

Do chat assistant conversations count as personal data I must disclose?

If they contain personal data about the requester and your business put it there, yes. The fact that it sits in a third-party tool rather than your own systems does not remove your responsibility for it.

Can I charge for a subject access request?

Normally no. A fee or a refusal is only available where the request is manifestly unfounded or excessive, for example because it is repetitive, and you have to be able to demonstrate that.

What if the AI vendor will not tell me what they retain?

Then you have a procurement problem as well as a DSAR problem. Document what you asked and when, give the requester the information you do hold, and treat the vendor's opacity as a reason to review the contract.

Does an embedding count as personal data?

Treat it as such where it derives from and can be linked back to an identifiable person, which is the usual case when the source text is stored next to it for retrieval.