Privacy teams should identify where automated decisions have significant impact, document the data inputs and logic used, and ensure there is a lawful basis and human review path where required. They also need explainability, retention limits, and governance that aligns privacy review with AI oversight. The goal is to make automated processing defensible before regulators or individuals challenge it.
Why Article 22 Needs More Than a Legal Checklist
Automated decision-making under GDPR Article 22 is not just a privacy review problem, it is a control design problem. Privacy teams need to know where automation materially affects people, which inputs drive the outcome, and whether the system is being used in a way that creates legal or operational exposure. That usually means checking the decision path, the exception path, and the evidence trail together.
The hardest cases are rarely fully automated from end to end. Human review that is nominal only, poorly defined thresholds, or post hoc overrides that are not actually used can leave the organisation unable to defend the process. Teams should treat the presence of automation as a signal to examine decision authority, not as proof that the Article 22 obligations have been satisfied.
What Privacy Teams Should Document and Control
Start with the decision itself: what is being decided, what personal data is used, and what downstream effect makes the decision significant. For each system, privacy teams should map the inputs, the logic category or model behavior at a practical level, the recipient of the decision, and the points where a person can intervene or challenge the outcome. The strongest reviews also note where data minimisation, purpose limitation, and retention limits constrain the process.
That documentation should be usable by more than the original project team. If a regulator, auditor, or affected individual asks how the decision was made, the organisation should be able to show the policy basis, the review path, and the safeguards that reduce arbitrary or opaque processing. A useful reference point is the EU General Data Protection Regulation (GDPR), which anchors the privacy obligations around transparency, data protection by design, and lawful processing.
Explainability does not mean exposing source code or trade secrets in every case. It means being able to explain the factors that mattered, why the decision is significant, and how a person can seek review or contest it. Where AI systems are part of the workflow, privacy teams should align with broader AI governance so that model oversight, approval, and change control are not handled as separate silos.
Risk and Threat Considerations
Automated decision-making becomes risky when the organisation cannot show that the system is constrained, reviewable, and operating within the intended lawful basis. The main exposure is not only legal challenge, but also silent drift where the system’s inputs, thresholds, or business use change faster than the privacy controls around it.
Failure mechanism: Teams assume a human can intervene, but the override is rarely used, the decision logic is too opaque to explain, or the retention of inputs and outputs is too weak to reconstruct what happened after the fact. That leaves the organisation unable to evidence fairness, necessity, or effective review when the process is challenged.
Impact: The result can be enforcement exposure, withdrawal of trust, and operational disruption when the organisation must pause or redesign a decision process under pressure. In practice, the biggest problem is often not one bad decision, but a decision pipeline that cannot be defended consistently at scale.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST AI RMF, NIST CSF 2.0 and CIS Controls v8 set the technical controls, while EU AI Act define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | GOVERN — Govern | AI decision governance supports oversight, accountability, and human review for automated decisions. |
| MAP — Map | Mapping identifies context, use, impact, and stakeholders for automated personal-data decisions. | |
| MANAGE — Manage | Manage covers ongoing risk treatment, monitoring, and change control for AI decision processes. | |
| Recommendation — Establish accountable AI governance for automated decision systems and review escalation paths. Map the decision context, affected individuals, and data flows before deployment. Track drift, exceptions, and control changes throughout the AI decision lifecycle. | ||
| EU AI Act | Transparency and human oversight requirements | Automated decisions using personal data need transparency and human oversight where high-impact. |
| Recommendation — Build human oversight and disclosure obligations into the decision workflow. | ||
| NIST CSF 2.0 | GV.RM-03 — Legal and regulatory requirements are understood and managed | Article 22 creates a governance obligation to manage legal exposure for automated decisions. |
| PR.DS-01 — Data is managed consistently with risk and policy | Privacy teams must control inputs, retention, and use of personal data in decision systems. | |
| GV.OV-01 — Organizational context is established and communicated | Automated decision-making needs clear ownership and review accountability across teams. | |
| Recommendation — Align the automated decision process with applicable privacy obligations and approvals. Limit inputs and retention to the data actually needed for the decision. Assign clear ownership for decision logic, review, and challenge handling. | ||
| CIS Controls v8 | 3 — Data Protection | Personal data used for automated decisions requires retention limits and controlled handling. |
| 6 — Access Control Management | Human review and change control depend on appropriate access to decision systems and records. | |
| 8 — Audit Log Management | Article 22 defensibility depends on logs that show inputs, logic, and review actions. | |
| Recommendation — Classify and protect decision inputs, outputs, and retention records. Restrict who can change decision logic and who can approve exceptions. Retain audit logs that reconstruct the decision and review path. | ||
Practitioner Guidance
What to prioritise: Focus first on high-impact decisions where the consequence to the individual is material, then verify whether those decisions are truly automated or only partially reviewed. If the human step cannot change outcomes in a meaningful way, treat the process as higher risk and revisit the control design before relying on the review label.
What to verify: Make sure the documentation covers the actual decision logic used in production, not the intended logic from the project design. Privacy teams should also verify that retention schedules, challenge procedures, and ownership for model or rule changes are explicit, because those are the points most likely to break Article 22 defensibility over time.
Practitioner takeaway: The key question is not whether AI is involved, but whether the organisation can explain, review, and defend the decision path when the outcome matters to a person.
Related resources from NHI Mgmt Group
- How should teams govern automated decision-making systems under privacy regulations?
- Which teams should own privacy evidence when automated decisions use personal data?
- How should security teams implement GDPR controls for AI systems that process personal data in LLMs and agents?
- How should security teams control personal data sharing with third parties under GDPR?