EU AI Act + GDPR Art.22: Automated Decision-Making Double Compliance Guide 2026

Post #1 in the sota.io EU AI Act + GDPR Intersection Series

When you build a credit-scoring AI, a recruitment screening tool, or an insurance risk classifier, you face a compliance challenge that most guides ignore: two separate EU frameworks apply simultaneously, and satisfying one does not automatically satisfy the other.

The EU AI Act classifies certain AI systems as high-risk under Annex III. GDPR Art.22 imposes independent obligations whenever those same systems produce decisions with significant legal or similarly significant effects on natural persons. The obligations overlap, complement, and sometimes conflict. Getting both right before the August 2, 2026 EU AI Act full-obligation deadline is not optional.

This is the first post in a five-part series examining every major EU AI Act–GDPR intersection point. We start with Art.22 because it is the most widely misunderstood and the source of the most enforcement risk in production AI deployments today.

What GDPR Art.22 Actually Prohibits

GDPR Art.22(1) gives data subjects the right not to be subject to a decision based solely on automated processing — including profiling as defined in GDPR Art.4(4) — which produces legal effects or similarly significantly affects them.

Three elements must all be present for Art.22(1) to apply:

1. Solely automated processing. There must be no meaningful human involvement in the decision. A human who rubber-stamps AI output without genuinely reviewing it does not break the "solely automated" chain — a point the EDPB has emphasised in its guidelines. Meaningful human oversight requires real capability to override, not just nominal sign-off.

2. Including profiling. GDPR Art.4(4) defines profiling as any form of automated processing used to evaluate personal aspects — including performance at work, economic situation, health, personal preferences, interests, reliability, behaviour, location, or movements. Most AI systems that make decisions about individuals will involve profiling.

3. Legal or similarly significant effect. A legal effect changes a person's legal status or rights: contract formation, credit access, insurance eligibility, employment. "Similarly significant" covers outcomes that substantially affect circumstances or behaviour even without formal legal consequence — loan rejection at a level that affects housing access, denial of insurance that leaves someone unprotected, or automated HR screening that blocks career progression.

Credit scoring, insurance underwriting, mortgage approval, automated hiring and dismissal, educational assessment that determines access to programmes, biometric categorisation for security clearances — all of these routinely meet all three criteria.

EU AI Act Annex III: The High-Risk Overlap Map

EU AI Act Art.6 establishes classification rules for high-risk AI systems. Systems listed in Annex III are presumptively high-risk, subject to a significant body of pre-market and ongoing obligations.

The Annex III categories most likely to also trigger GDPR Art.22 include:

When a system appears on this list AND its outputs feed directly into decisions that meet the Art.22(1) criteria, you have a full overlap: BOTH frameworks apply, BOTH sets of obligations are independently mandatory.

The Three Art.22(2) Exceptions — and Why They Are Narrower Than They Appear

GDPR Art.22(2) provides three gateways that permit solely automated decision-making despite Art.22(1):

(a) Necessary for entering into, or performance of, a contract. This is the most commonly invoked exception. Automated credit scoring to process a loan application may qualify. However, "necessary" is a high bar — if a human review could reasonably achieve the same purpose, automated processing is not necessary. Convenience is not necessity.

(b) Authorised by EU or Member State law. This exception requires a specific legal basis in national or EU law that also provides suitable safeguards. The GDPR itself does not create this basis — you need to identify the specific law.

(c) Based on the data subject's explicit consent. Explicit consent under GDPR has strict requirements: freely given, specific, informed, unambiguous, and actively provided (no pre-ticked boxes). Consent must be as easy to withdraw as to give. For employment contexts, genuinely free consent is structurally difficult given power imbalance.

The critical Art.22(4) carve-out. Even when one of the Art.22(2) exceptions applies, Art.22(4) prohibits automated decisions based on special-category data (Art.9 data: health, biometric, racial or ethnic origin, etc.) — except when the Art.22(2)(a) or (c) exception applies AND the controller has implemented suitable safeguards. This means Art.22(2)(b) — legal authorisation — does NOT suffice for special-category data in automated decisions. Health AI systems must use consent or contract necessity, not just any legal basis.

EU AI Act Art.14 vs GDPR Art.22(3): Two Human Oversight Frameworks

This is where double-compliance becomes most operationally complex.

EU AI Act Art.14 requires that high-risk AI systems be designed and developed with human oversight measures that enable the natural persons responsible to:

• Fully understand the system's capabilities and limitations
• Monitor the system's operation for signs of anomalous behaviour
• Remain able to decide not to use the system, or override its outputs
• Intervene and switch the system off when appropriate

Art.14(4) specifies that if the high-risk AI system operates at significant speed or scale that makes human review of individual decisions impractical, the built-in human oversight must at minimum allow meaningful review of a representative sample of outputs.

GDPR Art.22(3) requires controllers who process decisions under one of the Art.22(2) exceptions to implement suitable measures to safeguard data subjects' rights, freedoms, and legitimate interests. At minimum, this means:

• Providing meaningful information about the logic, significance, and consequences of the automated processing
• Granting the data subject the right to obtain human intervention
• Allowing the data subject to express their point of view
• Enabling the data subject to contest the decision

These requirements are not identical and cannot be satisfied by the same technical implementation without deliberate design. The AI Act Art.14 requirement focuses on internal operational oversight by the deployer's staff. The GDPR Art.22(3) requirement focuses on external procedural rights available to the data subject.

In practice, you need both. Your system needs a staff-facing human review capability (Art.14) AND a customer-facing decision review process (GDPR Art.22(3)). The former is about preventing AI errors from causing systemic harm. The latter is about ensuring individual recourse.

Dual Assessment Obligation: DPIA + EU AI Act Risk Management

GDPR Art.35(1) requires a Data Protection Impact Assessment before processing that is likely to result in a high risk to the rights and freedoms of natural persons. GDPR Art.35(3)(a) specifically identifies automated processing, including profiling, that significantly affects people, as a processing operation that requires a DPIA.

If you are running a high-risk AI system that makes automated decisions about individuals, you almost certainly need a DPIA. This is not a one-time exercise — the DPIA must be reviewed when circumstances change, and must be maintained as a living document.

EU AI Act Art.9 requires high-risk AI providers to implement a risk management system that is a continuous iterative process running throughout the system's lifecycle. The risk management system must identify and analyse known and reasonably foreseeable risks, estimate and evaluate risks that may emerge during intended use, and adopt appropriate risk management measures.

The DPIA and the AI Act risk management system address different risk dimensions — the DPIA focuses on privacy and data protection risks to individuals, while the Art.9 system focuses on safety and accuracy risks across the system's operation. Both are mandatory. Both require documentation. Both require updates when the system changes.

Practical integration approach. Many teams find it effective to run a combined risk workshop that feeds both documents, with separate chapters addressing the data protection lens (DPIA) and the AI safety lens (Art.9 risk management plan). This avoids duplication while ensuring each document meets its specific regulatory requirements.

Deployer Obligations Under EU AI Act Art.26

EU AI Act Art.26 places specific obligations on deployers — organisations that use high-risk AI systems in their professional activities. Deployers cannot outsource compliance to their AI provider.

Under Art.26, deployers of high-risk AI systems must:

• Use the system in accordance with the provider's instructions for use
• Assign human oversight to sufficiently competent natural persons
• Monitor the system's operation and report serious incidents
• Suspend or discontinue use when the system presents unacceptable risk
• Implement the fundamental rights impact assessment when deploying systems in Annex III categories involving public authorities or affecting individuals in specific sectors

For systems that also trigger GDPR Art.22, the deployer is typically the GDPR controller — the party that determines the purposes and means of the automated decision. This means the deployer must satisfy both the Art.26 EU AI Act obligations and the GDPR Art.22 / Art.35 obligations. Relying on the AI provider's documentation is not sufficient — the GDPR controller's accountability principle (Art.5(2) GDPR) requires demonstrable compliance at the controller level.

EU AI Act Art.9: Ongoing Risk Management for Automated Decision Systems

EU AI Act Art.9 establishes the risk management system as a continuous, iterative process. For systems that make automated decisions, this has practical implications that extend beyond initial deployment:

• Feedback loops. You must monitor whether the system's outputs are producing the harms you identified in your risk assessment. Automated decisions can exhibit drift — a system that was calibrated appropriately at launch may develop disparate impact over time as population characteristics shift.
• Post-market surveillance. Art.72 requires providers to collect and analyse post-market data. For deployers, this means ensuring that operational data about decision outcomes is captured and fed back into the risk management process.
• Incident escalation. EU AI Act Art.73 requires reporting of serious incidents. For automated decision systems, a serious incident could include a batch of decisions that affected a class of individuals in ways that were not anticipated and that caused significant harm.

Compliance Checklist: GDPR Art.22 + EU AI Act High-Risk AI

Before deploying an AI system that makes or meaningfully influences individual decisions:

GDPR Art.22 Checklist

• Map all decision outputs to determine whether any produce legal or similarly significant effects on individuals
• Identify whether the processing is "solely automated" — document any human oversight step and confirm it is genuinely meaningful
• Confirm which Art.22(2) exception applies, or redesign to require human involvement that breaks the "solely automated" chain
• Implement Art.22(3) safeguards: logic explanation, human review right, contestation mechanism
• Check whether special-category data (Art.9 GDPR) is involved — if so, verify Art.22(4) compliance
• Complete DPIA (Art.35) before go-live; schedule annual review
• Record the legal basis, safeguards, and risk assessment in your GDPR Records of Processing Activities (Art.30)

EU AI Act Art.6 / Annex III Checklist

• Determine whether the system falls under an Annex III category
• If yes, implement the full high-risk AI system obligations from August 2, 2026
• Establish and document the risk management system per Art.9
• Prepare technical documentation per Art.11
• Implement human oversight capability per Art.14 (staff-level)
• Assign deployer responsibilities per Art.26
• Register the system in the EU database per Art.49 if applicable
• Perform fundamental rights impact assessment per Art.27 if in a qualifying deployment context

Integration Points

• Confirm that the DPIA and the Art.9 risk management plan are separate but consistent documents
• Confirm that Art.14 human oversight (staff capability) and Art.22(3) human review right (data subject right) are both implemented — they are different mechanisms serving different purposes
• Add a review trigger that revisits both documents when the model is updated, retrained, or redeployed in a new context

What Changes on August 2, 2026

The EU AI Act full obligation date for high-risk AI systems under Annex III is August 2, 2026. From that date, deploying a high-risk AI system without the Art.9 risk management system, Art.11 technical documentation, and Art.14 human oversight capability in place exposes the deployer to penalties under Art.99.

GDPR Art.22 obligations have been in force since May 25, 2018. They are already enforceable and have already produced significant enforcement actions across Europe.

If your system is high-risk under the AI Act AND involves automated decisions under GDPR Art.22, you face two independent enforcement authorities with two sets of fines: GDPR fines up to 4% of annual global turnover from the national data protection authority, and EU AI Act fines up to 3% of annual global turnover (Art.99) from the national market surveillance authority.

Compliance with one does not create a safe harbour under the other. Build for both.

Next in This Series

Post #2 — DPIA for High-Risk AI: How to write an EU AI Act-aware Data Protection Impact Assessment that satisfies both GDPR Art.35 and AI Act Art.9 risk management requirements in a single process.

Post #3 — GDPR Art.17 Right to Erasure in AI Systems: How to handle deletion requests when personal data has been used to train or fine-tune an AI model, and what to do about RAG vector stores that contain derived representations.

Post #4 — Data Minimisation in AI Training: GDPR Art.5(1)(c) constraints on training dataset composition and inference-time personal data use.

Post #5 — The Full Compliance Stack: DPO role, accountability chain, audit trail, and running an AI-aware Records of Processing Activities.

sota.io is an EU-native managed PaaS. No US parent, no CLOUD Act exposure. Deploy your compliance-sensitive AI applications on infrastructure that is sovereign by architecture, not just by marketing. Start for free →