While article 5's banned-practices list gets most of the current attention, it's not what will occupy most compliance teams' time over the coming years.
That would be Article 10: training, validation, and testing data for high-risk AI systems has to be relevant, sufficiently representative, and, to the best extent possible, free of errors and complete. In practice, this is one of the hardest provisions in the regulation to satisfy, but also exactly where we at Calibrion spend most of our time: the intersection of data science, AI engineering, evaluation, and legal obligations.
The revised timeline for compliance
In November 2025, the European Commission proposed the Digital Omnibus to simplify implementation of the AI Act and allow more time to complete the technical standards for high-risk systems. Adopted in July 2026 as Regulation (EU) 2026/1744, it set new application dates for those requirements:
- High-risk obligations for standalone systems (recruitment tools, credit scoring) moved from 2 August 2026 to 2 December 2027.
- High-risk obligations for AI in already-regulated products (medical devices, machinery) moved to 2 August 2028.
- GPAI provider obligations and Article 50 transparency obligations weren't touched at all, in force since 2 August 2025 and 2 August 2026 respectively.
The wider regulatory framework continued to develop. The EU approved the Council of Europe’s Framework Convention on AI, the first legally binding international treaty in this field. It will enter into force for the EU on 1 September 2026, while the UK, US, and Japan are among its signatories. In July 2026, CEN and CENELEC published EN 18286, a quality-management standard designed to support implementation of the AI Act.
A 2026 EU AI Act Readiness Report by Vision Compliance, based on assessments of its clients across eight industries, found:
- 78% of organizations have taken no meaningful steps toward AI Act compliance
- 83% have no formal inventory of the AI systems they actually deploy
- 61% have no process for producing required technical documentation
For most companies, the immediate risk comes from delaying preparation for rules that are already in force.
What the Act requires
Article 5 bans a short list of practices outright, no documentation or mitigation plan makes them legal: manipulative AI, exploiting vulnerable groups, social scoring, untargeted face-scraping, emotion recognition at work or school. Enforceable since February 2025, fines can reach €35 million or 7% of global turnover, the highest tier in the regulation. Most product teams will never come close to it, but it's worth a five-minute check on any new initiative.
Articles 9–15 are the operational core for anything high-risk: recruitment tools, credit and insurance decisioning, safety components in regulated products, and a growing list of Annex III use cases:
| Article | What it actually requires |
|---|---|
| Art. 9 | Continuous risk management across the system's whole life, not a one-time sign-off |
| Art. 10 | Training, validation, and testing data that is relevant, representative, and checked for bias |
| Art. 11 | Technical documentation that exists before market entry and stays current |
| Art. 12 | Automatic event logging across the system's lifecycle |
| Art. 13 | Clear instructions to whoever deploys the system: capabilities, limits, accuracy |
| Art. 14 | Human oversight that actually works: someone who can understand, override, and stop the system |
| Art. 15 | Resilience against errors, adversarial input, and data poisoning |
For teams building AI models, this table should be read as a checklist for engineers, not a legal memo: each article maps to a buildable artefact. Teams that treat this as paperwork will most probably fail at their first audit; teams that treat it as infrastructure will pass.
A little bit down the list, Article 50 sets specific transparency duties. People must be told when they are interacting directly with AI unless that is already obvious. Providers of systems that generate synthetic content must make the output machine-readable and detectable, while companies using such systems must disclose deepfakes and certain AI-generated text on matters of public interest. These duties have applied since 2 August 2026.
Why Article 10 is the hardest provision, and where the work actually happens
The standards Article 10 sets are near impossible to fully satisfy, and the drafters seem to know it: the text says "to the best extent possible," not "guarantee error-free data." Why is it hard to satisfy? Three reasons: no real-world dataset is error-free or perfectly representative (you can only measure the gap and manage it, which is what Article 10's bias-testing requirement, itself rooted in EU non-discrimination law two decades older than the Act, asks you to do); most companies build on foundation models they didn't train, so there's zero or little visibility into the provider's data, shifting the question from auditing input to testing output; and compliance isn't a one-time event — when models get retrained the analysis should run again.
The 78% figure above is mostly due to shortage of a technical capability, since most AI Act commentary is written by lawyers describing a legal text, not AI practitioners describing how to satisfy it. However, many of these are highly technical issues:
- Meeting Article 10 requires data quality checks and data evaluation that profile datasets and identify skew across protected attributes before training. Or using synthetic data to improve coverage without using personal data.
- Articles 15 and 9 require continuous evaluation using custom evaluators, statistical tests, ML models, or LLM judges.
- For RAG systems, Article 13's transparency depends on retrieval architecture decided months before the documentation gets written: a model can only give a grounded answer if it pulls from a well-governed source.
A note on Article 14: applying human oversight to AI agents
Article 14 requires effective human oversight of high-risk AI systems. For agents that browse, call tools, and take several actions in sequence, oversight usually involves more than approving individual outputs. The controls should reflect what the agent can do and the consequences of an error.
Useful controls include least-privilege access, clear limits on permitted actions, session logs, escalation rules, and a tested way to stop the agent. Higher-risk or irreversible actions need stricter controls. We use these principles in our agent work at Calibrion. Singapore's Model Governance Framework for Agentic AI, published in January 2026, recommends a similar approach.
How Data Lab supports Article 10
Article 10 asks providers of high-risk AI systems to examine the data used for training, validation, and testing. They need to understand where the data came from, whether it is suitable for the intended use, where it may contain errors or bias, and what they did about any shortcomings they found.
Calibrion Data Lab supports the technical part of that work. It can examine a dataset for imbalance, missing coverage, anomalies, duplicates, corruption, train–test leakage, and possible bias. The findings can then be used to remove unsuitable records, repair recoverable errors, or add examples where important cases are underrepresented.
| What Article 10 asks for | How Data Lab can help |
|---|---|
| Data that is relevant and sufficiently representative for its intended use | Distribution and coverage analysis shows which groups, cases, or regions of the dataset are overrepresented or missing |
| Examination for errors and possible bias | Statistical checks and task-specific evaluators flag anomalies, imbalance, duplication, leakage, and other potential problems for review |
| Measures to address gaps and shortcomings | Flagged data can be filtered or repaired, and new examples can be added to close specific coverage gaps |
| Data governance and documentation | The resulting report records provenance, diagnostics, evaluator results, expert-review decisions, and the transformations made to the dataset |
This does not make a system compliant by itself. The provider still has to define the system's intended purpose, decide which risks and groups are relevant, and meet the Act's legal and governance requirements. Data Lab provides evidence and practical tools for the dataset work behind that assessment.
Getting Started: start with one dataset
Article 10 is difficult because there is no universal definition of a good dataset. What counts as relevant or representative depends on what the system is meant to do, who it affects, and where it will be used.
A useful first step is to take one important training or evaluation dataset and write down what it needs to represent. Then examine where the data falls short, decide which gaps matter, and keep a record of what was changed.
This will not remove every uncertainty or settle the legal assessment. It does, however, turn a broad compliance requirement into work that a technical team can begin.