Common mistakes are assuming any automated scoring is outside Article 22, and failing to give people the required safeguards where decisions have legal or similarly significant effects. Teams should identify the decision logic, check whether human review is real, and ensure notices, challenge routes, and bias testing are in place where Article 22 applies.
How Article 22 mistakes usually happen
The most common failure is treating “automated” as if it automatically means “outside Article 22.” In practice, the real test is whether the decision is based solely on automated processing and produces legal or similarly significant effects. Teams also misread the boundary between low-risk automation and decisions that still trigger safeguard duties because the outcome materially affects a person.
Another frequent mistake is stopping at the model or score instead of reviewing the end-to-end decision process. If a risk score is fed into a workflow that staff rarely override, the organisation may still be making a decision with meaningful human impact even if a person technically clicks approve at the end.
For privacy and automated decisioning issues that sit alongside Article 22, AI and Privacy Guide is the most direct internal reference because it covers Article 22, profiling, and the surrounding GDPR analysis practitioners usually need together.
Why safeguards fail even when teams know the rule
A second class of mistake is treating safeguards as a notice-only exercise. Article 22-style decisions need more than a generic privacy notice if the processing triggers the rule. People need a meaningful route to challenge the decision, ask for human intervention where required, and understand the basis on which the organisation reached the result.
Bias testing is also often too shallow. Teams may run a one-time model review, but the real risk is that upstream data drift, threshold changes, or policy changes alter outcomes later. That means the control needs periodic reassessment, not just a launch checklist. For broader privacy compliance pitfalls that often travel with automated decisioning failures, Top 10 Privacy Compliance Mistakes helps place Article 22 errors in the wider GDPR control environment.
Human review is another weak point. A review is not meaningful if the reviewer simply rubber-stamps the machine output, has no authority to change it, or lacks enough context to disagree. In those cases, the process looks human-supervised on paper but behaves like automation in reality.
What practitioners should verify before relying on an automated decision
The best way to avoid Article 22 mistakes is to verify the decision path, not just the model. Practitioners should confirm what input data is used, which business rule or score drives the outcome, where human intervention occurs, and whether the final outcome can genuinely change after review. That is the difference between an assistive workflow and a decision that may require Article 22 safeguards.
It is also worth checking the operational evidence. Can the team show that notices were given, challenge requests were handled, and exceptions were reviewed by someone with real authority? If those records do not exist, the organisation may have a policy statement rather than an enforceable control. Where automated decisions depend on account access, workflow permissions, or privileged system actions, the supporting control plane should be reviewed alongside the decision logic itself, and Top 10 MFA Mistakes is a useful companion when weak access controls are part of the failure mode.
Teams should also separate legal interpretation from implementation detail. The legal team can tell you when Article 22 applies, but product, engineering, and operations teams have to prove how the workflow works in practice and whether the safeguards are actually enforceable.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while GDPR defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Automated decision systems need tightly scoped access to limit unauthorized changes. |
| AU-6 — Audit Review, Analysis, and Reporting | Article 22 safeguards depend on reviewable logs for decisions, overrides, and challenges. | |
| Recommendation — Restrict decision-system permissions to the minimum required for each role. Log decision inputs, overrides, notices, and challenge handling for auditability. | ||
| GDPR | Article 22 — Automated individual decision-making, including profiling | The question is directly about mistakes around GDPR Article 22 automated decisions. |
| Article 15 — Right of access by the data subject | People affected by automated decisions may need access to meaningful information about the logic involved. | |
| Article 35 — Data protection impact assessment | High-impact automated decisions often require structured privacy risk assessment before deployment. | |
| Recommendation — Assess whether the decision triggers Article 22 and provide required safeguards when it does. Provide accessible information about the decision logic and the data used. Run a DPIA when automated processing may create high risk to individuals. | ||
Practitioner Guidance
What to prioritise: Start by mapping the exact decision flow from data intake to final outcome. If the review step cannot truly reverse the result, treat the process as higher risk and reassess whether the safeguards match the actual automation path.
What to verify: Check that notices, challenge routes, and human review are operational, not just documented. The evidence should show who can intervene, how often exceptions are used, and whether the organisation has tested the process after model, threshold, or policy changes.
Common mistake: Do not confuse “a person was involved somewhere” with meaningful human intervention. If the person cannot change the outcome or lacks the context to do so, the safeguard is weak even if the workflow includes a manual step.
Practitioner takeaway: Article 22 failures usually come from control design, not from the model alone. The question is whether the automation is genuinely bounded by review, explanation, and challenge mechanisms that work when the decision matters most.