EU AI Act High-risk system checklist

Article 8 requires a high-risk AI system to meet Chapter III Section 2 requirements for its intended purpose and the generally acknowledged state of the art. Use the Article 9 risk-management process to check compliance.

Before using this checklist, separate Annex I Section A products from Section B products.

Under amended Article 2(2), Section B systems follow the sectoral route: only Article 6(1), Article 60a and Articles 102 to 112 apply directly, with Articles 57 to 59 applying only insofar as high-risk requirements have been integrated into the sectoral legislation.

For Section A systems, record any specific limitation under an applicable Article 2(13) delegated act; equivalent sectoral controls alone do not establish that a limitation applies.

Close this checklist only with a traceable evidence pack showing how each Article 9 to 15 control is implemented for this specific system, version, intended purpose, user context, and foreseeable misuse.

For systems supplied or first used before their Chapter III application date, amended Article 111(2) applies the high-risk operator rules only if significant design changes occur from that date. Annex X large-scale IT systems follow the separate rule in Article 111(1).

Chapter III Sections 1-3, except Article 6(5), apply from 2 December 2027 for Article 6(2) Annex III systems and 2 August 2028 for Article 6(1) Annex I systems.

Record the first placement or service date, type and model, and design-change analysis separately from the Article 43 substantial-modification test used to decide whether conformity assessment must be repeated. For high-risk systems intended for public-authority use, Article 111(2) requires providers and deployers to take the necessary compliance steps by 2 August 2030.

Keep the risk file current throughout the system lifecycle. Article 9 requires a risk-management system that you establish, implement, document and maintain.

For each risk, keep the hazard, affected right or safety interest, intended-use scenario, reasonably foreseeable misuse scenario, mitigation, residual risk decision, test evidence, and post-market monitoring trigger together.

For systems trained with data, check the quality of the training, validation and testing datasets used. For systems without training techniques, Article 10 applies its criteria to the testing datasets.

The data evidence should show why the data is suitable for the intended purpose and where it can fail. It should also document bias examination, bias mitigation, data gaps, and the Article 4a safeguards for any strictly necessary special-category personal data used for bias detection or correction.

If the provider relies on Article 4a for special-category personal data, record why other data, including synthetic or anonymised data, cannot effectively detect and correct the bias.

Document reuse limits, security and privacy measures including pseudonymisation, authorised access with confidentiality controls, prevention of access or transfer to other parties, and deletion when the bias is corrected or the retention period ends, whichever comes first. The processing record must explain strict necessity and why other data could not achieve the objective.

Prepare technical documentation before supplying or first using the system. Keep it current. Article 11 sets the duty and Annex IV lists the minimum content.

Article 12 requires technical logging capability over the system lifetime so that relevant events can support traceability, post-market monitoring, and monitoring by deployers where applicable.

Give deployers enough information to interpret outputs and use the system correctly under Article 13. Design the system so people can oversee it during use under Article 14.

The practical test is whether a trained deployer can understand the intended purpose, limitations, expected accuracy and robustness, foreseeable risk conditions, input-data requirements, output interpretation aids, maintenance needs, logs, and oversight controls without relying on undocumented engineering knowledge.

Test accuracy, robustness and cybersecurity for the system's intended purpose and risks. Article 15 requires appropriate, consistent performance throughout the lifecycle, including under faults, feedback loops and AI-specific attacks.

Close this part of the checklist only when the instructions for use declare accuracy levels and metrics, and the engineering evidence shows robustness and cybersecurity controls matched to the relevant circumstances and risks.

Complete the Article 16 provider duties as well as the Articles 8-15 system checks. The remaining work includes quality management, conformity assessment, declaration, CE marking, registration and ongoing corrective action where required.

If any Article 8 to 15 evidence is missing, record the gap before starting conformity-assessment, declaration, CE marking or registration steps. If the system changes substantially later, the Commission overview indicates that the provider process returns to conformity assessment.