AI Data Transfers: GDPR, SCCs & EU AI Act Rules

Where GDPR and the EU AI Act Overlap on Data

Organizations that train, develop, or deploy AI systems using data that originates in the European Economic Area now operate under two parallel regulatory frameworks that were not designed to interact. The General Data Protection Regulation governs how personal data is processed and transferred across borders. The EU AI Act governs how AI systems are placed on the EU market, including specific data governance obligations for high-risk systems and general-purpose AI models. Both instruments apply to providers outside the EU under conditions that are broader than most organizations assume. [Verified: June 2026]

GDPR Article 3(2) extends the regulation’s scope to any controller or processor established outside the EU when its processing activities relate to offering goods or services to data subjects in the EU, or to monitoring their behavior. The AI Act Article 2 applies to providers placing AI systems on the EU market, deployers using AI systems within the EU, and—critically—providers and deployers located in third countries when the output of the AI system is used in the EU. This means a US-based AI provider whose model is accessed by EU users, or whose outputs inform decisions affecting EU individuals, faces AI Act obligations regardless of where the system was trained. [Verified: June 2026]

The overlap zone is neither theoretical nor narrow. It encompasses every instance where an AI system is trained on datasets containing EU personal data that are transferred to a third country for model development, fine-tuning, or testing. The GDPR requires a lawful basis for the processing and a valid transfer mechanism under Chapter V. The AI Act requires documented data governance that may itself reveal personal data processing activities. The two frameworks demand different forms of documentation, serve different oversight purposes, and impose different penalties—yet they apply to the same data flows, the same organizational actors, and the same technical systems.

The Dual Framework Problem

The core difficulty is structural. GDPR compliance is data-centric: it follows personal data from collection through processing to deletion or anonymization. AI Act compliance is system-centric: it follows an AI system from design through deployment to market surveillance. A single training dataset may contain personal data subject to GDPR transfer rules, while the AI system built from that dataset is subject to AI Act data governance obligations. The GDPR does not care whether the system is high-risk under the AI Act. The AI Act does not care whether the underlying data was lawfully transferred under GDPR Chapter V. Each framework operates independently, and neither provides a safe harbor for compliance with the other.

For third-country providers, this creates a compliance architecture problem. A provider based in the United States that trains a large language model on web-scraped data containing EU personal data must satisfy GDPR Article 46 transfer requirements—typically Standard Contractual Clauses with a Transfer Impact Assessment—while also satisfying AI Act Article 53 obligations for general-purpose AI models, including a publicly available summary of training content. The training data summary itself may disclose the scope of personal data processing, potentially creating tension with GDPR data minimization principles. The provider cannot assume that AI Act compliance documentation substitutes for GDPR records, or vice versa.

Both frameworks also require the appointment of an EU-based representative under certain conditions. GDPR Article 27 mandates a representative for non-EU controllers and processors caught by Article 3(2). The AI Act Article 22 (for high-risk systems) and Article 54 (for general-purpose AI models) require third-country providers to appoint an EU authorized representative before placing a system on the market. These are separate legal roles with separate functions. The GDPR representative communicates with data protection authorities on data subject rights and breach notifications. The AI Act representative verifies technical documentation, retains conformity records for ten years, and cooperates with market surveillance authorities. A single entity may perform both functions if properly mandated, but the mandates are not interchangeable. [Verified: June 2026]

The Data Governance vs. Data Transfer Tension

The tension between the two frameworks becomes operational at the point where AI Act data governance requirements intersect with GDPR data transfer restrictions. The AI Act Article 10 imposes detailed data governance obligations on high-risk AI systems, including requirements to document data origin, collection processes, preparation operations, assumptions about data availability and suitability, bias examination, bias mitigation measures, and gaps in dataset coverage. Article 10(3) requires datasets to be relevant, sufficiently representative, and as error-free and complete as possible. Article 10(4) requires datasets to reflect the geographical, contextual, behavioral, and functional settings of the system’s intended use. [Verified: June 2026]

These obligations generate documentation that the GDPR does not explicitly require, but that may itself contain personal data or reveal personal data processing. A dataset origin record under Article 10(2)(b) must state, “in the case of personal data, the original purpose of the data collection.” This directly implicates GDPR Article 6 lawful basis analysis and Article 13/14 transparency obligations. If the original collection purpose was incompatible with AI training, the GDPR may prohibit the processing regardless of what the AI Act requires for system conformity.

The most acute collision occurs under AI Act Article 10(5), which creates a narrow exception for processing special category personal data—data revealing racial or ethnic origin, political opinions, religious beliefs, trade union membership, genetic or biometric data, health data, or data concerning sex life or sexual orientation—for the purpose of bias detection and correction. GDPR Article 9(1) prohibits processing such data unless an exemption applies. Article 10(5) of the AI Act provides one such exemption, but only under six cumulative conditions: the objective cannot be achieved with synthetic or anonymized data; the data is subject to technical limitations on re-use and state-of-the-art security and pseudonymization; access is strictly controlled and documented; the data is not transmitted, transferred, or accessed by other parties; the data is deleted once bias is corrected or the maximum retention period ends; and the records of processing document why the exception was necessary. [Verified: June 2026]

The fourth condition—that the special category data must not be “transmitted, transferred or otherwise accessed by other parties”—creates a significant operational constraint that organizations must evaluate carefully when designing bias detection processes. In practice, this requirement may substantially limit the ability to involve external vendors, cloud service providers, or cross-border processing arrangements where other parties could access the data. The precise interaction between Article 10(5) and the GDPR Chapter V transfer mechanisms has not yet been clarified through enforcement practice or authoritative guidance. Organizations should therefore avoid assuming that compliance with GDPR transfer mechanisms alone resolves the Article 10(5) restriction and should assess whether their processing model can satisfy both frameworks simultaneously.

GDPR Transfer Mechanisms for AI Data: Current Status

Organizations transferring personal data for AI training, validation, or testing must select a GDPR Chapter V mechanism that accounts for the specific risks of AI data flows. The standard mechanisms—adequacy decisions, Standard Contractual Clauses, Binding Corporate Rules, and derogations—remain available, but their application to AI contexts requires adjustments that many existing compliance programs have not yet made.

Adequacy Decisions

As of 2026, the European Commission has recognized fifteen jurisdictions as providing adequate data protection. Full adequacy decisions cover Andorra, Argentina, the Faroe Islands, Guernsey, the Isle of Man, Israel, Japan, Jersey, New Zealand, South Korea, Switzerland, the United Kingdom, and Uruguay. Canada holds a partial adequacy decision limited to commercial organizations subject to the Personal Information Protection and Electronic Documents Act. The United States does not have a general adequacy decision; the EU-US Data Privacy Framework provides adequacy only for organizations certified under that framework. US entities that are not DPF-certified must rely on SCCs with a Transfer Impact Assessment. [Verified: May 2026]

An adequacy decision satisfies GDPR Chapter V but does not satisfy AI Act data governance obligations. A provider transferring personal data to an adequate jurisdiction for AI training must still document data origin, collection purpose, and bias detection measures under Article 10. The adequacy decision removes the transfer lawfulness question; it does not remove the AI Act conformity question. Organizations that treat adequacy as a blanket compliance solution risk missing AI Act obligations that apply regardless of where the data is processed.

The UK adequacy decision was renewed in December 2025 and remains valid through December 2031. This is relevant for AI providers with UK-based data processing operations, though post-Brexit UK data protection law continues to diverge from EU law in areas such as automated decision-making and international transfers. Organizations should monitor whether UK adequacy renewal conditions impose any AI-specific requirements in future reviews. [Verified: April 2026]

Standard Contractual Clauses

The 2021 Standard Contractual Clauses (Commission Implementing Decision 2021/914) are the mandatory version for transfers not covered by an adequacy decision. Legacy SCCs adopted under the 2001, 2004, and 2010 decisions should have been replaced for all ongoing transfers. The 2021 SCCs contain four modules: controller-to-controller, controller-to-processor, processor-to-processor, and processor-to-controller. For most AI training data scenarios, Module 2 (controller-to-processor) applies when an EU-based data controller sends personal data to a third-country AI developer acting as a processor. [Verified: June 2026]

AI-specific considerations arise in SCC implementation that standard data protection agreements do not address. Clause I(b) on purpose limitation requires that processing be limited to the purposes specified in Annex I. If the Annex I description states that data will be used for “AI model training,” that purpose must be specific enough to satisfy both GDPR Article 5(1)(b) and AI Act Article 10(2)(b), which requires documentation of the original purpose of data collection. Vague descriptions such as “machine learning research” may fail both tests.

Clause II on data minimization requires that personal data be adequate, relevant, and limited to what is necessary. This conflicts with AI Act Article 10(3), which requires datasets to be “sufficiently representative” and as complete as possible. A dataset that is minimal under GDPR may be insufficient under the AI Act. Organizations must document how they satisfy both requirements—typically by demonstrating that the dataset is no larger than necessary for the AI system’s intended purpose, while still meeting representativeness requirements for that purpose.

Annex II on security measures must cover AI-specific risks. Standard encryption and access controls may not address risks particular to AI systems, such as model inversion attacks that reconstruct training data from model outputs, membership inference attacks that determine whether an individual’s data was in the training set, or data reconstruction from gradient updates in federated learning. The SCC security annex should specify technical measures against these risks, not generic information security controls.

Transfer Impact Assessments

Following the Schrems II judgment (CJEU, July 2020) and the EDPB Recommendations 01/2020, a Transfer Impact Assessment is mandatory for all transfers based on Article 46 mechanisms. The TIA must assess whether the law and practice of the destination country undermine the protections guaranteed by the SCCs. [Verified: June 2026]

For AI data transfers, the TIA must include factors that standard assessments often omit. The assessment should examine whether the destination country’s surveillance laws provide for government access to AI training environments, model weights, or inference logs. The US CLOUD Act, for example, permits US law enforcement to compel disclosure of data held by US providers regardless of where the data is stored. China’s Cybersecurity Law and Data Security Law impose data localization and government access obligations that may conflict with SCC protections. The TIA should also assess whether the technical environment in which the AI model is trained provides safeguards equivalent to EU standards—specifically, whether the training infrastructure supports encryption, access logging, and data segregation in ways that prevent unauthorized reconstruction of personal data from model artifacts.

The EDPB guidelines on data transfers to third country authorities, adopted in final form in June 2025, provide additional guidance on handling government access requests. These guidelines are directly relevant for AI providers that may receive compulsory disclosure orders for training data, model parameters, or inference records. The guidelines clarify that SCCs do not automatically authorize disclosure to foreign authorities and that organizations must assess whether the requesting authority has demonstrated necessity and proportionality. [Verified: June 2026]

Binding Corporate Rules

Binding Corporate Rules under GDPR Article 47 remain available for intra-group AI data transfers. BCRs require approval from the lead supervisory authority and must be updated to reflect changes in processing activities. For organizations developing high-risk AI systems across multiple group entities, BCRs should explicitly address AI Act data governance obligations, including the documentation requirements of Article 10 and the restrictions on special category data transfers under Article 10(5). A BCR that was approved before the AI Act entered into force may not cover these obligations unless amended. Organizations should review their BCRs for gaps before the high-risk AI system obligations take effect. [Verified: June 2026]

EU AI Act Data Governance Obligations by Risk Level

The AI Act imposes data governance obligations that vary by system risk classification. These obligations determine what data must be documented, what data may be processed, and what data must remain within the EEA. Understanding the risk-tier structure is essential for mapping GDPR transfer requirements because the data governance burden—and the transfer restrictions—intensify as risk classification rises.

High-Risk AI Systems — Article 10 Requirements

High-risk AI systems, defined in AI Act Annex III, include systems used in biometric identification, critical infrastructure management, education and vocational training, employment and worker management, access to essential services, law enforcement, migration and border control, and administration of justice. The data governance obligations for these systems apply from 2 August 2026, though the Digital Omnibus proposal may defer this deadline to 2 December 2027 if formally adopted. [Verified: June 2026]

Article 10 requires providers to establish data governance and management practices for training, validation, and testing datasets. The obligation is not merely to document data but to demonstrate that the data governance design supports the system’s conformity with essential requirements. Article 10(2) mandates documentation of: design choices regarding datasets; data collection processes and origin; data preparation operations such as annotation, labeling, cleaning, updating, enrichment, and aggregation; assumptions about data availability, suitability, and limitations; examination of possible biases; appropriate bias detection and mitigation measures; and identification of gaps or shortcomings in dataset coverage. [Verified: June 2026]

Article 10(3) requires datasets to be relevant, sufficiently representative, and as error-free and complete as possible to the best extent possible. Article 10(4) requires datasets to reflect the geographical, contextual, behavioral, and functional settings within which the high-risk AI system is intended to be used. These requirements have direct implications for cross-border data flows. A system intended for deployment across multiple EU member states may require training data from each jurisdiction to satisfy representativeness requirements. If that data is transferred to a third country for model training, each transfer requires a GDPR Chapter V mechanism, and the Article 10 documentation must record the lawful basis for each transfer.

The GDPR intersection is explicit in Article 10(2)(b), which requires documentation of “the origin of data, and in the case of personal data, the original purpose of the data collection.” This provision creates a practical documentation bridge between AI Act conformity and GDPR compliance. Documentation maintained under AI Act Article 10 may also support GDPR Article 30 records of processing where it contains the information required by the GDPR, including the purposes of processing, categories of data subjects, categories of personal data, recipients, transfers to third countries, and retention periods. Organizations should nevertheless ensure that all mandatory Article 30 elements are fully documented, even where separate AI Act records are used to support that obligation, in order to reduce duplication while maintaining compliance with both frameworks.

Special Category Data for Bias Detection — Article 10(5)

Article 10(5) creates a tightly constrained exception for processing special category personal data under GDPR Article 9(1) for the purpose of bias detection and correction. The exception applies only when six cumulative conditions are met. Published regulatory guidance and the official AI Act service desk materials confirm that these conditions are mandatory, not discretionary. [Verified: June 2026]

First, the bias detection objective must not be effectively fulfillable by processing synthetic data, anonymized data, or other data that does not involve special category data. This is a necessity test: the organization must demonstrate that synthetic or anonymized alternatives were evaluated and found insufficient. Second, the special category data must be subject to technical limitations on re-use and protected by state-of-the-art security and pseudonymization measures. Third, access must be strictly controlled and documented. Fourth—and this is the condition that governs cross-border transfers—the data must not be transmitted, transferred, or accessed by other parties. Fifth, the data must be deleted once bias has been corrected or the maximum retention period has expired, whichever comes first. Sixth, the records of processing must document why the exception was necessary. [Verified: June 2026]

The fourth condition significantly restricts how special category data used for bias detection may be handled. Organizations should not assume that adequacy decisions, Standard Contractual Clauses, or Binding Corporate Rules automatically resolve the separate requirement that the data must not be transmitted, transferred, or otherwise accessed by other parties. Whether a particular outsourcing arrangement, cloud deployment, or cross-border processing model satisfies Article 10(5) will depend on its technical and contractual design and may ultimately be clarified through future guidance or enforcement. Organizations should therefore evaluate these arrangements conservatively before relying on Article 10(5).

Operationally, organizations should design bias detection workflows so that special category data remains subject to the strict controls required by Article 10(5). Particular attention should be given to cloud deployments, subcontracting arrangements, remote access, and cross-border processing where other parties could gain access to the data. Until additional regulatory guidance becomes available, organizations should adopt a conservative approach and ensure they can demonstrate that any processing arrangement satisfies both the AI Act requirements and the applicable GDPR obligations.

General-Purpose AI Models — Article 53 Obligations

General-purpose AI models, defined in AI Act Article 3(63) as models trained with large amounts of data using self-supervision at scale that display significant generality and capability to perform a wide range of tasks, have been subject to specific obligations since 2 August 2025. Article 53 requires providers of GPAI models to: maintain technical documentation; maintain information and documentation for downstream providers; implement a policy to comply with EU copyright law, including reservation of rights under the Digital Single Market Directive Article 4(3); and draw up and make publicly available a summary of the content used for training the model. [Verified: June 2026]

The copyright compliance obligation under Article 53(1)(c) interacts with GDPR data transfer rules in ways that are not yet fully tested. Web-scraped training data may contain both copyrighted material and personal data. A provider that scrapes EU websites for training data must comply with GDPR lawful basis requirements for the personal data and with copyright law for the protected content. The TDM opt-out under DSM Directive Article 4(3) allows rightsholders to reserve their rights against text and data mining, but it does not address whether the scraped data contains personal data or whether the scraping itself constitutes processing under GDPR. Providers that rely on legitimate interest for web scraping must conduct a balancing test that considers both copyright and data protection interests.

The training data summary under Article 53(1)(d) must follow the AI Office template, published on 24 July 2025. The template requires disclosure of: dataset modalities (text, image, audio, video, code, tabular, other); total dataset size; number of data points; languages covered; data acquisition dates; major datasets used; web crawler specifications; top 10% domains by volume; datasets exceeding 3% of total training data; and measures taken to comply with TDM opt-outs. [Verified: June 2026]

The GDPR tension arises when the training data summary reveals personal data processing that the provider has not disclosed under GDPR transparency obligations. If the summary discloses that a dataset contains “social media posts from EU users,” that disclosure may trigger GDPR Article 13/14 information requirements if the provider has not already notified those users. The AI Office template permits withholding of confidential business information and trade secrets, but it does not provide a blanket exemption from GDPR transparency obligations. Providers should scope their summaries at an aggregate level—describing dataset types and sources rather than individual data subjects—to minimize GDPR exposure.

GPAI Models with Systemic Risk — Article 55

Providers of GPAI models with systemic risk face additional obligations under Article 55. Systemic risk is defined in Article 52 based on cumulative training compute exceeding 10^25 FLOP or a designation by the AI Office. Obligations include: performing model evaluation; assessing and mitigating systemic risks at the EU level; tracking and reporting serious incidents to the AI Office; and ensuring adequate protection of the model against attempts to influence it through manipulation, design vulnerabilities, or data poisoning. [Verified: June 2026]

The incident reporting obligation creates a potential GDPR intersection. If a serious incident involves personal data—such as a data poisoning attack that causes the model to output personal data it was not supposed to retain—the provider may have simultaneous obligations to report to the AI Office under Article 55 and to notify the relevant data protection authority under GDPR Article 33. The two notification regimes have different timelines, different content requirements, and different thresholds. GDPR Article 33 requires notification within 72 hours of becoming aware of a breach likely to result in risk to data subjects. The AI Act incident reporting timeline is not identical, and the AI Office is not a data protection authority. Providers should establish procedures that can trigger both notification streams when an incident affects personal data.

Third-Country AI Providers: The Authorized Representative Bridge

Third-country providers that place high-risk AI systems or GPAI models on the EU market must appoint an EU authorized representative. This requirement is not a formality. It is a statutory precondition for lawful market access, and it creates a compliance architecture that links AI Act obligations to GDPR enforcement mechanisms.

Mandatory Appointment Requirements

Article 22 requires providers of high-risk AI systems established outside the EU to appoint an authorized representative before placing a system on the EU market. Article 54 imposes the same requirement on providers of GPAI models established outside the EU. The representative must be established in the EU and must accept a written mandate empowering it to perform specified tasks on the provider’s behalf. [Verified: June 2026]

The representative’s location matters for GDPR purposes. If the provider is subject to GDPR Article 3(2) because it offers goods or services to EU data subjects or monitors their behavior, the provider must also appoint a GDPR representative under Article 27. The GDPR representative and the AI Act representative may be the same entity, but the legal bases are distinct. GDPR Article 27 requires the representative to facilitate communication with data protection authorities and data subjects. The AI Act representative’s functions are broader and more technical, encompassing verification of conformity documentation, retention of technical records, and cooperation with market surveillance authorities.

Representative’s Data-Related Obligations

The authorized representative must verify that the provider’s technical documentation includes data governance records required by Article 10. For high-risk systems, this means confirming that the provider has documented dataset origins, collection processes, preparation operations, bias detection measures, and gap analyses. For GPAI models, the representative must verify that the provider has maintained the technical documentation required by Article 53 and has published a training data summary in compliance with the AI Office template.

The representative must retain all documentation for ten years from the date the AI system or model is placed on the EU market or put into service. This retention period exceeds GDPR’s general documentation retention requirements and creates a long-term compliance record that market surveillance authorities can access at any time. The representative must provide all information and documentation necessary to demonstrate conformity to competent authorities upon request, including access to logs and training data documentation. [Verified: June 2026]

The representative must also cooperate with authorities on any action taken to eliminate or mitigate risks posed by the AI system. This includes providing access to source code under Article 74(13) if necessary for conformity assessment, and facilitating access to training, validation, and testing datasets under Article 74(12), including through APIs or remote access. The GDPR intersection here is significant: when authorities access personal data under AI Act powers, the access must still respect GDPR data subject rights. The representative should have procedures for handling such requests that distinguish between AI Act market surveillance access and GDPR data subject access requests.

Penalty Structure

The AI Act penalty framework is tiered by violation type. Article 99 establishes the following maximum penalties: [Verified: June 2026]

These penalties apply independently of the GDPR enforcement framework. A provider that unlawfully transfers personal data for AI training while also failing to comply with AI Act data governance obligations may face enforcement under both legal regimes where the relevant requirements have been infringed. GDPR Article 83 permits administrative fines of up to €20 million or 4% of total worldwide annual turnover for certain infringements, including violations of the international transfer rules. The AI Act establishes its own administrative penalty regime under Article 99. While organizations may be subject to enforcement under both frameworks, the level and interaction of any penalties will ultimately depend on the facts of the case, the applicable legal provisions, and the decisions of the competent authorities.

The authorized representative has specific statutory responsibilities under the AI Act that are separate from the provider’s own compliance obligations. While primary responsibility for compliance remains with the provider, representatives that fail to fulfil their own legal duties—such as retaining required documentation or cooperating with competent authorities—may themselves become subject to enforcement under the applicable legal framework. Organizations selecting representatives should verify that the representative has both the technical capacity to review AI Act documentation and the legal capability to engage effectively with market surveillance authorities and, where relevant, data protection authorities.

Practical Compliance Framework: Mapping Transfers to AI Obligations

The overlap between GDPR Chapter V and AI Act data governance is not a theoretical compliance problem. It is an operational architecture problem that affects data flow design, vendor selection, cloud infrastructure choices, and documentation systems. Organizations need a framework that treats both frameworks as simultaneous constraints, not sequential compliance tasks. The following six-step approach maps the operational decisions required to satisfy both regimes.

Step 1 — Classify the AI System by Risk Tier

Risk classification under the AI Act determines which data governance obligations apply and, by extension, which data flows must be documented and controlled. The classification is not optional self-assessment. It is a statutory determination with direct consequences for conformity assessment, market access, and penalty exposure.

Prohibited AI practices under Article 5 include social scoring by public authorities, real-time remote biometric identification in publicly accessible spaces by law enforcement (with narrow exceptions), emotion recognition in workplaces and educational institutions, and AI systems that exploit vulnerabilities of specific groups. These systems cannot be placed on the EU market regardless of data governance quality. [Verified: June 2026]

High-risk systems under Annex III trigger Article 10 data governance obligations. General-purpose AI models trigger Article 53 obligations. Systems with limited risk—such as chatbots and deepfakes—trigger transparency obligations under Article 50 but not Article 10 data governance. Minimal risk systems have no specific obligations. The classification decision should be documented with legal reasoning, because misclassification carries penalty risk under Article 99 for supplying incorrect information.

For data transfer purposes, the risk tier determines what data must be inventoried. A minimal-risk system may require no AI Act data governance documentation, but if it processes EU personal data transferred to a third country, GDPR Chapter V still applies. A high-risk system requires both GDPR transfer documentation and AI Act data governance records. The classification step therefore defines the scope of the compliance effort.

Step 2 — Inventory All Data Flows in the AI Lifecycle

Organizations must map every instance where personal data moves across the EEA border during the AI lifecycle. This includes training data transfers, validation data transfers, testing data transfers, inference data flows, feedback loop data, and model update data. The inventory must identify: the data category (personal data, special category data, anonymized data, synthetic data); the EEA origin jurisdiction; the destination jurisdiction; the transfer mechanism currently in place (adequacy, SCCs, BCRs, derogation); the AI Act risk tier of the system using the data; and the purpose of the transfer within the AI lifecycle.

The EDPB Europrivacy certification criteria require organizations to map all personal data flows and document the transfer mechanisms applied to each. While Europrivacy certification is voluntary, the mapping methodology it prescribes provides a structured approach that aligns with both GDPR Article 30 records and AI Act Article 10 documentation requirements. Organizations can adapt this framework without pursuing certification. [Verified: April 2026]

A critical inventory gap that organizations frequently miss is the distinction between data transfers for training and data transfers for inference. Training data transfers are typically bulk, one-time or periodic transfers that occur before deployment. Inference data transfers occur in real time or near-real time during system operation and may involve personal data inputs from EU users being sent to third-country servers for processing. Both require GDPR Chapter V mechanisms, but the SCC modules and TIA factors differ. Inference data flows often use Module 1 (controller-to-controller) or Module 3 (processor-to-processor), while training data flows more commonly use Module 2 (controller-to-processor).

Step 3 — Select and Document Transfer Mechanisms with AI-Specific Annexes

For each cross-border flow involving personal data, the organization must select a GDPR Chapter V mechanism. The selection hierarchy is statutory: adequacy decisions first, then SCCs or BCRs, then derogations only where the other mechanisms are unavailable. The selection is not merely a legal formality. It determines what documentation the organization must maintain, what oversight it will face, and what data subject rights apply.

When SCCs are the selected mechanism, the organization must ensure that the Annex I description of processing activities reflects AI-specific purposes and risks. The description should state the specific AI system or model being trained, the type of model (supervised, unsupervised, reinforcement learning, generative), the intended use case, and the geographical scope of deployment. Vague descriptions such as “data processing for research” or “machine learning development” do not satisfy GDPR Article 5(1)(b) purpose limitation or AI Act Article 10(2)(b) origin documentation requirements.

The Annex II security measures must address AI-specific threats. Standard encryption, access control, and audit logging are necessary but not sufficient. The security annex should specify: measures to prevent model inversion attacks that reconstruct training data from model outputs; measures to prevent membership inference attacks that determine whether an individual’s data was in the training set; measures to prevent data reconstruction from gradient updates in distributed or federated training; and measures to ensure that special category data processed under Article 10(5) cannot be accessed by cloud provider personnel or subprocessors. These measures should be described in sufficient technical detail to satisfy both GDPR Article 32 security requirements and AI Act Article 10 technical documentation standards.

The TIA must include AI-specific factors that standard assessments omit. The assessment should examine whether the destination country’s surveillance laws permit government access to AI training environments, model weights, or inference logs. It should assess whether the technical infrastructure supports the security measures described in Annex II. It should evaluate whether the recipient’s data governance practices align with AI Act Article 10 requirements, particularly for high-risk systems. A recipient that cannot demonstrate Article 10-compliant data governance may undermine the SCC protections even if the recipient’s general data protection practices are sound.

Step 4 — Align AI Act Data Governance with GDPR Records

AI Act Article 10(2)(b) requires documentation of “the origin of data, and in the case of personal data, the original purpose of the data collection.” This provision creates an opportunity for unified documentation. The records maintained under AI Act Article 10 can serve as the foundation for GDPR Article 30 records of processing, provided they include the additional elements GDPR requires: categories of data subjects, categories of personal data, recipients of the data, transfers to third countries and the documentation of those transfers, and time limits for erasure.

Organizations should design a single data governance documentation system that satisfies both frameworks. The system should capture: dataset identifiers and versions; data source URLs or database references; collection dates and methods; original collection purposes and lawful bases; GDPR transfer mechanisms and TIA references; AI Act risk classification and conformity assessment references; bias detection measures and results; special category data flags and Article 10(5) compliance records; retention schedules and deletion confirmations; and access logs and authorization records.

This unified approach reduces duplication, minimizes inconsistency risk, and creates a defensible audit trail. When market surveillance authorities request data governance documentation under Article 74(12), the organization can produce records that also satisfy GDPR supervisory authority inspection requirements. When data subjects exercise access rights under GDPR Article 15, the organization can trace their data through the AI lifecycle using the same documentation system.

Step 5 — Implement Special Category Data Restrictions

If bias detection requires special category data under Article 10(5), the organization must implement controls that prevent cross-border transfer. The prohibition in Article 10(5)(d) is categorical: the data must not be transmitted, transferred, or accessed by other parties. This means the data cannot be stored in cloud environments with data centers outside the EEA. It cannot be processed by third-country subcontractors. It cannot be accessed by offshore development teams. It cannot be included in datasets shared with research collaborators outside the EU.

The organization must first confirm that synthetic or anonymized data cannot achieve the same bias detection objective. This confirmation should be documented with technical evidence, not asserted. If synthetic data is technically feasible, Article 10(5) does not apply, and the organization should use synthetic data to avoid GDPR Article 9 complexity. If synthetic data is not feasible, the organization must implement: pseudonymization that meets GDPR Recital 26 standards; state-of-the-art encryption for data at rest and in transit within the EEA; strict access controls limiting access to personnel with a direct need for bias detection; audit logging of all access; and deletion procedures that remove the data once bias is corrected or the maximum retention period expires.

The records of processing must document why the exception was necessary. This documentation should include: the specific bias being detected; the technical reasons synthetic or anonymized data was insufficient; the measures implemented to protect the data; the retention period; and the deletion confirmation. These records serve both AI Act conformity assessment and GDPR accountability requirements.

Step 6 — Prepare for Market Surveillance and Data Subject Access

Article 74(12) grants market surveillance authorities the power to access training, validation, and testing datasets, including through APIs or remote access. Article 74(13) allows access to source code if necessary for conformity assessment. These powers are not limited by GDPR data subject rights, but they do not override them either. When authorities access personal data under AI Act powers, the data subject rights under GDPR Articles 15-22 still apply. [Verified: June 2026]

Organizations should establish procedures that distinguish between AI Act market surveillance access and GDPR data subject access requests. Market surveillance access may be broad and technical, focusing on dataset composition, model architecture, and conformity documentation. Data subject access requests are individual-specific and focused on the data subject’s own personal data. The procedures should specify: who receives each type of request; what documentation is produced for each; how personal data is redacted or aggregated when produced for market surveillance; how the organization logs the disclosure for GDPR Article 30 records; and how the organization notifies data subjects if the disclosure triggers a GDPR Article 33 breach notification.

The authorized representative plays a central role in these procedures. The representative receives market surveillance requests, verifies that the requested documentation is complete, and coordinates the provider’s response. The representative should have technical staff capable of understanding AI system documentation and legal staff capable of assessing GDPR implications. A representative that lacks either capacity creates compliance risk for the provider.

The Digital Omnibus Proposal: What Changes for AI Data Compliance

The Digital Omnibus proposal, formally titled the “Omnibus Simplification Package,” was published by the European Commission on 19 November 2025. It proposes amendments to the AI Act, the GDPR, and other digital regulations with the stated goal of reducing administrative burden. The proposal’s status is critical for AI data compliance planning because it contains provisions that would modify both GDPR data processing rules and AI Act data governance obligations. [Verified: June 2026]

Current Status

The European Council and European Parliament reached a provisional agreement on 7 May 2026. The European Parliament formally endorsed the provisional agreement on 16 June 2026. The proposal still requires formal adoption by the Council of the European Union and publication in the Official Journal of the European Union before it enters into force. Anticipated formal adoption is July 2026. Until formal adoption occurs, the original AI Act deadlines and GDPR provisions remain in force. [Verified: June 2026]

The timing matters for compliance planning. The original AI Act deadline for high-risk system obligations is 2 August 2026. If the Omnibus is not formally adopted and published before that date, the original deadline applies regardless of the provisional agreement. Organizations that have deferred compliance preparation based on the Omnibus timeline risk missing the 2 August 2026 deadline. The provisional agreement is not law. Only formal adoption creates legal effect.

Proposed Changes Affecting AI Data

The provisional agreement contains several provisions that would modify AI data compliance if adopted. The most significant for this article is the proposed deferral of high-risk AI system obligations from 2 August 2026 to 2 December 2027. This deferral would apply to most high-risk categories under Annex III, though not to all. Organizations should verify whether their specific high-risk category is covered by the deferral before adjusting timelines. [Verified: June 2026]

The GPAI model obligations that took effect on 2 August 2025 and the prohibited practices that took effect on 2 February 2025 are not deferred. Providers of GPAI models and deployers of prohibited systems must continue current compliance regardless of Omnibus adoption.

The Omnibus also proposes amendments to GDPR provisions that affect AI data processing. The most consequential proposed change would clarify that legitimate interest is a valid legal basis for processing personal data for AI training, subject to a balancing test. This addresses a long-standing uncertainty in GDPR interpretation, where some supervisory authorities have questioned whether AI training can satisfy the necessity and proportionality requirements of Article 6(1)(f). If adopted, the amendment would provide legal certainty for organizations that rely on legitimate interest for training data processing, though the balancing test would still require documentation and the right to object would still apply. [Verified: June 2026]

The proposal also introduces new exceptions for processing sensitive data in AI contexts. One proposed exception would permit processing of special category data for bias detection under broader conditions than Article 10(5) currently allows. Another would permit incidental processing of special category data in training datasets without requiring explicit consent, provided the data is not the primary processing purpose and appropriate safeguards apply. These proposed exceptions have drawn significant criticism from data protection authorities and may be modified before final adoption.

EDPB and EDPS Position

The EDPB and EDPS Joint Opinion 2/2026, published on 10 February 2026, assessed the Digital Omnibus proposal. The opinion supported the goal of reducing administrative burden but raised substantial concerns about the proposed changes to data protection rules. The authorities warned that the proposed exceptions for sensitive data processing in AI training would “materially reduce” the level of data protection in the EU. They noted that the proposed legitimate interest clarification for AI training could undermine the rights of data subjects if not accompanied by strengthened transparency and objection mechanisms. [Verified: June 2026]

The Joint Opinion does not bind the legislators, but it carries institutional weight. The European Parliament’s endorsement of the provisional agreement on 16 June 2026 suggests that some of the data protection concerns were addressed in the final negotiation, though the exact text of the adopted provisions is not yet public. Organizations should monitor the final Omnibus text for modifications to the proposed AI data processing exceptions before adjusting their compliance programs.

The practical implication for compliance teams is that the Omnibus creates planning uncertainty. Organizations should prepare for the original 2 August 2026 high-risk deadline while maintaining flexibility to adapt if the deferral to December 2027 is formally adopted. They should also prepare for the proposed GDPR changes without relying on them, since the final text may differ from the provisional agreement. The safest approach is to implement current law fully and treat Omnibus provisions as potential future simplifications, not as current compliance shortcuts.

Common Mistakes to Avoid

Organizations navigating the GDPR-AI Act intersection repeatedly make the same category of errors. These errors are not failures of legal analysis. They are failures of operational architecture—assumptions that one framework’s compliance substitutes for the other, or that familiar data protection practices automatically satisfy new AI governance requirements. The following six mistakes represent the most frequent and most consequential compliance gaps.

Mistake 1: Treating Adequacy Decisions as AI Act Exemptions

An adequacy decision under GDPR Article 45 resolves the lawfulness of a personal data transfer to the destination country. It does not resolve any AI Act obligation. A provider transferring EU personal data to an adequate jurisdiction for AI model training must still comply with AI Act Article 10 data governance if the resulting system is high-risk, and with Article 53 if the model is a general-purpose AI model. The adequacy decision covers transfer lawfulness. The AI Act covers system conformity. These are independent compliance questions.

The error manifests in vendor due diligence. An organization selects a US-based AI training provider certified under the EU-US Data Privacy Framework and assumes this certification satisfies all regulatory requirements for the training engagement. It does not. The DPF certification addresses GDPR transfer lawfulness for the personal data sent to the US provider. It does not address whether the provider maintains Article 10-compliant data governance records, whether the provider can produce the training data summary required by Article 53(1)(d), or whether the provider’s infrastructure supports the security measures required by AI Act Annex II. Due diligence must cover both frameworks separately.

Mistake 2: Conflating the AI Act Authorized Representative with the GDPR Representative

The AI Act authorized representative and the GDPR Article 27 representative are separate legal roles with separate functions, separate appointment requirements, and separate oversight relationships. The AI Act representative verifies technical documentation, retains conformity records for ten years, and cooperates with market surveillance authorities. The GDPR representative facilitates communication with data protection authorities, handles data subject requests, and supports breach notification. A single entity may perform both functions, but only if explicitly mandated for both roles.

The error occurs when organizations appoint an AI Act representative and assume GDPR Article 27 compliance is automatic. It is not. The GDPR representative mandate must specify the data processing activities, the categories of data subjects, and the supervisory authority contact points. The AI Act representative mandate must specify the AI systems or models covered, the conformity assessment procedures, and the market surveillance authority contact points. These mandates address different regulators, different documentation, and different enforcement timelines. Organizations that conflate the two roles risk gaps in both compliance programs.

Mistake 3: Transferring Special Category Data for Bias Detection Outside the EEA

Article 10(5)(d) of the AI Act prohibits the transmission, transfer, or access of special category data used for bias detection by other parties. This is not a GDPR transfer restriction that can be overcome with SCCs or an adequacy decision. It is an AI Act prohibition that applies regardless of the GDPR transfer mechanism. Organizations that outsource bias detection to third-country vendors, store bias detection datasets in multi-region cloud environments, or share special category data with offshore research collaborators are in direct violation of this provision.

The error is often unintentional. An organization implements pseudonymization and encryption for special category data used in bias detection and stores the dataset in a cloud service with data centers in Frankfurt and Virginia. The Frankfurt storage satisfies the EEA location requirement, but the cloud provider’s global replication or backup procedures may copy the data to Virginia. The organization’s contract with the cloud provider may permit the provider’s support personnel in India or the Philippines to access the data for troubleshooting. These arrangements violate Article 10(5)(d) even if the data is encrypted and pseudonymized. Organizations must verify that their infrastructure, contracts, and operational procedures prevent any cross-border movement or third-party access of special category data used for bias detection.

Mistake 4: Using Legacy Standard Contractual Clauses

The 2021 SCCs (Commission Implementing Decision 2021/914) replaced all previous versions. Legacy SCCs adopted under the 2001, 2004, and 2010 decisions should have been replaced for all ongoing transfers. Organizations that continue to rely on legacy SCCs for AI training data transfers are using an invalid transfer mechanism. This is not a technicality. The 2021 SCCs contain provisions on government access requests, data subject rights, and supplementary measures that the legacy versions lack. These provisions are essential for post-Schrems II compliance and for AI-specific transfer risks.

The error is compounded when organizations update their SCCs to the 2021 version but fail to update the Annex I description of processing activities to reflect AI-specific purposes and risks. A 2021 SCC with a generic Annex I description that does not specify the AI system, the model type, or the intended use case fails both GDPR purpose limitation requirements and AI Act Article 10(2)(b) origin documentation requirements. The SCC update must include a full re-examination of the processing description, the security measures, and the TIA.

Mistake 5: Conducting Transfer Impact Assessments Without AI-Specific Factors

The TIA is not a generic data protection exercise. It is a jurisdiction-specific, risk-specific assessment of whether the destination country’s law and practice undermine the SCC protections. For AI data transfers, standard TIA templates miss factors that are specific to AI systems and that determine whether the transfer is lawful.

A standard TIA may assess whether the destination country’s surveillance laws permit government access to stored data. It may not assess whether those laws permit access to AI model weights, training logs, or inference records. It may assess whether the recipient has adequate information security certifications. It may not assess whether the recipient’s training environment supports protections against model inversion attacks or membership inference. It may assess whether the recipient has a data protection officer. It may not assess whether the recipient maintains AI Act Article 10-compliant data governance documentation. Organizations must adapt their TIA procedures to include AI-specific risk factors, or their assessments will be incomplete and potentially invalid.

Mistake 6: Deferring Compliance Preparation Pending Digital Omnibus Adoption

The Digital Omnibus provisional agreement has created a compliance deferral reflex. Organizations see headlines about the proposed deferral of high-risk AI obligations to December 2027 and delay their Article 10 preparation. This is a mistake for two reasons. First, the Omnibus is not law. The provisional agreement reached on 7 May 2026 and endorsed by Parliament on 16 June 2026 still requires formal Council adoption and publication in the Official Journal. Until that occurs, the original 2 August 2026 deadline remains in force. Second, even if the Omnibus is adopted, the GPAI model obligations (August 2025) and prohibited practices (February 2025) are not deferred. Organizations with GPAI models are already subject to Article 53 data governance and training data summary requirements. [Verified: June 2026]

The error is particularly costly for organizations that have not yet appointed an authorized representative. If the Omnibus is not formally adopted before 2 August 2026, providers of high-risk AI systems must have an EU authorized representative in place by that date. The appointment process involves legal review, mandate negotiation, and operational onboarding. Organizations that wait for Omnibus certainty may miss the deadline and face market access restrictions.

Why Documentation Discipline Is Becoming the Core Governance Test

The intersection of GDPR Chapter V and AI Act data governance is not a temporary regulatory friction. It is a structural feature of the EU’s emerging AI accountability architecture. Organizations that treat this intersection as a compliance puzzle to be solved once will find themselves out of position as enforcement intensifies, market surveillance authorities gain operational capacity, and the Digital Omnibus—whether adopted in its current form or modified—adds new layers of obligation. The organizations that will manage this environment successfully are those that build documentation systems capable of serving multiple regulators, multiple frameworks, and multiple audit contexts from a single source of truth.

Immediate Actions: 30-Day Window

Organizations should begin with a system and data inventory that captures both GDPR and AI Act dimensions. The inventory must classify every AI system by AI Act risk tier, identify every cross-border personal data flow in the AI lifecycle, and flag any special category data used for bias detection. This is not a legal review. It is an operational mapping exercise that reveals where the two frameworks apply to the same data, the same systems, and the same vendor relationships. The inventory should be completed within 30 days and should be owned by a cross-functional team with authority from legal, engineering, and compliance functions.

During this window, organizations should also verify their authorized representative status. Third-country providers of GPAI models are already required to have an EU representative under Article 54. Providers of high-risk systems must have a representative in place by 2 August 2026 unless the Digital Omnibus deferral is formally adopted. The representative appointment process involves legal mandate negotiation, operational onboarding, and documentation handover. Waiting for Omnibus certainty is not a viable strategy. Organizations should proceed with appointment now and adjust timelines only after formal adoption.

Short-Term Actions: 90-Day Window

Within 90 days, organizations should audit their Standard Contractual Clauses for AI-specific adequacy. This audit should examine whether the Annex I description of processing activities specifies the AI system, model type, and intended use case with sufficient precision to satisfy both GDPR purpose limitation and AI Act origin documentation. It should verify that Annex II security measures address AI-specific risks including model inversion, membership inference, and data reconstruction from gradient updates. It should confirm that the TIA includes jurisdiction-specific assessments of government access to AI training environments, model weights, and inference logs.

Organizations should also conduct Transfer Impact Assessments for all non-adequate transfers involving AI training data. Many organizations conducted TIAs for general data transfers after Schrems II but have not updated those assessments to reflect AI-specific risks. The TIA should be treated as a living document that is revised when the AI system changes, when the training data expands, or when the destination country’s legal environment shifts. The algorithmic bias auditing frameworks that organizations use for AI Act Article 10 compliance can inform the TIA by identifying which datasets contain special category data and which bias detection measures require heightened protection. [Verified: June 2026]

The 90-day window is also the appropriate timeframe for reviewing cloud infrastructure contracts. Organizations that store AI training data in multi-region cloud environments should verify that special category data used for bias detection under Article 10(5) is physically and logically restricted to EEA data centers. This requires more than selecting a European region in a cloud console. It requires contractual prohibitions on global replication, backup, and support access that could move the data outside the EEA. The contract should specify that the cloud provider’s personnel outside the EEA cannot access the data, and that the provider’s subprocessors are subject to the same restriction.

Medium-Term Actions: Before 2 August 2026

Organizations should implement unified data governance documentation that serves both GDPR and AI Act requirements. The documentation system should capture dataset identifiers, source references, collection purposes, lawful bases, transfer mechanisms, TIA references, risk classifications, bias detection measures, special category data flags, retention schedules, and access logs in a single structured format. This unified approach reduces duplication, minimizes inconsistency, and creates a defensible audit trail that satisfies both data protection supervisory authorities and AI Act market surveillance authorities.

The unified documentation system should also support the cross-jurisdictional compliance requirements that organizations face when operating under EU, US, and other regulatory frameworks simultaneously. A documentation system designed only for GDPR and AI Act compliance will require retrofitting when NIST AI RMF obligations, OECD AI Principles implementation, or other national AI governance frameworks impose additional data governance requirements. The system should be architected for multi-framework compliance from the outset. [Verified: June 2026]

Organizations should establish procedures for handling market surveillance access requests under Article 74(12) and (13). These procedures must distinguish between AI Act market surveillance access, which may be broad and technical, and GDPR data subject access requests, which are individual-specific. The procedures should specify how personal data is redacted or aggregated when produced for market surveillance, how the disclosure is logged for GDPR Article 30 records, and how the organization assesses whether the disclosure triggers a GDPR Article 33 breach notification. The authorized representative should be trained on these procedures and should have the technical capacity to execute them.

Ongoing Monitoring Requirements

Organizations must monitor three regulatory streams that will shape the GDPR-AI Act intersection over the next 18 months. First, the formal adoption and publication of the Digital Omnibus, which will determine whether high-risk obligations are deferred to December 2027 and what GDPR amendments affect AI training data processing. Second, EDPB guidance on the interplay between AI Act data governance and GDPR data protection principles, which is likely to emerge as market surveillance authorities begin exercising their powers. Third, AI Office template updates for GPAI model training data summaries, which may impose additional disclosure requirements or modify existing ones.

Organizations should also evaluate AI governance tooling that can automate data flow mapping, documentation generation, and compliance monitoring. Manual documentation systems are not sustainable at the scale required by both frameworks. Tools that integrate data inventory, risk classification, transfer mechanism tracking, and audit logging into a single platform reduce human error and create real-time compliance visibility. The selection criteria for such tools should include: support for GDPR Article 30 records and AI Act Article 10 documentation in a unified format; automated TIA workflow management; special category data flagging and access restriction enforcement; and integration with cloud infrastructure APIs to verify data residency. [Verified: June 2026]

The Forward Trajectory

The EU’s regulatory trajectory is toward integrated accountability, not parallel compliance silos. The Digital Omnibus proposal, whatever its final form, reflects a legislative intent to reduce administrative duplication while maintaining fundamental rights protection. The mechanism for achieving this integration is documentation. Regulators in both the data protection and AI oversight domains are converging on a common expectation: that organizations can produce, on demand, a complete, accurate, and auditable record of how data was collected, where it moved, how it was used, and what protections applied at each stage.

This expectation is not satisfied by legal opinions or policy statements. It is satisfied by technical systems that capture data provenance, enforce access controls, log transfers, and generate compliance documentation automatically. The organizations that invest in these systems now will face the enforcement environment of 2027 and beyond from a position of strength. Those that continue to treat GDPR and AI Act compliance as separate legal exercises managed through spreadsheets and email approvals will find that the gap between their documentation capacity and regulatory expectation has become a liability.

The penalty structure makes this a board-level concern. The cumulative exposure under GDPR Article 83 and AI Act Article 99 reaches €55 million or 11% of global turnover for a single data transfer violation that also breaches high-risk system obligations. For large technology providers, this is not a compliance cost. It is an existential risk. The compliance investment required to avoid it—unified documentation, representative appointment, TIA updates, and infrastructure controls—is modest by comparison. The question is not whether organizations can afford to build this capability. It is whether they can afford not to.