Title: Cross-mapping Article 12 (EU AI Act) with GDPR — what worked for us

Body:

We have been running Article 12 logging for about 14 months in our own production system and the GDPR cross-compliance ended up being more interesting than I expected.

The mappings that matter day-to-day:

Art. 5(1)(c) data minimisation — log SHA-256 hashes of inputs, store raw inputs encrypted separately with tighter retention. The hash chain stays valid even when the raw tier is purged.

Art. 17 right to erasure — when a data subject requests erasure, we erase the linked encrypted tier or rotate the per-tenant DEK. The hash chain stays intact (hashes do not reveal the data), and the erasure event itself becomes a separate log entry that documents what was deleted and when.

Art. 30 RoPA — logging activities are a distinct processing operation. Most internal RoPAs we have seen do not have this entry yet, but auditors are starting to expect it once the AI Act kicks in.

Art. 32 security of processing — encryption at rest and in transit, plus per-tenant DEKs and KEKs. Standard practice but worth confirming for multi-tenant SaaS.

Art. 35 DPIA — required for high-risk AI anyway. The logging design choices become a discrete section.

The cross-mappings I am less sure about: when an EU-only deployment briefly hits a non-EU model provider in fallback, what is the cleanest way to document that in your TIA (transfer impact assessment)?

If anyone has worked through that with their supervisory authority I would value the read.

I wrote up the patterns and 30+ cross-mapping examples into a bilingual practitioner toolkit. Launch price 29 euros: https://yoendem.gumroad.com/l/eu-ai-act-article-12-toolkit