EU AI Act Compliance Checklist for High-Risk AI Systems
Most high-risk AI checklists list the articles and stop. That is not where teams get stuck. They get stuck on what counts as evidence — whether a notebook satisfies Article 11, whether a review queue satisfies Article 14, whether a dashboard satisfies Article 72. This checklist is written around that question, and it is ordered by dependency rather than by article number.
Published: March 2026 · updated August 2026 · Author: Dominic Fui Dodzi-Nusenu · Reading time: ~9 minutes
Disclosure: This article was drafted using generative AI assistance and subsequently edited, verified, and expanded by human legal and tech policy specialists.
In brief
High-risk obligations now apply from 2 December 2027 for standalone Annex III systems and 2 August 2028 for AI embedded in Annex I regulated products. Nine workstreams matter: classification, risk management (Article 9), data governance (Article 10), technical documentation (Article 11 and Annex IV), logging (Article 12), transparency to deployers (Article 13), human oversight (Article 14), accuracy and robustness and cybersecurity (Article 15), and post-market monitoring with serious-incident reporting (Articles 72 and 73). Three of these accumulate evidence over time — risk management, logging and monitoring — so they must start first even though they finish last. The most common failure is not a missing control but a control that exists and cannot be evidenced as it stood on a past date.
Step 0 — Classification, and writing down why
Before any control, establish and record the tier. For each system capture the intended purpose, the Annex III point relied on or ruled out, whether you are provider or deployer, and the date and author of the assessment.
Record the reasoning, not just the conclusion. A supervisor testing your classification will ask why a system was judged out of scope. „We assessed it as minimal risk“ is not an answer; „the system ranks existing customers for outbound marketing and makes no eligibility determination, so Annex III point 5 does not engage“ is.
The nine workstreams, in dependency order
| # | Article | What it demands | What counts as evidence |
|---|---|---|---|
| 1 | Art. 9 — Risk management | A continuous, iterative process across the lifecycle | Dated register of identified risks, mitigations, residual risk and review cycles |
| 2 | Art. 10 — Data governance | Relevant, representative, error-examined training, validation and test data | Data provenance records, bias examination results, documented gaps |
| 3 | Art. 12 — Logging | Automatic recording of events over the system’s lifetime | Retained, tamper-evident logs traceable to a system version |
| 4 | Art. 15 — Accuracy, robustness, cybersecurity | Appropriate performance and resilience, declared | Test results per version, adversarial and drift testing, declared metrics |
| 5 | Art. 14 — Human oversight | Measures enabling effective override by competent people | Named roles, competence records, override rate and outcomes |
| 6 | Art. 13 — Transparency to deployers | Instructions for use enabling correct operation | Versioned instructions covering purpose, limits, and expected performance |
| 7 | Art. 11 + Annex IV — Technical documentation | Prescribed content set, kept current | Version-controlled documentation reconstructable at a past date |
| 8 | Art. 17 — Quality management system | Documented policies and procedures for compliance | QMS covering change control, responsibilities, and record keeping |
| 9 | Art. 72 + 73 — Post-market monitoring and incidents | Active monitoring plan; serious incident reporting | Monitoring plan, collected performance data, incident register |
Why this order and not article order
Items 1, 3 and 9 produce evidence that only exists if time has passed. A risk register with one entry dated last week describes a process that has not run. Logs cannot be backdated. A monitoring plan with no collected data is a document about an intention. Everything else — documentation, instructions, the QMS — can be written in a concentrated effort near the end, and written well.
So the correct sequencing is counter-intuitive: start the things that accumulate, defer the things that can be authored. Teams routinely do the reverse, because documentation feels like progress and monitoring feels like infrastructure.
The four evidence tests
For each control, ask these before calling it done.
- Reconstruction. Can you show what this system, its data and its documentation looked like on a given date eighteen months ago?
- Attribution. Can you say who made each decision and when, without relying on anyone’s memory?
- Independence. Would this evidence convince someone who did not build the system and does not trust you?
- Continuity. Does it show a process running, or a deliverable produced once?
Most artefacts that fail an audit fail the first and the fourth. They are accurate, current, and unable to speak about the past.
Common substitutions that do not hold
| Teams often submit | Why it falls short |
|---|---|
| Model cards in a wiki | No version history tied to system releases; editable without trace |
| A Jupyter notebook of validation results | Not reconstructable per release; usually not retained per version |
| A BI dashboard | Shows current state only; Article 72 expects collected data over time |
| A manual review queue | Article 14 requires competence, authority and information to override — a queue alone evidences none of the three |
| Vendor documentation alone | Covers the vendor’s system as shipped, not your configuration, data or use |
Would your current evidence survive the reconstruction test?
Assess your high-risk systems against Articles 9 to 15 in one pass.
Related reading
- EU AI Act for Financial Institutions: The 2027 Deadline
- German AI Regulation: BaFin, DORA, NIS2 and the KI-MIG
- Understanding AI Bias in Financial Services
Frequently asked questions
When do high-risk obligations actually apply?
2 December 2027 for standalone Annex III systems and 2 August 2028 for AI embedded in products already regulated under Annex I, following the Digital Omnibus deferral. Prohibited practices, AI literacy, GPAI obligations and Article 50 transparency are already in force.
Do deployers need all nine workstreams?
No. Deployer duties sit mainly in Article 26 — operating the system per instructions, ensuring input data relevance, assigning competent human oversight, retaining logs and monitoring. The full Annex IV documentation burden falls on providers, but note Article 25 can make a deployer into a provider.
Is a conformity assessment always external?
No. Article 43 lets providers of most Annex III systems choose internal control under Annex VI, while some cases — notably certain biometric systems — offer a route involving a notified body under Annex VII. Where the law offers a choice, it is genuinely yours to make; the routes differ in cost, timing and whether you end up holding a certificate.
How long should logs be retained?
Long enough to serve post-market monitoring and any incident investigation over the system’s lifetime, and at minimum the period specified for your system type. In practice, plan retention around the reconstruction test above rather than the shortest defensible period.
Can we start with documentation and add monitoring later?
This is the most expensive sequencing error available. Documentation can be written well in a concentrated effort; monitoring history cannot be created retrospectively. Start logging and monitoring first even if the documents lag.
What triggers Article 73 serious incident reporting?
A malfunction or incident that directly or indirectly leads to death, serious harm to health, serious disruption of critical infrastructure, breach of fundamental-rights obligations, or serious harm to property or the environment. Reporting deadlines are short, so the incident procedure needs to exist before you need it.