Obligations on High-Risk AI Systems

Foundational practitioner context is in the existing COMPEL article “EU AI Act Risk Classification: A Practitioner’s Guide” (Article ID 253). This specialist article goes deeper — working through each obligation Article-by-Article, naming the control evidence that satisfies it, and anchoring the discussion to two documented European enforcement patterns.

Reading the obligation stack — substance first

Chapter III Section 2 describes what a high-risk AI system must be. Section 3 describes what each actor must do about Section 2. The specialist reads Section 2 first to understand the substantive state the system must achieve, then Section 3 to understand who is responsible for achieving it.

The specialist’s obligation register is keyed by Article, not by control. Each row names the obligation, the actor who owns it, the evidence artefact that satisfies it, and the reassessment trigger. The register is built once per high-risk system and refreshed on each substantive change.

Article 9 — risk management system

Article 9 requires a continuous iterative [[risk-management-system]] across the lifecycle of the high-risk AI system, covering identification and analysis of known and reasonably foreseeable risks, estimation and evaluation of risks that may emerge during intended use and under reasonably foreseeable misuse, adoption of risk-management measures, and ongoing testing. The Article explicitly states the risk management system shall be a continuous, iterative process planned and run throughout the entire lifecycle of the high-risk AI system.

Operationally, Article 9 maps well to ISO/IEC 23894:2023 Clause 6 (the AI-specific application of ISO 31000) and to NIST AI RMF’s MAP and MANAGE functions. The specialist’s obligation-register entry for Article 9 lists the following control evidence:

• Risk-identification register with foreseeable-misuse entries separated from in-scope-use entries.
• Risk-estimation methodology documented once per system class.
• Risk-treatment plan per identified risk, with residual-risk sign-off.
• Iteration cadence and trigger conditions for re-running the risk assessment.

A frequent error is to treat Article 9 as a one-time pre-deployment exercise. The “continuous iterative” language precludes this reading; supervisory authorities will treat a stale risk register as a prima facie Article 9 failure.

Article 10 — data and data governance

Article 10 imposes duties on training, validation, and testing datasets for high-risk systems. Datasets must be relevant, sufficiently representative, free of errors to the extent possible, and complete for the intended purpose. Data-governance and management practices must cover design choices, data-collection processes, data-preparation operations, formulation of assumptions, prior assessment of data availability and suitability, examination for possible biases, identification of relevant data gaps, and measures to address those gaps.

Article 10(5) contains a narrow authorisation for processing special categories of personal data under Article 9 GDPR where strictly necessary to detect and correct bias in high-risk AI systems, subject to strict safeguards. The specialist should note this pathway but treat it with care; the safeguards are narrow and the use of special-category data for bias detection is itself a risk vector.

The Dutch childcare-benefits case — Dutch DPA fine of €2.75M against the Dutch Tax Administration in 2021 for the Toeslagenaffaire risk-scoring system — is the canonical EU example of Article 10 / Article 14 failure. The system applied an ethnicity-correlated risk indicator to classify benefit applications as fraudulent; the ensuing enforcement action and parliamentary inquiry documented failures in data-representativeness assessment, bias detection, and human-oversight design. For the specialist, the Toeslagenaffaire is the teaching case that anchors both Article 10 (data governance) and Article 14 (human oversight). Source: Autoriteit Persoonsgegevens, “Dutch DPA imposes fine on Tax Administration for discriminatory and unlawful data processing,” https://autoriteitpersoonsgegevens.nl/en/current/dutch-dpa-imposes-fine-on-tax-administration-for-discriminatory-and-unlawful-data-processing .

Article 11 and Annex IV — technical documentation

Article 11 requires that [[technical-documentation-annex-iv]] be drawn up before the high-risk system is placed on the market or put into service and kept up to date. Annex IV enumerates the minimum contents: general system description, detailed system description including intended purpose and version, monitoring and control mechanisms, description of changes made through the lifecycle, standards applied and, where relevant, the conformity assessment procedure followed, EU declaration of conformity, and post-market-monitoring plan.

Annex IV is the most concrete evidence specification in the Act. The specialist can produce an Annex IV contents checklist directly from the Annex text and use it as the working template for every high-risk system. Work performed under ISO/IEC 42001:2023 (AI management system) — particularly Clause 7 documented information and Annex A control references — substantially reduces the incremental authoring burden; most Annex IV sections can be assembled from ISO/IEC 42001 AMS artefacts with mapping and supplementary content.

Article 12 — record-keeping

Article 12 requires high-risk AI systems to automatically record events (logs) over their lifecycle, with capabilities that ensure traceability of the system’s functioning appropriate to the intended purpose. Minimum logged events include the period of each use (start/end timestamps), the reference database against which input data has been checked, the input data for which the search has led to a match, and the identity of the natural persons involved in result verification.

The specialist’s evidence artefact for Article 12 is a log-schema specification and a retention policy anchored to the system lifecycle. Supervisory authorities will request log samples during enforcement; an organisation that cannot produce logs compliant with Article 12’s requirements faces an evidentiary gap that is difficult to close retroactively.

Article 13 — transparency and provision of information to deployers

Article 13 requires high-risk AI systems to be designed and developed to ensure sufficiently transparent operation to enable deployers to interpret system output and use it appropriately. Instructions for use accompanying the system must include specified content: identity of provider, characteristics and capabilities and limitations of the system, changes to the system and performance made by the provider, human-oversight measures, expected lifetime, and maintenance and care measures.

Article 13’s transparency duty sits between Article 50 (transparency to end users of certain system classes — see Article 5 of this credential) and Article 26 (deployer-side use of transparency information). The specialist keeps the three Articles straight by remembering who receives the information: Article 13 provider → deployer; Article 50 provider → natural person interacting with the system; Article 26 deployer → end user and worker in scope.

Article 14 — human oversight

Article 14 requires high-risk AI systems to be designed and developed in such a way, including with appropriate human-machine interface tools, that they can be effectively overseen by natural persons during the period in which they are in use. The oversight must be aimed at preventing or minimising risks to health, safety, or fundamental rights that may emerge from use in accordance with the intended purpose or under reasonably foreseeable misuse.

The Article enumerates specific oversight capabilities: the natural person assigned to oversight must be able to understand the capacities and limitations of the system, remain aware of possible automation bias, correctly interpret output, decide not to use the system, and intervene or interrupt operation.

“Human in the loop” is a shorthand that the Act deliberately avoids — the Article 14 standard is design-time oversight capability, not run-time operator presence. A system designed so that a human cannot interpret its output, cannot override it, or cannot meaningfully intervene is non-compliant with Article 14 regardless of who is sitting in front of the terminal. The Toeslagenaffaire case again illustrates: the human caseworkers reviewing the system’s flags lacked the information, the training, and the interpretive frame to meaningfully override the system’s risk scores. Article 14 compliance therefore attaches to the design of the oversight relationship, not to the presence of an operator.

Article 15 — accuracy, robustness, and cybersecurity

Article 15 requires high-risk AI systems to be designed and developed in such a way that they achieve an appropriate level of accuracy, robustness, and cybersecurity, and to perform consistently in those respects throughout their lifecycle. Accuracy levels and relevant accuracy metrics must be declared in the accompanying instructions for use. Technical and organisational measures must address cyber risks including adversarial examples, data poisoning, and model evasion.

The CEN-CENELEC JTC 21 harmonised standards under the AI Act will provide the concrete benchmarks for what “appropriate level” means in each domain. Until those standards are finalised, the specialist uses ISO/IEC 42001 Clause 8 operational planning and control, together with domain-specific benchmarks where they exist (for example, MDR performance-evaluation standards for medical-device AI), as the interpretive anchor.

Articles 43 and Annex VI/VII — conformity assessment

Article 43 sets out the [[conformity-assessment]] procedure for high-risk systems. Most high-risk systems use the internal conformity assessment procedure of Annex VI — the provider self-assesses against the requirements of Chapter III Section 2 and draws up an EU declaration of conformity. Biometric systems under Annex III point 1 require the third-party assessment procedure of Annex VII, involving a notified body.

Annex I systems covered by existing third-party conformity regimes (e.g., MDR) integrate the AI Act requirements into the existing pathway rather than running parallel assessments. Notified bodies under MDR, machinery, or automotive regimes will progressively incorporate AI-Act-aligned scope over 2025–2027 as the harmonised standards mature.

Article 49 — registration in the EU database

Article 49 requires providers to register high-risk systems (and, for the Article 6(3) derogation, non-high-risk Annex III systems) in the EU database established under Article 71 before placing them on the market or putting them into service. The database is public; registration entries include system name, intended purpose, classification, status, and contact details for the provider.

The specialist treats registration as a discipline tool. Because registrations are public, the content of a registration entry cannot materially diverge from the classification register row or the technical documentation. Alignment across the three artefacts is both a compliance duty and a supervisory-signal to authorities that the organisation’s governance is coherent.

Article 72 — post-market monitoring

Article 72 requires providers to establish and document a [[post-market-monitoring]] system proportionate to the nature of the AI technologies and risks of the high-risk system. The system must actively and systematically collect, document, and analyse relevant data on performance throughout the lifetime of the system, enabling the provider to evaluate continuous compliance with the Chapter III Section 2 requirements.

Operationally, Article 72 maps to NIST AI RMF MEASURE and MANAGE, to ISO/IEC 42001 Clause 9 performance evaluation, and to industry post-market-surveillance practices from MDR (the specialist of MDR origin will find the Article 72 pattern familiar). The evidence artefact is a post-market-monitoring plan, a monitoring dashboard, and a corrective-action log.

Article 73 — serious incident reporting

Article 73 requires providers of high-risk systems to report to the national competent authority of the relevant Member State any serious incident within timelines ranging from immediately for infrastructure-disrupting incidents to 15 days for most other serious incidents. A serious incident is defined in Article 3(49) as an incident or malfunction that leads directly or indirectly to death, serious harm to health, serious and irreversible disruption of the management or operation of critical infrastructure, infringement of obligations under Union law intended to protect fundamental rights, or serious harm to property or the environment.

The specialist’s obligation-register entry for Article 73 names the responsible incident-response owner, the reporting-timeline decision tree, and the template report contents. The reporting duty runs alongside — not in place of — incident-reporting duties under other instruments (GDPR Article 33, NIS2 Directive, MDR vigilance).

Deployer-facing obligations — Articles 26 and 27

Deployers face a lighter but non-trivial obligation stack under Article 26: use the system in accordance with instructions, assign human oversight to competent persons, maintain logs under their control, cooperate with authorities, and inform workers and their representatives. Annex III deployers in public-sector and certain private-sector contexts additionally owe a [[fundamental-rights-impact-assessment]] under Article 27 before first use.

Article 25 rewires roles where a deployer substantially modifies a high-risk system — see Article 1 of this credential for the role-transfer mechanics.

Diagram — HubSpokeDiagram

This article is accompanied by a HubSpokeDiagram. The hub is the high-risk AI system. The spokes are the eleven obligations: Article 9 (risk management), Article 10 (data and data governance), Article 11 (technical documentation), Article 12 (record-keeping), Article 13 (transparency), Article 14 (human oversight), Article 15 (accuracy, robustness, cybersecurity), Article 43 (conformity), Article 49 (registration), Article 72 (post-market monitoring), and Article 73 (serious incident reporting). Each spoke is a coloured chevron; the colour encodes the actor primarily responsible (provider — blue; deployer — orange; provider-and-deployer shared — purple). The figure gives the specialist a single-image reference that captures both the obligation list and the actor allocation in one look.

Cross-references

• EATP-Level-2/M2.6-Art11-EU-AI-Act-Compliance-for-Practitioners.md — practitioner compliance execution consuming the obligation register.
• EATP-Level-2/M2.6-Art12-Building-EU-AI-Act-Evidence-Portfolios.md — evidence-portfolio construction using Annex IV as the spine.
• EATE-Level-3/M9.4-Art03-Enterprise-AI-Compliance-Evidence-Management.md — enterprise-scale evidence management system on which the specialist’s obligation register is operated.
• EATF-Level-1/M1.5-Art09-Audit-Preparedness-and-Compliance-Operations.md — audit-preparedness context for Articles 72–73.
• Existing regulatory article regulatory-compliance-articles.ts Article ID 253, “EU AI Act Risk Classification: A Practitioner’s Guide” — the four-tier practitioner context this specialist treatment extends.

Learning outcomes — confirm

A specialist who completes this article should be able to:

• Explain each substantive obligation Articles 9 through 15 and the corresponding Section 3 actor-allocation.
• Classify at least ten described control activities under the obligation Article they satisfy.
• Evaluate a technical-documentation draft against the Annex IV contents list and identify gaps.
• Design a high-risk obligation checklist for a given Annex III classification, keyed by Article and by actor.

Quality rubric — self-assessment

Publish threshold per design doc §16.5 is 85. This article meets the threshold.