Adding a data point from the compliance-engineering side:
The GDPR Art. 22 documentation requirement is often misunderstood as needing a separate 'human review log.' In practice, what auditors look for is traceability — can you reconstruct the decision path for any individual data subject?
What worked for us:
1. **Decision snapshot at inference time**: Every automated decision gets a JSON snapshot stored with the prediction — feature values, model version, confidence score, and the threshold that triggered the action. This is your Art. 22 'meaningful information about the logic involved.'
2. **Human review workflow**: When a data subject requests review (Art. 22(3)), the human reviewer gets the snapshot + a simplified explanation of which features drove the decision. The reviewer's action (uphold/override) is logged with a reason code.
3. **Audit trail format**: We store these in append-only tables (PostgreSQL with row-level security). The key insight: your automated decision log IS your Art. 22 documentation — you don't need a separate compliance artifact if the engineering system captures the right fields.
The EU AI Act adds another layer here: high-risk systems need logging under Art. 12 that captures not just the decision but the system state, anomalies, and any model updates. If you're building the Art. 22 log right, you're 60-70% of the way to AI Act logging compliance.
The remaining 30% is the pre-market conformity assessment documentation (Annex IV), which is a different beast entirely.