What Annex III providers must actually build to meet the risk management, data governance, documentation, oversight and robustness requirements before the December 2027 deadline.
Educational content, not legal advice. AI regulation is fast-moving and jurisdiction-specific. Verify every obligation and deadline against the primary legal text and consult qualified counsel before making compliance decisions. Accurate as of the research date shown in the metadata below.Who this applies to, and by when
The EU AI Act's heaviest substantive obligations fall on providers of high-risk AI systems. Annex III lists the standalone high-risk use cases: biometric identification and categorisation, safety components of critical infrastructure, education and vocational training, employment and worker management (including CV-screening and hiring tools), access to essential private and public services (such as credit scoring and life/health insurance risk assessment), law enforcement, migration and border control, and administration of justice and democratic processes.
The compliance clock moved. Under the 2026 Digital Omnibus on AI, adopted by the Council on 29 June 2026, the application date for Annex III standalone high-risk systems was deferred from 2 August 2026 to 2 December 2027. High-risk AI embedded as a safety component of products already regulated under EU harmonisation law (Annex I, e.g. medical devices, machinery, toys) moved from 2 August 2027 to 2 August 2028. Teams now have more runway, but the engineering lift below has not shrunk.
Deadlines are not the whole story. If your product is also a chatbot, a content generator, or a deepfake tool, the Article 50 transparency duties still apply from 2 August 2026 regardless of the high-risk deferral. Do not let the 2027 date lull a chatbot team into thinking nothing is due next year.The seven requirements at the heart of Chapter III, Section 2
Articles 8 to 15 define the requirements a high-risk system must meet. Article 8 is the umbrella clause: requirements apply across the lifecycle, must account for the system's intended purpose and the generally acknowledged state of the art, and where a system falls under both the AI Act and other EU harmonisation law, providers may integrate the documentation to avoid duplication. Articles 9 through 15 are the substantive obligations.
Article 9 — Risk management system
A continuous, iterative risk management process that runs across the entire lifecycle, not a one-time assessment. You must identify and analyse known and reasonably foreseeable risks to health, safety and fundamental rights; estimate risks from intended use and reasonably foreseeable misuse; evaluate risks from post-market monitoring data; and adopt targeted mitigation measures. Residual risk must be judged acceptable. Where the system may be accessed by or affect people under 18, their specific risks must be considered.
- Deliverable: a living risk register tied to system versions, with mitigations, residual-risk justifications, and review triggers.
- Integrate with existing SDLC risk practices rather than bolting on a parallel process.
- Testing against pre-defined metrics and thresholds is explicitly part of this article, including testing for foreseeable misuse.
Article 10 — Data and data governance
Training, validation and testing datasets must meet quality criteria appropriate to the intended purpose. Governance practices must cover design choices, data collection and origin, preparation (labelling, cleaning, aggregation), assumptions about what the data measures, an assessment of availability and suitability, and examination for possible biases likely to affect health, safety or fundamental rights. Datasets should be relevant, sufficiently representative, and to the best extent possible free of errors and complete for the intended purpose.
- Article 10(5) permits processing of special-category personal data strictly for bias detection and correction, subject to safeguards; document your legal basis and controls if you rely on it.
- Deliverable: dataset datasheets, provenance records, and a documented bias-examination methodology.
Article 11 — Technical documentation
Technical documentation must be drawn up before the system is placed on the market and kept up to date. Annex IV specifies the contents: a general description, detailed design and development information, monitoring and control logic, risk-management records, and validation/testing procedures. This is the evidentiary backbone auditors and market surveillance authorities will request first.
Article 12 — Record-keeping (logging)
The system must technically allow for the automatic recording of events (logs) over its lifetime, to a degree appropriate to its purpose. Logs must support traceability, post-market monitoring, and the detection of situations that may present a risk or lead to a substantial modification. For certain biometric systems the article specifies minimum log content, including usage periods, reference database checked, and input data.
Article 13 — Transparency and provision of information to deployers
High-risk systems must be sufficiently transparent for deployers to interpret output and use it appropriately, and must ship with instructions for use. Those instructions must state the provider's identity, the system's characteristics and performance (including accuracy, robustness and known limitations), the human-oversight measures in place, expected lifetime, and maintenance needs. Note this is distinct from the Article 50 end-user transparency duties.
Article 14 — Human oversight
Systems must be designed so that natural persons can effectively oversee them during use. Oversight measures must enable a person to understand capabilities and limits, remain aware of automation bias, correctly interpret output, decide not to use the system or to override it, and intervene or halt operation via a stop function. For certain biometric identification systems, a stricter rule requires that action be taken only after separate verification by at least two competent persons.
Article 15 — Accuracy, robustness and cybersecurity
Systems must achieve an appropriate level of accuracy, robustness and cybersecurity and perform consistently across their lifecycle. Accuracy metrics must be declared in the instructions for use. Robustness covers resilience to errors, faults and environmental inconsistencies, including feedback loops in systems that keep learning after deployment. Cybersecurity measures must address AI-specific attack vectors such as data poisoning, model poisoning, adversarial examples and model evasion.
Requirements versus obligations: don't stop at Article 15
Articles 8-15 describe what the system must be. A separate set of provider and deployer obligations (Articles 16-27) describes what organisations must do around the system. In practice these are where most of the operational and audit burden lands:
| Obligation | Article | What it means in practice |
|---|---|---|
| Quality management system | Art 17 | A documented QMS covering the whole lifecycle, including compliance, data management and post-market monitoring. |
| Conformity assessment | Art 43 | Demonstrate conformity before market entry, mostly via internal control; certain biometric cases need a notified body. |
| EU declaration of conformity and CE marking | Arts 47-48 | Draw up the declaration and affix CE marking once conformity is established. |
| Registration in the EU database | Art 49 | Register the system (and, for public authorities, certain deployments) in the public EU database before use. |
| Post-market monitoring | Art 72 | Collect and analyse performance data in the field and feed it back into risk management. |
| Fundamental rights impact assessment | Art 27 | Certain deployers (public bodies and specified private actors) must assess fundamental-rights impact before deployment. |
| Serious incident reporting | Art 73 | Report serious incidents to the relevant market surveillance authority within defined timeframes. |
A pragmatic sequencing for teams
- Confirm classification. Is your use case genuinely in Annex III, and do any Article 6(3) exemptions (narrow procedural or preparatory tasks) apply? Document the reasoning either way.
- Stand up the risk management system (Art 9) first; it is the spine everything else attaches to.
- Instrument data governance and logging (Arts 10, 12) early, because retrofitting provenance and audit logs late is expensive.
- Draft technical documentation and instructions for use (Arts 11, 13) as living artefacts alongside development, not as a pre-launch scramble.
- Design human oversight and robustness/security controls (Arts 14, 15) into the product, then validate against declared metrics.
- Wrap it in a QMS and run conformity assessment, CE marking and EU-database registration (Arts 17, 43, 47-49) before the December 2027 date.
Harmonised standards from CEN-CENELEC are intended to give a presumption of conformity. Track their publication: aligning to a harmonised standard is generally the lowest-friction route to demonstrating you meet Articles 8-15.The deferral to December 2027 is real breathing room, but conformity assessment, standards alignment and documentation are multi-quarter efforts. Teams that treat 2027 as a start date rather than a finish line will be the ones scrambling.