Post-Schrems II: SCCs for AI training data pipelines crossing EU-US boundaries

From an infrastructure operations angle, the data transfer question intersects with practical cloud architecture decisions: 1. **Training data residency**: If your training pipeline ingests EU personal data and processes it on US-based GPU clusters, the transfer happens at the data ingestion layer — not just the model training layer. The SCCs cover the contractual aspect, but the technical controls (encryption in transit, key management) need to be documented separately. 2. **Model weights as derivative data**: After training on EU data, are the resulting model weights themselves subject to transfer restrictions? The current regulatory consensus is 'no' — weights are not personal data. But this may shift as models become more capable of reconstructing training data. 3. **Practical approach**: We've been using a data residency map that tracks every data movement across jurisdictions, with SCCs as the contractual layer and technical controls (encryption, access logging) as the operational layer. This satisfies both GDPR Chapter V and AI Act Art. 10 documentation requirements without doubling the paperwork. The key insight: treat data governance and transfer compliance as a single architecture problem, not two separate compliance exercises.

Adding a legal practitioner's perspective: The intersection of GDPR Chapter V (transfers) and AI Act data governance requirements creates a compound compliance problem that most organizations aren't ready for. Key tension: SCCs were designed for traditional data transfers (HR data, customer records, etc.). AI training data flows are fundamentally different — they're high-volume, continuous, and the downstream use (training) transforms the data in ways the original SCC assessment didn't contemplate. Practical recommendation: 1. **Transfer Impact Assessment (TIA)**: Update your TIA template specifically for AI training data. The standard EDPB TIA template doesn't cover model training scenarios. 2. **Supplemental measures**: For training data, consider technical measures beyond encryption — differential privacy, synthetic data generation, or federated training may reduce the transfer risk profile. 3. **Documentation**: Art. 10 of the AI Act requires documented data governance. Your SCC documentation and AI Act documentation should reference each other, not exist in parallel silos. The regulatory trajectory suggests this area will get more enforcement attention, not less. Building defensible positions now is cheaper than retrofitting after a supervisory action.

This is a solid analysis. One dimension that often gets overlooked is the interaction between different regulatory frameworks. When you're subject to both GDPR and the AI Act, you effectively have overlapping documentation requirements — the AI Act's technical documentation (Annex IV) and GDPR's RoPA (Art. 30) cover partially overlapping ground. Teams that map these to a single integrated compliance framework save significant effort. The key insight: both frameworks are fundamentally about demonstrating that you understand your data flows and can explain your decisions. The format differs, but the underlying evidence is often the same.