← All guides
EU AI Act13 min read8 July 2026

EU AI Act High-Risk AI System Conformity Assessment: Art. 9–15 Obligations Explained (2026)

Complete guide to EU AI Act high-risk AI system conformity assessment requirements. Art. 9 risk management, Art. 10 data governance, Art. 11 technical documentation, Art. 14 human oversight, Art. 15 accuracy, and post-market monitoring obligations for providers.

Why the conformity assessment matters now

The EU AI Act (Regulation (EU) 2024/1689) is not an aspirational framework. As of February 2026, providers of AI systems classified as high-risk under Annex III face mandatory conformity assessment obligations before placing their systems on the EU market. The AI Office and national market surveillance authorities are actively building enforcement capacity. The window for preparation is now.

This guide covers everything you need to know about the conformity assessment process for high-risk AI systems — which systems are in scope, what Art. 9 through Art. 15 actually require, how the assessment procedures work, and where providers typically fall short.

Which AI systems are high-risk?

The EU AI Act uses two categories for high-risk AI:

  • Annex I systems — AI that is a safety component of a product already regulated under existing EU harmonised legislation (medical devices, machinery, vehicles, aviation, etc.). These are in scope from August 2027.
  • Annex III systems — stand-alone AI applications in eight specific domains. These are in scope from February 2026.

The eight Annex III high-risk categories are:

  1. Biometric categorisation systems (with narrow exceptions for biometric identification in law enforcement)
  2. Critical infrastructure management — AI used in electricity, gas, water, transport, digital infrastructure
  3. Education — AI making or influencing admission, access, or evaluation decisions
  4. Employment — AI for recruitment, CV screening, job assignment, performance evaluation, promotion, or termination
  5. Essential private services — creditworthiness assessment, credit scoring, life/health insurance risk pricing, emergency call triage
  6. Law enforcement — risk assessment of persons, crime prediction, evidence evaluation, profiling
  7. Migration and border management — risk assessment, document verification, asylum application processing
  8. Justice and democratic processes — AI assisting courts in dispute resolution; political campaign micro-targeting

Important nuance: a provider can self-classify their system as not high-risk even within these domains if the AI “does not pose a significant risk” based on specific criteria in Art. 6(3). This is a narrow exception, not a general carve-out. The burden of proof is on the provider, and incorrect self-classification is a sanctionable non-conformity.

Who has conformity assessment obligations?

The EU AI Act distinguishes between providers, deployers, importers, and distributors — but the conformity assessment obligations land primarily on providers (Art. 16), defined as those who develop and place the system on the market or put it into service under their own name or trademark.

Key point for enterprise buyers: if you significantly modify a third-party AI system, you may become the provider with full Art. 9–15 obligations. “Substantial modification” (Art. 25) means any change that alters the AI system’s performance to the extent that compliance with the original conformity assessment can no longer be assumed.

The conformity assessment routes

High-risk AI systems must undergo one of two conformity assessment procedures before CE marking:

Annex VI: Internal Control

Available to most Annex III categories. The provider self-assesses compliance with Art. 9–15, documents this in the technical documentation (Annex IV), and draws up an EU Declaration of Conformity (Art. 47). No third party is involved.

Who can use it: All Annex III categories except biometric identification systems used by law enforcement.

Annex VII: Third-Party Assessment by a Notified Body

Mandatory for: (a) AI used for real-time remote biometric identification in public spaces by law enforcement; (b) AI already requiring third-party conformity assessment under existing harmonised legislation (Annex I systems). Optional for others who want additional credibility.

Notified bodies for AI are being designated by EU member states through 2025–2026. TÜV SÜD, Bureau Veritas, DNV, and DEKRA are among the organisations pursuing AI Act notified body designation.

Art. 9: Risk Management System — the most critical requirement

The risk management system (RMS) under Art. 9 is foundational. Without it, nothing else works. Here’s what it must cover:

  1. Lifecycle scope: The RMS must operate throughout the AI system’s entire lifecycle — from design through decommissioning. A one-time risk assessment before launch does not satisfy Art. 9(1).
  2. Risk identification (Art. 9(2)): Both risks from intended use and reasonably foreseeable misuse must be identified and analysed. The AI Office’s 2025 guidance confirms that “reasonably foreseeable misuse” includes predictable off-label uses, not just malicious adversarial attacks.
  3. Risk mitigation (Art. 9(4)): Controls must be tested and verified, not merely documented. Evidence of testing is required.
  4. Vulnerable group risks (Art. 9(6)): Children, persons with disabilities, and disadvantaged groups require specific risk analysis. This is a mandatory specific consideration — not an optional enhancement.
  5. Living process (Art. 9(9)): Post-market data must feed back into the RMS. Closed-loop feedback is required — your risk register must be updated based on real-world performance data.

Common failure point: Providers document the RMS at launch and then treat it as static. Auditors and the AI Office will request evidence of updates since initial deployment. Static risk documentation is a non-conformity.

Art. 10: Data Governance — the most underestimated requirement

Art. 10 applies to any AI system trained on data. It requires documented data governance practices across the entire data lifecycle:

  • Collection, selection, labelling, and processing methods documented
  • Dataset relevance, representativeness, and completeness assessed
  • Error and anomaly detection conducted
  • Bias examination performed where system outputs may affect persons
  • Special category personal data processed only where strictly necessary

GDPR intersection: Art. 10 does not replace GDPR. The EDPB and AI Office Joint Guidance (2024) confirms that GDPR obligations apply in full to AI training data. For any high-risk AI system processing personal data, a DPIA under Art. 35 GDPR is typically required. The DPIA and the Art. 10 data governance documentation should be coordinated — they often overlap significantly.

Bias examination specifics: For employment AI (Annex III(4)), regulators will expect disparate impact analysis across protected characteristics. For credit scoring AI, regulators expect analysis for gender, age, and nationality bias. “We checked for bias” without a documented methodology and results is not sufficient.

Art. 11 and Annex IV: Technical Documentation

Technical documentation must be prepared before market placement and kept up-to-date throughout the system’s lifetime. Annex IV specifies seven categories of required content:

  1. General description of the AI system (purpose, intended use, persons affected)
  2. A detailed description of the development elements (design, training methodology, architecture)
  3. Monitoring, functioning, and control information (including logging and human oversight design)
  4. Description of the risk management system
  5. Changes made to the system and results of conformity assessment updates
  6. A list of harmonised standards applied (or other specifications where standards are absent)
  7. The EU Declaration of Conformity

The technical documentation must be made available to market surveillance authorities upon request within a reasonable time. “Available upon request” means it should be production-ready at all times, not reconstructed retrospectively.

Art. 14: Human Oversight — three pillars

Human oversight under Art. 14 is a design requirement, not just a contractual obligation. The three pillars the system must technically enable:

  1. Understand: Deployers must be able to fully understand what the system can and cannot do. This means accurate capability/limitation disclosure in the instructions for use, and an interface that does not obscure the system’s confidence levels or uncertainty.
  2. Monitor: Deployers must be able to detect anomalies, malfunctions, and unexpected performance in real time. Log visibility and anomaly alerting are design features, not afterthoughts.
  3. Intervene: Deployers must be able to disregard, override, or reverse AI outputs. Override mechanisms must be tested, documented, and technically functional.

Art. 14(5) specifically names automation bias as a risk that must be addressed. Research consistently shows that humans over-rely on AI recommendations, especially under time pressure. The AI Office expects providers to demonstrate they have considered interface design and training materials that actively counter over-reliance.

Art. 15: Accuracy, Robustness, and Cybersecurity

Three distinct requirements here:

  • Accuracy (Art. 15(1)): Accuracy levels must be specified and disclosed. “Appropriate” is context-dependent — the AI Office expects benchmarking against alternative approaches where available. For employment AI, comparison with structured human interviewing is relevant. For credit AI, comparison with traditional scorecard models is expected.
  • Robustness (Art. 15(3)): The system must behave correctly in edge cases and adversarial conditions. Testing must include distributional shift testing — what happens when real-world data differs from training data?
  • Cybersecurity (Art. 15(4)): AI-specific threats (prompt injection, model poisoning, data poisoning, evasion attacks, model inversion) are explicitly in scope. Standard application security (OWASP Top 10) is necessary but not sufficient. The ENISA AI Cybersecurity Report (2023) and OWASP LLM Top 10 are the expected reference threat taxonomies.

Post-market obligations: Art. 17, 49, 72, and 73

The conformity assessment is not a one-time event. Post-market obligations include:

  • Quality Management System (Art. 17): A documented QMS covering AI strategy, design, quality control, risk management, PMM, and incident management. Equivalent to ISO 9001 in structure, but must address AI Act specifics.
  • EU AI Database Registration (Art. 49): Mandatory registration before market placement. The EU AI database was launched in Q2 2025 at euaidb.eu. Non-registration is directly sanctionable.
  • Post-Market Monitoring (Art. 72): A structured PMM plan with data collection from deployers, performance benchmarking against declared accuracy levels, and integration with the risk management system.
  • Serious Incident Reporting (Art. 73): Time-bound reporting to the relevant national market surveillance authority. Timelines: immediately life-threatening — 2 days; serious injury — 10 days; other serious incidents — 15 days.

Penalties for non-compliance

Art. 99 establishes graduated penalties:

  • Non-compliance with banned practices (Art. 5): up to €35 million or 7% of global annual turnover
  • Non-compliance with provider obligations (Art. 9–15, 17, 49): up to €15 million or 3% of global annual turnover
  • Incorrect, incomplete, or misleading information to notified bodies or NCAs: up to €7.5 million or 1.5% of turnover

For SMEs and startups, penalties are capped at the lower of the percentage or the absolute figure. The AI Office has indicated that first-enforcement priorities will be focused on high-risk, high-harm use cases — employment AI, credit AI, and law enforcement AI.

Where to start: a practical conformity assessment roadmap

Phase 1 (0–30 days): Confirm Annex III classification. Establish (or document existing) risk management system. Begin Annex IV technical documentation. Engage assurance provider or notified body if applicable.

Phase 2 (31–90 days): Complete data governance documentation (Art. 10). Conduct bias examination. Human oversight design review and testing. Accuracy and robustness validation. AI security threat modelling.

Phase 3 (91–180 days): Register in EU AI database (Art. 49). Finalise Quality Management System (Art. 17). Establish PMM plan and incident reporting process. Draw up EU Declaration of Conformity (Art. 47). Affix CE marking.

Use ComplyKit’s EU AI Act High-Risk System Conformity Assessment generator to assess your system against all Art. 9–15 requirements and generate a structured conformity assessment report to share with your legal team or notified body.

Also relevant: our EU AI Act Compliance Checklist generator for a broader compliance overview, and the AI Privacy Impact Assessment generator for the GDPR Art. 35 DPIA requirements.