Annex III High-Risk Obligations and the December 2027 Date
This page answers one question: if you build or deploy an AI system that falls under Annex III of the EU AI Act, what exactly must be true on 2 December 2027, and how much of that work can realistically still be started now. The short version is that the Digital Omnibus moved the application date for standalone Annex III systems, it did not move the enforcement regime that is already live, and the extra months disappear quickly once you lay a conformity assessment out backwards from the deadline.
What the Act says
Article 6(2) classifies as high risk any AI system listed in Annex III. Annex III covers eight areas, including biometrics, critical infrastructure, education and vocational training, employment and worker management, access to essential private and public services including creditworthiness evaluation and life and health insurance pricing, law enforcement, migration and border control, and administration of justice.
Article 6(3) provides a derogation. A system named in Annex III is not high risk if it does not pose a significant risk of harm to health, safety or fundamental rights, because it performs a narrow procedural task, improves the result of a previously completed human activity, detects decision making patterns or deviations from prior patterns without replacing or influencing the human assessment, or performs a preparatory task. A system that performs profiling of natural persons is always high risk, with no derogation available. Under Article 6(4), a provider that relies on the derogation must document that assessment before placing the system on the market and must still register the system in the EU database under Article 49.
If the system is high risk, Articles 9 to 15 set the substantive requirements: a risk management system that runs across the whole lifecycle (Article 9), data governance for training, validation and testing sets (Article 10), technical documentation to the content specified in Annex IV (Article 11), automatic logging (Article 12), instructions for use to deployers (Article 13), human oversight measures designed into the system (Article 14), and accuracy, robustness and cybersecurity (Article 15). Article 16 lists the provider obligations, Article 17 requires a documented quality management system, Article 43 sets the conformity assessment route, Article 47 the EU declaration of conformity, Article 48 CE marking and Article 49 registration.
What the Omnibus moved and what it did not
The Digital Omnibus provisional agreement of May 2026 moved the application of standalone Annex III high-risk obligations to 2 December 2027, and the Annex I embedded high-risk obligations to 2 August 2028. That agreement is still pending formal adoption, so the final text can shift in detail. Plan to the date, do not treat it as settled law.
What did not move is more important for most teams:
- The Article 5 prohibitions have applied since 2 February 2025. If your product does emotion inference in the workplace or in education, untargeted facial image scraping, or social scoring, the extension is irrelevant to you.
- Article 4 AI literacy obligations have applied since 2 February 2025.
- Article 50 transparency duties and Article 53 GPAI obligations have been enforceable since 2 August 2026.
- Market surveillance authorities have had full enforcement powers since 2 August 2026. Penalty exposure under Article 99 of up to 15,000,000 EUR or 3 percent of total worldwide annual turnover for provider obligation breaches is live now for everything already in application.
So the extension bought time on one block of obligations while the enforcement machinery around it was already switched on.
Provider or deployer
A provider develops the system or has it developed and places it on the market or puts it into service under its own name or trade mark. A provider carries Articles 9 to 17, the conformity assessment under Article 43, the declaration and CE marking under Articles 47 and 48, registration under Article 49, post-market monitoring under Article 72 and serious incident reporting under Article 73.
A deployer uses the system under its own authority in a professional capacity. Article 26 is shorter but not trivial. A deployer must use the system in accordance with the instructions for use, assign human oversight to people with the necessary competence, training and authority, ensure input data is relevant and sufficiently representative where it controls that data, monitor operation and inform the provider and the market surveillance authority of serious incidents, and keep automatically generated logs for at least six months unless other law requires longer. Employers deploying workplace systems must inform worker representatives and affected workers before putting the system into use.
Article 25 is the clause that catches most SaaS companies. If you put your name or trade mark on a high-risk system, make a substantial modification to one, or change the intended purpose of a system so that it becomes high risk, you become the provider and inherit the full provider stack.
Article 27 adds a fundamental rights impact assessment for deployers that are public bodies or private entities providing public services, and for deployers of the creditworthiness and life and health insurance systems in Annex III point 5.
What the obligation concretely requires
Translating Articles 9 to 17 into artefacts, by the deadline you need to hold the following and be able to produce it on request:
- A written risk management file identifying known and foreseeable risks, the mitigations adopted, residual risk accepted and the testing that supports that judgement. It must be reviewed and updated, not written once.
- Data governance records covering provenance, collection method, scope and intended purpose of each training, validation and test set, examination for bias, and the gaps and shortcomings identified.
- Technical documentation covering every heading in Annex IV, including architecture, computational resources, performance metrics and the validation methodology.
- Automatic logging implemented in the product, recording the period of each use, the reference database checked where applicable, the input data and the natural persons involved in verification of the output. Retain for the lifetime of the system, at minimum six months.
- Instructions for use that give deployers the characteristics, capabilities, limitations, expected accuracy and known circumstances in which the system may present risk, as required by Article 13.
- Human oversight measures built into the design, not a sentence in a contract, so that a person can understand the output, interpret it correctly, disregard or override it and stop the system.
- A quality management system under Article 17, documented in policies and procedures, covering design control, testing, data management, post-market monitoring and incident reporting.
- A completed conformity assessment, an EU declaration of conformity, CE marking and an entry in the EU database.
For Annex III point 1 biometric systems, Article 43 routes you to a notified body under Annex VII where harmonised standards have not been applied in full. For Annex III points 2 to 8, conformity assessment is based on internal control under Annex VI. Internal control is self assessment, but it is self assessment against the full evidence set above, and the market surveillance authority can ask to see all of it.
The dates that bind
| Date | Status | What applies |
|---|---|---|
| 2 February 2025 | In force | Article 5 prohibitions, Article 4 AI literacy |
| 2 August 2026 | In force | Article 50 transparency, Article 53 GPAI obligations, enforcement and penalty powers |
| 2 December 2027 | 412 days away | Annex III standalone high-risk obligations, per the Digital Omnibus provisional agreement |
| 2 August 2028 | Future | Annex I embedded high-risk obligations |
| 2 August 2030 | Future | Deadline under Article 111 for bringing legacy high-risk systems used by public authorities into compliance |
Article 111 also contains a legacy provision for high-risk systems already placed on the market before the application date, which is lost the moment the system is subject to a significant change in design. Check the final Omnibus text for how the reference date in Article 111 is restated before relying on it, and do not architect a 2027 roadmap around freezing a product for three years.
Why 412 days is tighter than it sounds
Lay the work out backwards. Registration and the declaration of conformity have to be complete before the system is placed on the market, so they sit at the end. They depend on a finished technical documentation pack, which depends on completed testing and a risk management file that shows iteration over time rather than a single snapshot. Article 10 data governance evidence is the hardest item to produce retrospectively, because provenance for datasets assembled two years ago is often simply not recoverable, and the remedy is re-collection or re-training. Article 12 logging is an engineering change that has to ship, then run long enough to produce the records an authority will ask for. An Article 17 quality management system that was documented three weeks before the deadline looks exactly like what it is.
If you are in Annex III point 1 and need a notified body, add queue time on top of all of that. Notified body capacity under this regulation is new and finite, and the demand curve peaks in the months immediately before each application date.
What to do in the next 412 days
- Finish the Article 6 classification in writing this quarter. For each system, record the Annex III point it touches, whether any Article 6(3) condition applies, and whether the system performs profiling of natural persons, which removes the derogation. If you rely on the derogation, write the assessment now, because Article 6(4) requires it to exist before the system is placed on the market and requires registration anyway.
- Fix your role per system under Articles 25 and 26. Produce a one line answer for each product and each significant customer deployment pattern: provider, deployer, or provider by white labelling or substantial modification. Push the conclusions into your contracts, since a reseller putting their logo on your model makes them a provider and they will come back to you for the documentation.
- Ship logging and data provenance before the documentation work. These two are the only items where delay destroys evidence rather than merely postponing effort. Get Article 12 logs into production in the next two release cycles, and start recording dataset lineage for every training run from today.
- Book notified body capacity now if you are in Annex III point 1. Confirm whether the harmonised standards you intend to rely on are published and whether they cover your system in full. If they do not, you are on the Annex VII route and the calendar is not yours to control.
- Stand up the Article 17 quality management system in the first half of 2027. It needs operating history, internal audit records and change control evidence by December 2027, so it has to exist long before the documentation is assembled.
If you are not yet sure which of your systems fall inside Annex III, or whether you are the provider or the deployer of each one, the free screener at https://www.getactcomply.com/check walks through the Article 6 classification and the role question and returns a per system answer you can take into a planning meeting.