GDPR + AI Act Overlap: Handling Data Subject Rights in AI Systems

The convergence of GDPR and the EU AI Act creates a complex operational landscape for AI deployers. When a data subject exercises rights under Articles 15-22 GDPR in relation to an AI system, DPOs must navigate explainability requirements, human review obligations, and the technical challenges of model retraining. This guide provides a concrete framework for compliance, focusing on the operational intersection of these two critical regulations.

GDPR Article 22 and AI Act Article 86: The Dual Right to Human Review Explained

GDPR Article 22 establishes the right not to be subject to solely automated decision-making producing legal or similarly significant effects. The AI Act reinforces this principle in Article 86, extending it to all high-risk AI systems regardless of whether they produce legal effects. This creates a dual-layered protection mechanism that DPOs must operationalise.

Key distinctions in scope

• GDPR Article 22: Applies to decisions based "solely on automated processing" with legal or similarly significant effects. The threshold for "significant effect" remains open to interpretation, though WP29 guidelines suggest factors like personalisation of services, profiling, or evaluation of personal aspects.
• AI Act Article 86: Applies to all high-risk AI systems as defined in Article 6, regardless of whether the decision produces legal effects. This includes systems used in critical infrastructure, employment, essential services, law enforcement, and migration control.

Human review requirements

Both regulations require "meaningful human review" but differ in specificity:

• GDPR: Requires review by someone with "authority and competence to change the decision" (WP29 Guidelines on Automated individual decision-making).
• AI Act Article 86(2): Mandates that human reviewers possess "sufficient competence, training and authority" and have access to "all necessary information" to properly assess the AI system's output.

Operational implications

1. 1Process design: Human review must be integrated into the decision pipeline, not added as an afterthought. The AI Act requires this to be documented in the technical documentation (Annex IV, point 2(f)).
2. 2Information access: Reviewers need access to: - The AI system's output - Relevant input data - Explanation of how the output was reached (see AI Act Article 13) - Confidence scores or uncertainty metrics
3. 3Escalation paths: Clear procedures must exist for cases where the reviewer disagrees with the AI system's output.

Workflow: Data Subject Request to AI Explainability Response

The following sequence outlines the operational flow for handling a data subject request under GDPR Articles 15-22 when the processing involves an AI system:

sequenceDiagram
    participant DS as Data Subject
    participant DPO as DPO/Controller
    participant AI as AI System
    participant HR as Human Reviewer
    participant Eng as Engineering Team
    participant Prov as AI Provider

    DS->>DPO: Rights request (Art. 15-22)
    DPO->>AI: Identify relevant processing
    AI-->>DPO: Processing metadata
    DPO->>Prov: Request explainability artifacts
    Prov-->>DPO: Model documentation (AI Act Art. 11)
    DPO->>Eng: Request input data + model output
    Eng-->>DPO: Data + output + confidence scores
    DPO->>HR: Trigger human review (Art. 22/AI Act Art. 86)
    HR->>DPO: Review outcome + explanation
    DPO->>DS: Response (Art. 12 GDPR)
    alt Erasure/Rectification
        DPO->>Eng: Assess retraining needs
        Eng-->>DPO: Impact assessment
        DPO->>Prov: Coordinate model update
    end

Critical path analysis

1. 1Request intake (Day 0): The DPO must first determine whether the request relates to an AI system. This requires maintaining an inventory of AI systems and their data processing activities (GDPR Article 30, AI Act Article 11).
2. 2Explainability artifacts (Days 1-3): The AI provider must supply: - Technical documentation (AI Act Annex IV) - Explanation of the system's logic (GDPR Article 13(2)(f)) - Any available local or global explainability methods
3. 3Human review (Days 3-7): The reviewer must have access to: - The specific input data used for the data subject - The model's output - Explanation of how the output was derived - Any relevant business rules applied post-output
4. 4Response (Day 7-30): The DPO must provide: - Meaningful information about the logic involved (GDPR Article 15(1)(h)) - The significance and envisaged consequences (GDPR Article 13(2)(f)) - Information about the right to human review (AI Act Article 86(3))

Right to Erasure (Article 17) Impact on Trained Models: Unlearning is Hard

When a data subject exercises the right to erasure under GDPR Article 17, AI deployers face significant technical challenges. The core issue: most AI models cannot "unlearn" specific data points without complete retraining.

Technical limitations of machine unlearning

1. 1Model architecture constraints: - Deep neural networks encode information in distributed weights, making targeted removal impossible without affecting other learned patterns. - Traditional statistical models (e.g., linear regression) may allow partial unlearning, but this is rarely feasible for modern AI systems.
2. 2Data persistence: - Training data may be replicated in multiple locations (training sets, validation sets, test sets). - Feature engineering often creates derived data that persists even if raw data is removed.
3. 3Model versioning: - Multiple versions of a model may exist in production, staging, and development environments. - Shadow models or A/B testing variants may contain the same data.

Legal obligations vs. technical reality

GDPR Article 17(1) requires erasure "without undue delay," but Recital 65 acknowledges that controllers may have "overriding legitimate grounds" for retaining data. For AI systems, these grounds typically include:

1. 1Statistical purposes: If the data is necessary for statistical analysis and appropriate safeguards are in place (Article 89).
2. 2Public interest: For archiving purposes in the public interest (Article 89).
3. 3Technical impossibility: Where erasure would require disproportionate effort (WP29 Guidelines on the right to erasure).

However, the AI Act introduces additional considerations:

• High-risk systems: Article 10 requires training data to be "relevant, representative, free of errors and complete." If erasure affects these qualities, the model may become non-compliant.
• Data governance: Article 10(5) requires mechanisms to ensure data quality, which may conflict with erasure requests.

Practical approaches

1. 1Differential privacy: Implement during training to limit the influence of individual data points.
2. 2Federated learning: Train models on decentralised data to avoid centralised storage.
3. 3Model versioning: Maintain clear lineage of which models were trained on which data.
4. 4Impact assessment: Document the technical and legal analysis for each erasure request.

Decision Matrix: When Retraining is Required vs Not

The following matrix helps DPOs determine when model retraining is necessary in response to data subject rights requests:

Key considerations for the matrix

1. 1Data role: Distinguish between data used for training and data used for inference. Only training data removal typically requires retraining.
2. 2System risk level: High-risk systems (AI Act Article 6) have stricter requirements for data quality and model performance.
3. 3Performance impact: Assess whether data removal would degrade model performance below acceptable thresholds.
4. 4Regulatory requirements: Some sectors may have additional requirements (e.g., financial services under DORA).

Documentation Checklist for DPO + AI Provider Collaboration

Effective handling of data subject rights in AI systems requires close collaboration between DPOs and AI providers. The following checklist ensures comprehensive documentation:

Pre-deployment documentation

1. 1AI system inventory: - Classification of each system (