AI and GDPR Data Subject Rights: Making Them Work

Data subject rights are where GDPR meets AI architecture most directly. Access, erasure, and explanation all fail on the same thing: the system did not record what it would need to comply. This guide covers what each right demands, drawing on FISTA Solutions' AI enablement work. This article is general guidance, not legal advice.

Which rights bite hardest in AI systems?

All of them apply; three are materially harder than in conventional systems.

Right	What makes it hard in AI systems
Access	Personal data spread across logs, caches, vector stores
Erasure	Finding every copy, including provider-side retention
Rectification	Correcting data that has already influenced outputs
Objection	Stopping processing without breaking the system
Automated decisions	Explaining the basis and offering intervention
Portability	Assembling data from stores never designed for it

What is hard about the right to erasure?

Finding every copy. Personal data in AI systems spreads into prompt logs, response caches, vector stores, evaluation datasets, fine-tuning sets, and provider-side retention.

An erasure process that clears the primary database and leaves the vector store is incomplete, and the vector store is exactly where a subsequent retrieval will surface the data. Map every location at design time, because discovering them during a request is too late. See what is a retrieval index.

What do the automated decision-making rules require?

Where a decision based solely on automated processing produces legal or similarly significant effects, specific conditions apply, along with rights to obtain human intervention, express a point of view, and contest the decision.

The practical requirement is that the system recorded enough to explain the basis, and that a human reviewer has access to that basis and authority to change the outcome. A review process routed to staff who can only repeat the system's answer is not intervention. See what is the right to explanation.

How do you handle training data?

Ideally by minimising personal data in training sets in the first place, because erasure and access become technically difficult once data has shaped model weights.

Where personal data has been used, the position depends on the facts and is worth settling with counsel in advance rather than in response to a request. The engineering lesson is that decisions about training data are compliance decisions, and they are close to irreversible.

What evidence do you need?

Records of where personal data resides across the whole system including logs and vector stores, evidence that erasure reaches all of them, decision bases for automated decisions, records of human intervention where requested, and transparency information actually provided.

If that evidence exists as a by-product of how systems are built and operated, you are in good shape. If it exists only as documents written for a review, you are not, and the difference is visible to anyone who looks carefully.

How does this change engineering practice?

It pushes data mapping, retention design, and decision-basis logging to the front. All three are cheap at design time and close to impossible to retrofit.

The specific practice worth adopting is treating every store that can hold personal data — including a vector index and an evaluation set — as in scope for retention and erasure jobs from the day it is created, rather than adding it when someone remembers.

How does it interact with other regimes?

Usually more than expected. The same system can attract questions from a data protection authority, a sector supervisor, and a general AI regulator, each starting from a different premise and arriving at overlapping requirements.

One evidence base mapped to several requirements answers all of them. Separate programmes produce separate documents describing the same systems, and inconsistencies between them are themselves a finding.

What does compliance cost?

Mostly the cost of good engineering practice: evaluation, documentation, logging, and oversight design. Built into a project, the incremental cost is modest and much of it is work the system needed anyway.

Retrofitted onto a live system it becomes a project, performed under a deadline you did not choose, on something people already depend on. See AI compliance audit cost.

What are the common mistakes?

Treating prompts and vector stores as outside the personal data perimeter. Erasure that clears only the primary database. Logging outputs without the inputs needed to explain them. And review processes that cannot actually change an outcome.

Who owns this internally?

The function that owns the systems, with legal and compliance support. Ownership by compliance alone produces documents describing systems nobody changed; ownership by engineering alone produces good practice with no one accountable for the interpretation.

Name a person per system rather than a committee. Committees review; people decide.

What should you ask a supplier?

What documentation they provide about capabilities and limitations, what evaluation evidence they share, how they handle personal data, where processing happens, and what happens to your prompts and outputs.

Suppliers who have prepared answer those quickly. Suppliers who have not take weeks, and that delay is itself information about how the relationship will run.

How do you keep this current?

Assign someone to watch the sources that actually bind you rather than general commentary. Record what was checked and when, so the next review starts from a known point.

Rules in this area change, and a position taken eighteen months ago and never revisited is a risk in itself.

How do you test whether rights actually work?

By running a request end to end against a real record, deliberately, before a real one arrives.

Pick a test subject, submit an access and erasure request through your own process, and check every store afterwards. Organisations that do this find gaps every time, and finding them on a test is considerably cheaper than finding them on a complaint.

What should you do first?

List every store in your AI systems that can hold personal data, including caches, vector indexes, prompt logs, and evaluation datasets. That list is your rights-handling scope, and it is usually longer than the one your privacy documentation describes.

How FISTA Solutions helps

FISTA Solutions builds AI systems so the evidence exists when it is needed: every store that can hold personal data mapped and included in retention and erasure jobs, decision bases logged so explanation and intervention are possible, evaluation results dated and versioned, oversight designed structurally rather than asserted in policy, and documentation produced during the build rather than reconstructed afterwards. Delivery runs through AI enablement, AI agents, and forward deployed engineers. The record is 150+ projects for 50+ companies across 12+ countries.

To align a system with these requirements, message FISTA on WhatsApp, or read what is the right to explanation.