EU AI Act conformity assessment: how high-risk systems get certified

A conformity assessment is the documented procedure that demonstrates a high-risk AI system has been designed and built in compliance with the seven sections of Chapter III, Section 2: risk management (Article 9), data and data governance (Article 10), technical documentation (Article 11), record-keeping (Article 12), transparency and provision of information to deployers (Article 13), human oversight (Article 14), and accuracy, robustness, and cybersecurity (Article 15) [1].

The assessment ends with three artefacts: a signed EU declaration of conformity under Article 47, the CE marking affixed to the system or its accompanying documentation under Article 48, and a registration entry in the EU database for high-risk AI systems under Article 49. These three together are the public proof that the provider has met the design-time obligations and is operating the post-market monitoring required by Article 72.

The conformity assessment is repeated whenever the system undergoes a substantial modification, defined in Article 3(23) as a change not foreseen by the provider in the initial conformity assessment that affects compliance or changes the intended purpose. Routine updates inside the foreseen-change envelope do not trigger reassessment.

The Act provides two routes. Annex VI: internal control. The provider verifies its quality management system, examines the technical documentation, and confirms that the design and development process complies with the regulation - all without third-party involvement. This route applies to most Annex III high-risk systems, provided the provider has applied harmonised standards or, where standards do not exist, common specifications adopted by the Commission.

Annex VII: assessment by a notified body. A notified body, accredited by a member state and listed in the NANDO database, reviews the quality management system and the technical documentation, and may perform conformity tests on the system itself. Annex VII is mandatory for AI systems used for biometric identification under Annex III, point 1, where the provider has not applied harmonised standards. It is also the default route for AI safety components in Annex I regulated products, where the existing sectoral conformity assessment regime continues to apply with the AI requirements layered on top [3].

The choice of route should be documented in the conformity assessment plan before the build starts. Notified-body capacity is currently limited and lead times of three to nine months are realistic, which means the route choice has direct programme-management consequences.

Annex IV lists the nine sections the technical documentation must cover. One, a general description of the AI system: intended purpose, provider details, version, hardware, software, deployment forms, instructions for use. Two, a detailed description of the elements and the development process: design choices, system architecture, computational resources, data requirements, training methodologies, validation and testing procedures, key design choices and their rationale. Three, monitoring, functioning, and control: capabilities and limitations, foreseeable unintended outcomes, human oversight measures, technical measures to facilitate interpretation. Four, performance metrics: accuracy, robustness, fairness measures appropriate to the use case [3].

Five, the risk management system under Article 9. Six, a description of the data and data-governance practices under Article 10. Seven, the change management process. Eight, harmonised standards applied or, where partly applied, the alternative solutions. Nine, a copy of the EU declaration of conformity and the post-market monitoring plan. The pack is retained for 10 years from when the system is placed on the market under Article 18 and made available to national competent authorities on request.

Article 40 establishes a presumption of conformity: an AI system that complies with harmonised standards published in the Official Journal is presumed to comply with the corresponding requirements of Chapter III, Section 2. The Commission has issued a standardisation request to CEN-CENELEC under JTC 21, and the first wave of harmonised standards is being finalised. Until the harmonised standards are published, providers can apply common specifications adopted by the Commission under Article 41 or document equivalent solutions.

The practical importance of harmonised standards is that they unlock the Annex VI internal-control route for most Annex III systems. A provider who applies the standards can self-certify compliance. A provider who does not apply standards must either justify the alternative or use a notified body. ISO/IEC 42001:2023, the AI management-system standard, is closely tracked by the harmonised-standards work and is increasingly used as a procurement reference even where it is not yet formally harmonised [5].

Article 72 requires providers of high-risk AI systems to establish and document a post-market monitoring system that actively and systematically collects, documents, and analyses relevant data on the system's performance throughout its lifetime. The post-market monitoring plan is part of the technical documentation and must address how the system will be evaluated against the obligations of Chapter III, Section 2 in real-world conditions.

Serious incidents - defined in Article 3(49) as malfunctions or use leading to death, serious damage to property or environment, serious and irreversible disruption of critical infrastructure, breach of fundamental rights, or serious harm to health - must be reported to the relevant national market-surveillance authority under Article 73. The reporting deadline is 15 days for general serious incidents, 10 days for cases involving death, and 2 days for incidents involving widespread infringement or serious infrastructure disruption.

The post-market monitoring plan should name the metrics, the data-collection mechanism, the review cadence, the responsible owner, and the trigger conditions for re-running the conformity assessment. Plans that defer the operational specification to "after deployment" generally produce gaps that surface during the first regulator audit.

Deployers do not perform the conformity assessment - that is the provider's responsibility - but they carry obligations that interact with it. Article 26 requires deployers to use the system in accordance with the instructions for use, assign human oversight to natural persons with the necessary competence and authority, ensure input data is relevant and sufficiently representative, monitor operation against the instructions, retain logs for at least six months unless other law requires longer, inform workers and their representatives where high-risk systems are used in the workplace, conduct a fundamental rights impact assessment under Article 27 where applicable, and inform individuals subject to AI-driven decisions under Article 26(11) where applicable.

The contractual interface between provider and deployer should make this allocation explicit. A well-drafted master services agreement names the provider, names the responsible party for each Annex IV section, includes the post-market monitoring data feed back to the provider, and specifies audit rights, indemnification, and termination triggers tied to compliance status.

Five workstreams cover the preparation surface. One, the conformity assessment plan: route choice (Annex VI vs VII), notified-body selection if needed, milestones, owners, evidence schedule. Two, the data-governance description: training data sources and provenance, validation and testing splits, bias evaluation, special-categories handling, data-retention policy. Three, the technical documentation pack: a living document that grows alongside the build, structured around the nine Annex IV sections.

Four, the human-oversight design: not a UI overlay but an architectural constraint that shapes which decisions are made by the model, which by the human, and what override paths exist. Five, the post-market monitoring plan: metrics, owners, review cadence, incident-reporting procedure, retraining triggers.

For the broader cluster context, see EU AI Act overview, risk classification, and ISO 42001 mapping. For a guide to selecting a vendor that can produce these artefacts, see EU AI Act compliant AI vendors. For the underlying methodology, see TRACE.

Five patterns recur. A provider that defers the conformity assessment plan to "after pilot" - the work cannot be retro-fitted cheaply because the design choices that drive compliance happen at architecture time. A provider whose risk-management documentation is generic and not tied to the system's specific Annex III area. A provider whose data-governance description treats Article 10 as a checklist rather than a design constraint, leaving training-data provenance and bias evaluation thin. A provider whose human-oversight design is a UI overlay rather than an architectural property of the system. A provider whose post-market monitoring plan ends at deployment and has no structured metric collection or review cadence.

The Bank for International Settlements' 2024 paper on generative AI in finance describes similar patterns from the supervisory side and is a useful cross-reference for buyers in financial services [8]. The same underlying problem - compliance work treated as a documentation exercise rather than as an engineering constraint - drives most of the audit findings.