Data Subject Access Requests Involving AI-Generated Records

Data Subject Access Requests Involving AI-Generated Records

A question that keeps coming up in privacy operations meetings: when a data subject submits a DSAR under GDPR, and the responsive records include AI-generated content, prompt logs, or model outputs that reference the individual, what exactly do you owe them?

The short answer is more than you might think, and the mechanics are messier than a standard DSAR response. The longer answer requires working through several layers of GDPR obligations that were drafted before enterprise AI adoption looked anything like it does today.

What Counts as Personal Data in AI Systems

Article 4(1) of the GDPR defines personal data as "any information relating to an identified or identifiable natural person." That definition is broad by design, and it does not carve out machine-generated content. If your AI system produces a risk score, a summary, a recommendation, or a classification that relates to an identifiable individual, that output is personal data. Full stop.

The Article 29 Working Party (now the EDPB) clarified this in their Opinion 4/2007 on the concept of personal data, establishing that data "relates to" an individual when it concerns their identity, characteristics, or behavior, or when it is used to evaluate, treat, or influence them. An AI-generated credit assessment, a flagged fraud alert, a summarized patient intake note: all of these relate to the data subject and fall within scope.

Prompt logs add another wrinkle. If an employee at your organization typed a natural language prompt that included a customer's name, account number, medical history, or any other identifier, that prompt is a record containing personal data. The fact that it was an input to an AI system rather than a traditional database query changes nothing about its status under the regulation.

Inferred and Derived Data

The EDPB's Guidelines 8/2020 on the targeting of social media users drew a useful distinction between "observed" data (directly provided or collected), "derived" data (created by the controller from observed data through straightforward operations), and "inferred" data (produced through probabilistic analysis). Both derived and inferred data qualify as personal data when they relate to an identifiable person. AI outputs almost always fall into one of these two categories.

The CJEU reinforced this in YS and Others v. Minister voor Immigratie (C-141/12, 2014), though that case dealt with legal analyses in immigration files rather than AI. The court held that while a data subject has a right to access their personal data contained in an administrative document, they do not necessarily have a right to the document itself. This distinction matters for AI-generated records: you need to disclose the personal data within the output, but you may have some flexibility in how you present it.

Scoping the Response: What Goes In

When you receive a DSAR and your organization uses AI systems that process personal data, your search obligations under Article 15 extend to those systems. Practically, this means you need to be able to locate and retrieve:

• AI-generated outputs that reference or relate to the data subject: summaries, scores, classifications, recommendations, flags, and similar artifacts.
• Prompt logs where the data subject's personal data appeared as input, whether typed by an employee or injected programmatically through retrieval-augmented generation or similar architectures.
• Training data containing the individual's personal data, if identifiable and retrievable. This is often technically infeasible for large models, which the ICO has acknowledged, but the obligation exists in principle.
• Metadata about automated processing: timestamps, model versions, confidence scores, and the categories of data used as inputs.

Article 15(1)(h), added by reference through Article 22(1), requires you to provide "meaningful information about the logic involved" when automated decision-making or profiling is in play. The threshold question is whether the AI system's output feeds into a decision that produces legal effects or similarly significant effects on the individual. If it does, you owe an explanation of the logic, significance, and envisaged consequences. The Dutch DPA fined Uber 10 million euros in December 2023 partly for failing to meet this transparency obligation around automated driver profiling.

Practical Challenges and How to Handle Them

Retrieval Architecture

Most organizations cannot currently search prompt logs by data subject. If you are running AI workloads through an API, your logs may be structured around session IDs, user IDs (of the employee, not the data subject), or timestamps. Retrofitting a search capability that maps data subject identifiers to prompt logs and model outputs is a real engineering effort. But the GDPR does not offer a "too hard" exemption. Article 11(2) provides some relief if you genuinely cannot identify the data subject within the processing, but if you are processing their name and account number in prompts, you clearly can identify them.

Third-Party Model Providers

If you are sending personal data to a third-party AI provider (OpenAI, Anthropic, Google, or others), your data processing agreement under Article 28 should already address assistance with DSARs. In practice, many standard DPAs from major providers commit to deleting data after a retention window but offer limited support for retrieving specific records tied to a data subject. You remain the controller. The obligation to respond sits with you, and "our vendor cannot search their logs" is not a valid basis for an incomplete response.

Exemptions and Redactions

Prompt logs may contain trade secrets, proprietary system prompts, or personal data of other individuals. Article 15(4) permits you to withhold information that would adversely affect the rights and freedoms of others. Recital 63 allows you to consider trade secrets. But these are narrow exemptions, not blanket carve-outs. You should redact third-party personal data and genuinely confidential system architecture details, then disclose the rest. Document your redaction rationale in case of a supervisory authority inquiry.

The One-Month Clock

Article 12(3) gives you one month to respond, extendable by two months for complex requests. DSARs involving AI-generated records are strong candidates for that extension, but you need to notify the data subject of the delay and the reasons within the initial one-month window. Given the retrieval challenges, building AI system searches into your standard DSAR workflow now, before you receive a request that forces the issue, is the pragmatic move.

Documentation and Article 30 Records

Your Records of Processing Activities under Article 30 should already reflect AI systems that process personal data. If they do not, a DSAR is going to expose that gap painfully. Each AI processing activity needs a recorded purpose, lawful basis, data categories, retention period, and recipient list. When a DSAR arrives, your Article 30 records are the map you use to identify which systems to search. Incomplete records mean incomplete responses, which mean regulatory risk.

How FirmAdapt Addresses This

FirmAdapt's architecture was built with this problem in mind. The platform maintains structured, searchable logs of all AI interactions, including prompts, inputs, outputs, and metadata, indexed in a way that supports retrieval by data subject identifier. When a DSAR comes in, compliance teams can query across AI-generated records alongside traditional data stores, producing a unified response package without requiring custom engineering work.

FirmAdapt also automates the Article 15(1)(h) transparency requirements by maintaining plain-language documentation of model logic, input categories, and decision significance for each AI processing activity. This means the "meaningful information about the logic involved" is already drafted and version-controlled before anyone submits a request, rather than assembled under time pressure after the fact.