GDPR Art. 22 compliance when using ML models for candidate pre-screening

From an infrastructure perspective, the hardest part of Art. 22 compliance in candidate screening isn't the model — it's the logging pipeline. You need to store: (1) the input features, (2) the model version, (3) the output score, (4) the human reviewer's decision, and (5) the timestamp chain showing the human had meaningful time to review before the decision was finalized. We implemented this as an immutable audit log in S3 with write-once-read-many (WORM) retention. Each scoring event gets a correlation ID that ties the model output to the HR system's hiring decision. The auditor can trace any rejected candidate back to the exact model version, feature set, and human review timestamp. The key insight: the 'meaningful human review' requirement (Art. 22(3)) means the human can't just rubber-stamp. Our system enforces a minimum 30-minute review window and requires the reviewer to document at least one factor they independently verified. That documentation is part of the audit trail.

This touches on a real gap. technical teams often underestimate the audit trail requirements until the first SOC 2 or ISO 27001 assessment. In practice, most organizations I've seen default to the strictest interpretation across all applicable jurisdictions. The regulatory text doesn't explicitly address this edge case.

From an implementation standpoint, the biggest gap I've seen is that traditional DPA frameworks assume a human requestor with a clear identity and session context. When you have agents making API calls on behalf of workflow triggers, the data subject's original consent chain often gets broken at the delegation layer. What's worked for us: treating the agent's service account as a separate data processor role in your records, with explicit mapping back to the originating consent event. This means every agent action that touches personal data needs a traceable link to (a) which data subject's data, (b) which consent event authorized it, and (c) whether the processing purpose still matches. The AI Act's transparency requirements (Art. 50) compound this — you need to document not just what data flows through the agent, but whether the data subject was informed that an automated system would process their data. Most teams I've talked to handle the GDPR piece but haven't layered the AI Act disclosure on top yet.

The intersection between Art. 22 and SOC 2 CC6.1 is where most compliance teams get stuck. Art. 22 requires meaningful human intervention for automated decisions — but SOC 2 auditors want to see that the same human reviewer role is also properly access-controlled and logged. Practical approach: implement a three-layer review model: 1. Automated pre-screening by the agent (flagged, not finalized) 2. Human reviewer with documented decision authority (RBAC-enforced, logged) 3. Post-hoc audit trail that links the agent's initial recommendation to the human's final decision The key evidence piece for SOC 2: your RBAC system must prevent the agent's service account from bypassing the human review step. If the agent can auto-approve without human sign-off, CC6.1 fails and you're also exposed on Art. 22. For documentation, I recommend mapping each control objective to both frameworks simultaneously — it saves about 40% of evidence collection effort compared to treating them as separate audits.