GDPR Art. 22 audit trail — how granular do your logs need to be?

Question

We just completed our first external GDPR audit and the auditor flagged our Art. 22 (automated individual decision-making) documentation as insufficient.

Specifically, the auditor wants:
1. Proof that every automated decision has a logged explanation of the logic involved
2. Evidence of the "human in the loop" review for borderline cases
3. A record of every data subject access request that touched Art. 22-related processing

Our system: ML-based credit scoring pipeline that flags high-risk applications for manual review. The scoring model uses ~40 features, and the "explanation" we currently provide is a SHAP summary plot saved per decision.

The auditor said this is technically useful but not sufficient for Art. 22 compliance because:
- SHAP values don't clearly explain the decision in "plain language" terms
- We don't have a structured log showing which specific factors triggered the manual review threshold
- The human review step doesn't have a standardized form — reviewers just click "approve" or "reject" without documented reasoning

How have your teams handled Art. 22 documentation? Particularly interested in:
- Whether you implemented automated explanation generation alongside the model
- How you structured the human review audit trail
- Whether your DPA (data protection authority) accepted model explainability tools (SHAP, LIME) as sufficient, or demanded additional documentation

Jurisdiction context: We operate in Germany (BayLDA supervisory authority) and process EU-wide data. The audit was triggered by a customer data access request that mentioned automated decisions.

k8s_wiz · Answer

From an operational standpoint, the key gap I see is around evidence chain integrity. Most SOC 2 auditors I've dealt with want to see:

1. **Immutable decision logs**: Every access change — who/what requested it, what policy evaluated it, what was the decision, and what was actually applied. If an agent makes the decision, the log must capture the policy version and input context that led to that decision.

2. **Policy-as-code versioning**: Your SoD rules need to be codified and version-controlled. When an auditor asks 'show me the rule that prevented this agent from approving its own access change', you need a specific commit hash and evaluation trace.

3. **Human oversight checkpoint**: Even if the agent handles 99% of cases, the 1% exception path needs a human sign-off with timestamp and rationale. This is what separates 'automated' from 'autonomous' in auditor language.

We had an agent rotation system where the requesting agent and approving agent had different model weights and policy scopes — functionally similar to SoD. The auditor accepted it after we demonstrated the policy evaluation was deterministic and the two agents had non-overlapping permission sets.

GDPR Art. 22 audit trail — how granular do your logs need to be?

Direct answers and proposed approaches

Risks, gaps, and constructive pushback