This checklist helps test whether a high-risk AI system has the requirement evidence expected by Articles 8 to 15 before provider obligations such as conformity assessment, declaration, CE marking, and registration are triggered.
The checks focus on risk management, training-validation-testing data, technical documentation, automatic logs, deployer instructions, human oversight, accuracy, robustness, and cybersecurity. If you are not sure whether your system is in scope, start by checking whether it is a high-risk AI system under Article 6 and whether you are the provider or deployer covered by the AI Act.
Structured answer sets in this page tree.
Cited legal and guidance references.
Articles 8 to 15 of Regulation (EU) 2024/1689 set the core requirements for a . First document why the system is high-risk and which application date controls. Regulation (EU) 2026/1744 entered into force on 27 July 2026 and applies Chapter III Sections 1-3 from 2 December 2027 for Article 6(2) Annex III systems and from 2 August 2028 for Article 6(1) Annex I systems. Then use this release-readiness checklist for the provider evidence pack and Article 16 hand-off. Every item should have an owner, evidence location, test result or document reference, unresolved gap, and release decision.
Article 8 is the umbrella requirement: the must comply with the requirements in Section 2, taking account of its intended purpose and the generally acknowledged state of the art. The Article 9 risk management system should be used when checking that compliance.
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.
Under amended Article 111(2), the high-risk operator rules apply to a system placed on the market or put into service before its Chapter III application date only if the system undergoes significant design changes from that date. The controlling date is 2 December 2027 for an Article 6(2) Annex III system and 2 August 2028 for an Article 6(1) Annex I system. 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.
Maintain the risk management file throughout the system lifecycle. Article 9 requires an established, implemented, documented, and maintained risk management system for the .
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 high-risk AI systems that train models with data, Article 10 requires training, validation, and testing data sets to meet quality criteria when those data sets are used. For systems that do not use training techniques, the Article 10 criteria apply to testing data sets.
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.
Article 11 requires technical documentation before the is placed on the market or put into service and requires it to be kept up to date. Annex IV gives the minimum documentation 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.
Article 13 is about information that lets deployers interpret the system output and use the appropriately. Article 14 is about designing and providing the system so natural persons can oversee it during use.
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.
Article 15 requires high-risk AI systems to achieve an appropriate level of accuracy, robustness, and cybersecurity and to perform consistently throughout their lifecycle. The checkpoint covers model quality, system behaviour, operational environment, 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.
Articles 8 to 15 are the requirement baseline, but providers still need the Article 16 obligation package before placing a on the market or putting it into service. Keep that hand-off explicit so the checklist is not mistaken for the whole compliance file.
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.
Sorena can help convert the Article 8 to 15 checklist into a structured evidence pack for risk, data, documentation, logging, deployer instructions, oversight, testing, robustness, and cybersecurity owners.
Ask questions tied to cited sources about high-risk AI requirements, provider obligations, and evidence gaps using the cited sources on this page.
Review your high-risk AI system evidence, open Article 8 to 15 gaps, and provider hand-off steps with Sorena.
"declaration of conformity"
"Obligations of providers"