Data subject rights handling for AI

What it does

It lets the organisation answer a rights request for its AI systems as it would for any other. The procedure lists where personal data can sit in each system, how to search each place for an individual, and what can be done there: disclose, correct, delete, suppress or exclude from future training. The data protection officer owns the procedure; each system owner is accountable for their system's part. It operates whenever a request is received and is tested in advance.

How to implement it

• Map, for each system, the stores that may hold personal data, including those at providers.
• Keep the link from embeddings and training records back to their source records.
• Build search by individual into logs and stores at design.
• Define the response for data inside a trained model: output suppression, exclusion at the next retraining, or retraining.
• Add AI systems to the standard rights procedure and train those who handle requests.
• Test with a dummy request and record how long it took and what could not be done.

Evidence it operates

Design: a rights procedure covering AI systems; a data map for each system. Operation: records of requests handled, with the stores searched and action taken; test results; suppression lists; evidence of data excluded at retraining.

Where it fits

Acts when a request arrives, and depends on design choices made much earlier. It is the primary control for unfulfillable data subject rights and supports inaccurate personal data in outputs by providing the route to correction. It relies on dataset documentation to know what is where.

Limits

Removing one person's influence from a trained model is not yet practical at scale, so the honest answer is sometimes partial and has to be explained to the person. Suppressing an output leaves the data in the model. Providers may give no means to search by individual. The procedure cannot rescue a system designed with no way of finding a person's data.