Article 22 limits decisions based solely on automated processing, including profiling, when they produce legal or similarly significant effects on a person. Organisations should flag such decision paths, offer human review where required, and explain the logic, significance, and consequences to the individual. Separate these flows from lower-risk automation that does not make the final decision.
What Article 22 is actually controlling
Article 22 is not a ban on automation. It narrows when an organisation may rely on a decision that is made solely by automated processing, including profiling, if that decision produces legal effects or similarly significant effects for the individual. The practical test is whether a human is truly making the final decision, or whether automation is only presenting a recommendation that still gets independently reviewed.
That distinction matters because Article 22 is aimed at outcomes, not system design diagrams. A workflow can use scoring, ranking, fraud signals, or eligibility models, but if those outputs are the final decision and the impact on the person is significant, the organisation has moved into Article 22 territory. Lower-risk automation can still be useful, but it should be separated from the final decision path so the organisation can show where human judgment begins.
For privacy and data protection analysis, the key question is not whether AI or rules are used, but whether the process creates a decision about a person that changes their legal position, access, rights, or other materially important outcome. The EU General Data Protection Regulation (GDPR) is the core external reference for that legal test, and the AI and Privacy Guide gives a practitioner view of where automated decision-making, profiling, and privacy obligations intersect.
How the decision path should be structured
In practice, organisations should map the full journey from input to outcome. That means identifying when profiling, scoring, triage, or eligibility checks are used, then determining whether those outputs are advisory or determinative. If the decision is supposed to be reviewed by a person, the review must be real, not merely a rubber stamp. If the person reviewing the case cannot or does not override the system, the process may still function as a solely automated decision.
It also helps to separate the technical workflow from the governance workflow. The model or rule engine may produce a score, but the business process should clearly show who can accept, reject, or override that score, what evidence they can see, and what happens when the case is escalated. That separation makes it easier to demonstrate when Article 22 applies and when it does not.
Individuals should also receive meaningful information about the logic behind the decision, the significance of the outcome, and the likely consequences. That does not mean revealing source code or every feature weight, but it does require an explanation that is specific enough to be useful rather than generic. If the explanation does not help a person understand why the decision happened, it is probably too vague for this context.
When the automation becomes legally sensitive
The legal sensitivity usually rises when the automated decision affects access, opportunity, or rights in a way that is hard to undo. Examples include rejecting an application, denying a benefit, changing a contract outcome, or making a high-impact eligibility determination. At that point, the organisation should expect closer scrutiny of whether the process is genuinely necessary, whether a lawful basis exists, and whether safeguards such as human review are in place.
The risk is not just regulatory. If the organisation cannot explain the role of automation, it may struggle to defend the decision, handle a complaint, or respond to a subject access or objection request. If the process mixes advisory automation with final decisioning, teams may also lose visibility into which cases were truly automated and which were reviewed, making governance and audit trails weaker over time.
This is where documentation matters most. A clear record of the decision path, the role of human reviewers, the explanation given to the person, and any exceptions or overrides is often more valuable than a generic policy statement. It shows the organisation understands where the automation boundary sits and can prove that the boundary is enforced in practice.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
GDPR provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| GDPR | Art. 22 — Automated individual decision-making, including profiling | Article 22 directly governs solely automated decisions with significant effects on individuals. |
| Art. 13 — Information to be provided where personal data are collected from the data subject | Automated decisioning requires clear notice and intelligible information to the person affected. | |
| Art. 15 — Right of access by the data subject | Affected individuals may seek information about the processing and decision path used. | |
| Recommendation — Map each decision path to Article 22 and require meaningful human review where the rule applies. Ensure notices explain the logic, significance and consequences of automated decisions. Preserve records that support access requests about automated decision-making. | ||
Practitioner Guidance
What to verify: Confirm whether the system output is merely informative or whether it is functionally deciding the outcome. If reviewers always follow the model, or if no one can change the result, treat the path as high-risk automated decisioning even if a human is nominally present.
Decision rule: If the decision can materially affect a person’s rights, access, or opportunities, require a documented review path, a usable explanation, and a way to evidence that the final decision was not solely automated.
What practitioners underestimate: Many teams focus on the model and ignore the surrounding workflow. The compliance issue often turns on process design, reviewer authority, and explanation quality, not on whether the system uses AI or a simpler scoring engine.
Practitioner takeaway: The safest posture is to classify the whole decision chain, not just the algorithm, and to prove that any human step is substantive enough to interrupt full automation where Article 22 would otherwise apply.