If your organisation uses third-party data to train, fine-tune, or evaluate AI models, the EU Data Use and Access Act (DUAA) 2025 has changed your compliance obligations significantly. Unlike GDPR, which focuses on personal data processing, DUAA introduces a separate framework specifically targeting how data flows into AI systems — including the provenance, consent, and anonymisation standards that apply before a dataset ever touches a training pipeline.
The enforcement window opened in Q1 2026. Penalties follow the GDPR model: up to 4% of global annual turnover for material violations. And unlike early GDPR enforcement, regulators have signalled they will not extend grace periods for AI data practices given the pace of market adoption.
What DUAA 2025 Actually Requires
The Act establishes obligations across three main areas for organisations acquiring or supplying data for AI purposes:
1. Data provenance disclosure (Article 12)
Any dataset used to train, validate, or test an AI system that will be deployed in the EU must have documented provenance. This means tracing data back to its original source — not just the intermediary vendor who sold it to you. If you purchased a dataset from a data broker, you are responsible for obtaining that broker's chain-of-custody documentation, including the original collection basis and any subsequent processing steps.
The practical implication: "we bought it from a reputable vendor" is not a defence. Your compliance team needs supplier agreements that include provenance warranties and audit rights.
2. Lawful basis and consent records (Articles 14–17)
Where a dataset contains or was derived from data about natural persons, DUAA requires that the original lawful basis for processing is documented and remains valid at the time of AI training. Consent obtained under pre-GDPR terms, or consent that has expired or been withdrawn, does not satisfy DUAA's requirements even if the data appears fully anonymised at the time of training.
DUAA treats AI training as a distinct "further processing" purpose. Even if data was originally collected with broad consent, you cannot assume that consent covers AI model training without an explicit assessment of compatibility under Article 15 — or without re-establishing a new lawful basis.
3. Anonymisation standards (Article 19)
DUAA codifies anonymisation requirements that were previously left to member-state interpretation. For AI training data, the Act requires that PII is removed to a standard that makes re-identification "reasonably impossible" given the compute and data access available at the time of use. This is a higher bar than traditional k-anonymity in datasets where external re-identification vectors exist.
The Article 19 technical annex specifies acceptable anonymisation techniques by data type:
| Data Category | Minimum Standard | Status |
|---|---|---|
| Direct identifiers (name, NI, passport) | Removal or pseudonymisation with separate key storage | Required |
| Quasi-identifiers (age, postcode, profession) | k-anonymity (k≥5) or differential privacy (ε≤1.0) | Required |
| Behavioural / transactional data | Aggregation or differential privacy | Required |
| Fully synthetic data (no original PII) | Documented generation methodology | Compliant |
Cross-Border Considerations
DUAA's extraterritorial scope mirrors GDPR's. If the AI system will be offered to EU users, the data compliance requirements apply regardless of where training takes place. US and UK-based organisations training models on EU-origin datasets are within scope — and the Act explicitly catches training that occurs outside the EU where the resulting model is deployed within it.
For cross-border data transfers used in AI training, standard contractual clauses (SCCs) must be updated to include DUAA-specific data processing annexes. The European Data Protection Board published updated template language in March 2026 — existing SCCs that predate this update are considered non-compliant for AI training purposes.
How Organisations Need to Prepare
Compliance is a multi-step process. Most organisations are at different stages depending on how mature their data procurement and governance practices are. Here's a practical starting point:
- Audit your current training datasets. Identify every dataset used in production models and fine-tuning runs. For each, establish whether provenance documentation exists and whether the original lawful basis remains valid.
- Stress-test your anonymisation. Run your existing datasets through a DUAA-compliant PII assessment. Many datasets that passed GDPR scrutiny will fail Article 19's tighter standard, particularly behavioural and financial datasets where quasi-identifier combinations create re-identification risk.
- Update supplier contracts. Require provenance warranties, audit rights, and DUAA compliance representations from all data vendors. Treat data procurement like software licensing — due diligence before purchase, not after.
- Document your anonymisation methodology. Regulators will ask for it. For each dataset, maintain a record of what technique was applied, by whom, and what the assessed re-identification risk was at the time of processing.
- Establish a data lineage trail. If a model is later challenged, you need to demonstrate not just that the data was compliant when acquired, but that it remained compliant through every processing step into the training pipeline.
Where Most Organisations Are Getting It Wrong
The most common gap we see is treating DUAA compliance as a one-time procurement check rather than a continuous operational process. Data that is compliant at purchase can become non-compliant if consent is withdrawn upstream, if the dataset is re-processed in ways that degrade anonymisation, or if it's combined with other datasets in ways that create new re-identification risk.
The second gap is documentation. Most teams can explain what they anonymised; very few can produce the chain-of-custody record that shows how anonymisation was applied, verified, and maintained. This is precisely what DUAA enforcement will focus on.
Finally, many organisations are still treating AI training data governance as a purely technical problem rather than a legal and technical one. The anonymisation and provenance requirements in DUAA require legal sign-off on methodology, not just engineering implementation. Compliance and data engineering teams need to work together from the point of dataset selection, not just at the point of deployment.
What Compliant Data Infrastructure Looks Like
Building for DUAA compliance is not primarily about buying different data — it's about building the systems to verify, document, and maintain compliance across the full data lifecycle. That means automated PII detection and anonymisation at ingestion, provenance metadata attached to every dataset at source, consent validity checking against live records, and lineage tracking that follows data through every processing step.
Organisations that build this infrastructure now will have a structural advantage as regulatory requirements continue to tighten. Those that don't will face the same scramble GDPR created — expensive retroactive remediation, rushed data audits, and the risk of having to retire non-compliant datasets from production models under time pressure.
The data marketplace model is increasingly how forward-thinking organisations are addressing this: sourcing pre-verified, provenance-documented datasets from suppliers who have already done the compliance work, rather than buying raw data and inheriting the compliance burden internally.