Deploying artificial intelligence to automate regulated decisions, whether credit approvals, HR screening, medical triage or law-enforcement risk scoring, places a European organisation simultaneously under two distinct but overlapping legal regimes: the prohibition on solely automated individual decision-making in GDPR Article 22 and the human oversight obligations in EU AI Act Article 14. Understanding how these two frameworks interact, and designing sovereign on-premises infrastructure that satisfies both, is now a core compliance task for CISOs, DPOs and AI governance officers in every regulated sector.
Two Frameworks, One Decision: How Article 22 GDPR and Article 14 AI Act Relate
GDPR Article 22 and AI Act Article 14 address the same underlying concern from different legal angles, but neither supersedes the other and both apply simultaneously to any high-risk AI deployment that affects individual data subjects.
GDPR Article 22 grants data subjects a right not to be subject to a decision based solely on automated processing that produces a legal effect or a similarly significant effect on them. It is, at its core, a prohibition with narrow exceptions: explicit consent, contractual necessity, or a Union or Member State law that provides suitable safeguards. The word “solely” has been the central interpretive battleground.
The European Court of Justice resolved a critical ambiguity in ECJ C-634/21, OQ v Land Hessen (SCHUFA), handed down in December 2023. SCHUFA, the German credit-reference agency, produced probability scores that lenders then used as the decisive factor in credit decisions. The Court held that generating such a score already constitutes automated decision-making within Article 22, even if the formal yes/no decision is made by a human employee, because that employee exercises no genuine independent assessment. A nominal human step that functions as a rubber stamp does not break the chain of automation. This ruling has direct implications for any organisation whose AI output is “decisive in practice” even when a human is nominally involved.
EU AI Act Article 14, which applies to providers and deployers of high-risk AI systems listed in Annex III, imposes a forward-looking design obligation: systems must be built and operated so that natural persons can effectively oversee them, understand their outputs, intervene when necessary, and decline to use or override those outputs. This is not a data-subject right but a system-design and operational requirement enforced through market-surveillance authorities and, where personal data is involved, coordinated with data protection authorities.
What Counts as Meaningful Human Involvement
The SCHUFA ruling makes clear that the human reviewer must have the competence, authority, and information necessary to reach a genuinely independent conclusion. Mere access to an AI output, without the ability or the institutional mandate to override it, is insufficient under Article 22.
AI Act Article 14 operationalises this by requiring that deployers assign oversight to individuals who understand the system’s capabilities and limitations, are trained to interpret its outputs, and can detect anomalies, drift, and failure modes. For high-risk categories, Article 14(4) requires that the system be designed to enable effective oversight, meaning the technical interface must present the reviewer with enough information, including uncertainty indicators and feature attribution, to support a genuine decision.
Sector-specific requirements vary in practice:
| Use case | Article 22 threshold | Minimum Article 14 oversight standard |
|---|---|---|
| Automated credit scoring | Score determines or decisively shapes credit outcome (SCHUFA doctrine) | Trained credit officer reviews score, supporting factors and counterfactual; documented override authority |
| HR screening / CV ranking | Ranked output leads directly to rejection without human review of application | HR professional reviews top and bottom cohorts; bias monitoring log; appeal pathway |
| Medical diagnostic AI | Diagnostic output leads directly to treatment or denial of treatment | Clinician with relevant specialism reviews output against clinical notes; system presents confidence interval |
| Law-enforcement risk assessment | Risk score triggers detention, search or surveillance without independent review | Designated authorising officer with legal training reviews full evidential context; audit log stored separately |
Designing Audit Trails and Human-Review Workflows for Dual Compliance
A sovereign on-premises deployment must produce a single unified audit trail that simultaneously evidences Article 22 GDPR compliance and Article 14 AI Act compliance. Separate logs maintained in isolation create reconciliation gaps that will be exposed during a supervisory authority inspection.
Every automated output that could constitute a significant decision must generate an immutable record containing: the model version and configuration hash at inference time, the input features used (with personal data pseudonymised at rest), the output score or classification with a calibrated confidence value, the identity and role of the human reviewer assigned, the timestamp of the review, the reviewer’s documented conclusion (confirm, override, or escalate), and the reason code if the AI output was overridden. This record must be stored on infrastructure that the organisation controls entirely, with no replication to external cloud services.
The EDPB-EDPS Joint Opinion 5/2021 on the AI Act explicitly called for data protection authorities to be designated as competent authorities for the data-processing aspects of high-risk AI systems, and for the GDPR supervisory framework to be treated as the primary enforcement channel for data-subject rights in automated decisions. This means the DPA can and will request audit logs as part of an Article 22 complaint investigation, and those same logs must satisfy the technical-documentation requirements of the AI Act. Designing the log schema once to serve both purposes is not a shortcut; it is the approach the regulators anticipated.
All eight Annex III high-risk AI use-case clusters in the EU AI Act include scenarios where automated outputs can produce legal or similarly significant effects on individuals, meaning sovereign deployers in every regulated sector face the dual obligation without exception.
Local Explainability Without External API Calls
GDPR Article 15(1)(h) gives data subjects the right to meaningful information about the logic involved in any automated decision. AI Act Article 13 requires that high-risk systems be transparent enough for deployers to interpret outputs and for users to use the system appropriately. Both obligations must be fulfilled using explainability methods that keep personal data within sovereign infrastructure.
Three techniques are deployable entirely on-premises:
SHAP (SHapley Additive exPlanations) decomposes any model output into additive feature contributions using a game-theoretic foundation. The open-source Python library operates within the local inference runtime and requires no external service calls. SHAP values can be stored per decision record and surfaced to human reviewers and, in redacted form, to data subjects exercising Article 15 rights.
LIME (Local Interpretable Model-agnostic Explanations) approximates the model locally around a specific prediction using a simpler interpretable model. Like SHAP, it runs entirely within the Python environment and can be integrated into the inference pipeline on air-gapped or network-restricted sovereign servers.
Counterfactual explanations answer the question “what would have needed to be different for the outcome to change?” For a rejected credit application, a counterfactual might state that an income 12% higher or a debt-to-income ratio 5 points lower would have changed the outcome. This form of explanation is directly actionable for data subjects and satisfies the “meaningful information” standard more concretely than feature-importance scores alone. Libraries such as DiCE (Diverse Counterfactual Explanations) run locally and support tabular, text and image modalities.
IBM’s Cost of a Data Breach Report 2023 found an average total cost of EUR 4.45 million per breach globally, with regulated-sector breaches consistently above that average. Keeping explainability computation on sovereign infrastructure eliminates an entire category of data-exfiltration risk that would arise from sending decision inputs to an external explanation-as-a-service endpoint.
Article 26 AI Act Deployer Obligations and the GDPR Controller Role
When an organisation fine-tunes an open-weight model such as Mistral or Llama on its own data and deploys it on sovereign infrastructure, it is simultaneously a GDPR controller (for personal data processed during training and inference) and an AI Act Article 26 deployer (for the operational use of a high-risk system). In some configurations, where the fine-tuning constitutes a substantial modification of the original system, the organisation may also acquire provider-equivalent obligations under AI Act Article 25.
Article 26 deployer obligations include: using the system in accordance with the instructions of use provided by the provider; assigning human oversight to qualified individuals; conducting a fundamental-rights impact assessment where the system affects the public; informing affected workers before deploying systems that monitor or evaluate them; and maintaining logs to the extent technically feasible for the period specified in the AI Act’s implementing acts.
The DPO and the AI compliance officer must divide responsibilities without leaving gaps. A workable division assigns the DPO ownership of: the DPIA under GDPR Article 35, data-subject rights fulfilment including Article 15(1)(h) responses, supervisory authority liaison, and the data-governance aspects of training-data provenance. The AI compliance officer owns: the conformity assessment and technical documentation under AI Act Article 11, the human oversight protocol and reviewer training programme, post-market monitoring and incident reporting, and coordination with market-surveillance authorities. Both roles must jointly sign off on the unified audit-trail schema and the explainability methodology, because a gap in either domain can trigger enforcement from two separate regulatory directions simultaneously.
According to ENISA’s Threat Landscape 2023, over 40% of surveyed organisations in critical sectors reported using automated decision-making tools affecting individuals, yet the majority lacked formal governance structures that mapped to the dual GDPR and AI Act obligations.
FAQ
Does EU AI Act Article 14 replace the GDPR Article 22 prohibition on solely automated decisions?
No. Article 14 of the AI Act is a prospective design-and-oversight obligation that applies to high-risk AI systems throughout their lifecycle. GDPR Article 22 is a data-subject right that prohibits decisions based solely on automated processing unless a lawful basis applies. Both apply simultaneously and neither supersedes the other.
What did the ECJ rule in C-634/21 SCHUFA about automated credit scoring?
The Court held that producing a probability score that a third party then uses as the decisive factor in a credit decision constitutes automated decision-making within GDPR Article 22, even if the formal decision is taken by a human. A nominal human step that does not involve genuine assessment does not break the chain of automation.
Can SHAP or LIME run fully on-premises without sending data to external services?
Yes. Both SHAP and LIME are open-source Python libraries that operate entirely within the local runtime environment. They require no external API calls and can be integrated into an on-premises inference pipeline, making them suitable for sovereign deployments where data must not leave controlled infrastructure.
How should a DPO and an AI compliance officer divide responsibilities under both frameworks?
The DPO owns the Article 22 and Article 15(1)(h) obligations: the DPIA, data-subject rights fulfilment, and supervisory-authority liaison. The AI compliance officer owns the Article 14 and Article 26 obligations: conformity assessment, technical documentation, post-market monitoring, and the human oversight protocol. Both roles must jointly approve the unified audit trail that evidences compliance with both frameworks.
What does EDPB Guidelines 3/2025 add for organisations automating regulated decisions?
EDPB Guidelines 3/2025 clarify the boundary between the DSA and GDPR where recommender systems and automated content moderation overlap with personal-data processing. For regulated-sector deployers, the guidance reinforces that GDPR obligations, including Article 22, apply in full even when a system is also governed by sector-specific EU law, and that DPAs retain competence to investigate the data-processing layer of any automated system regardless of which other regulator supervises its outcome.
Hoe Qsentinel dit oplost
Qsentinel is the managed Nextcloud Enterprise workspace, enhanced by Qsentinel with post-quantum encryption and sovereign private AI, hosted in Switzerland or on-premise, out of reach of the CLOUD Act.