If your AI system qualifies as high-risk under the EU AI Act, seven distinct technical and organisational requirements apply before you can lawfully deploy it in the EU, and they must be maintained throughout the system’s operational life.
These requirements are set out in Articles 9 to 15 of Regulation (EU) 2024/1689. They cover everything from how you manage risk and govern your training data, to the logs you must generate, the oversight mechanisms you need in place, and the accuracy and robustness standards the system must meet. Collectively, they represent the most detailed compliance obligation in the entire regulation.
This page explains each requirement in plain language, maps it to the relevant article, and gives you a checklist you can use to assess where your organisation currently stands.
Whether you are a provider building a high-risk AI system or a deployer operating one, these requirements affect you, although the specific obligations differ by role.
Key dates to know: The full requirement framework for most standalone high-risk AI systems listed in Annex III (covering recruitment, credit scoring, biometrics, law enforcement, education, and border control) applies from 2 December 2027, deferred 16 months from the original 2 August 2026 date by the Digital Omnibus.
High-risk AI systems embedded as safety components in regulated products under Annex I (such as medical devices, machinery, and vehicles) must comply by 2 August 2028.
→ Not sure whether your system qualifies as high-risk? Start with our Self-assessment tool.
→ Need a role-by-role breakdown of who owns which obligations? See Provider vs Deployer: Who owes what.
What counts as a high-risk AI system?
Under Article 6, an AI system is classified as high-risk if it falls into one of two categories:
Category 1: It is itself a safety component of a product regulated under EU sectoral legislation (medical devices, machinery, toys, vehicles, and similar), or it is such a product in its own right, provided its failure or malfunction would endanger health or safety. Following the Digital Omnibus, AI used solely for non-safety purposes, such as user assistance, optimisation, service efficiency, automation, convenience, or non-safety quality control, no longer qualifies under this route.
Category 2: It is listed in Annex III of the AI Act. Annex III covers eight domains:
- Biometric identification and categorisation
- Critical infrastructure management (energy, water, transport)
- Education and vocational training (access, assessment, grading)
- Employment and worker management (recruitment, performance monitoring, task allocation)
- Access to essential private and public services (credit scoring, benefits assessment, emergency dispatch)
- Law enforcement (risk assessment of individuals, evidence evaluation)
- Migration, asylum and border control
- Administration of justice and democratic processes
If your system sits in any of these areas, the requirements below apply to you. A separate self-classification obligation under Article 6(3) means providers must also assess whether an Annex III system genuinely poses a significant risk, and document that assessment either way.
The seven requirements at a glance
| Requirement | Article | Who it primarily applies to |
|---|---|---|
| Risk management system | 9 | Provider (deployer must cooperate) |
| Data and data governance | 10 | Provider |
| Technical documentation | 11 | Provider |
| Record-keeping (logging) | 12 | Provider (deployer retains logs) |
| Transparency to deployers | 13 | Provider |
| Human oversight | 14 | Provider designs; deployer implements |
| Accuracy, robustness, and cybersecurity | 15 | Provider |
Note: Article 26 sets out separate deployer obligations that run alongside these seven technical requirements. These include conducting a fundamental rights impact assessment under Article 27 where relevant, notifying individuals when they are subject to high-risk AI decision-making, and cooperating with market surveillance authorities.
Requirement 1: Risk management system (Article 9)
What the regulation requires
Providers must establish, implement, document, and maintain a risk management system across the entire lifecycle of the high-risk AI system. The regulation is explicit that this is a continuous, iterative process; not a one-off exercise completed before launch.
The system must identify and analyse known and foreseeable risks, estimate and evaluate those risks when the system is used as intended and when it is reasonably foreseeable that it may be misused, and adopt risk management measures to address them. It must also account for the combined effect of all seven requirements working together.
Testing is a specific obligation under Article 9. Systems must be tested to verify they perform consistently for their intended purpose, with testing carried out at appropriate points throughout development and in any event before being placed on the market or put into service.
What this means in practice
A risk management system under Article 9 is not a document; it is a set of living processes backed by documentation. You need a formal framework for identifying risks at the point of design, a process for evaluating those risks before deployment, and ongoing mechanisms for detecting new risks once the system is in operation.
Residual risks that cannot be fully eliminated must be judged acceptable and documented as such. Where the system will be used by deployers in specific contexts, providers must also account for the knowledge and training of those deployers when designing risk mitigation measures.
Article 9 compliance checklist
☐ Risk management system documented and formally established before deployment
☐ Risk identification and analysis covers intended use and reasonably foreseeable misuse
☐ Risk evaluation completed and residual risks assessed as acceptable
☐ Risk management measures implemented (design changes, technical mitigations, user information)
☐ Testing carried out prior to placement on the market, testing records retained
☐ Risk management process reviewed and updated on a regular basis throughout operational life
☐ Vulnerable groups, including minors, considered in risk assessment where relevant
☐ Risk management documentation available for regulatory inspection
Requirement 2: Data and data governance (Article 10)
What the regulation requires
High-risk AI systems that involve model training must be developed using training, validation, and testing datasets that meet specific quality criteria. The datasets must be subject to appropriate data governance and management practices, be relevant and representative for the intended purpose, and be free of errors and complete to the greatest extent possible.
Providers must be able to demonstrate how datasets were sourced, what the data collection process was, how potential biases were identified and addressed, and what gaps exist and why.
The requirement applies to all three dataset types: training data, validation data, and testing data. For systems that do not use model training techniques, the Article 10 requirements apply to testing datasets only.
What this means in practice
Article 10 treats data governance as a technical obligation, not an aspiration. You need documented processes for how data is collected, cleaned, labelled, and evaluated — and evidence that shows those processes were actually followed. Version control for training datasets is effectively required, because you need to be able to trace which data was used in which model version if a compliance question arises later.
Bias detection is specifically addressed. Where bias cannot be detected or corrected without processing special categories of personal data, the regulation permits this under strict conditions; including technical safeguards, restricted re-use, and GDPR compliance.
Article 10 compliance checklist
☐ Training, validation, and testing datasets documented with source, collection process, and scope
☐ Relevance and representativeness of datasets assessed for the intended use and geographic/demographic context
☐ Bias detection and correction measures implemented and documented
☐ Dataset version control in place; each model version traceable to specific dataset versions
☐ Data gaps identified and assessed for impact on system performance
☐ Special category personal data processing (if used for bias correction) meets Article 10(5) conditions
☐ Data governance practices reviewed when datasets are updated
Requirement 3: Technical documentation (Article 11 and Annex IV)
What the regulation requires
Before placing a high-risk AI system on the market or putting it into service, providers must prepare technical documentation. This documentation must be drawn up in such a way that it enables authorities to assess compliance with the requirements; which means it cannot simply be internal developer documentation repurposed for a regulatory audience.
The specific content of technical documentation is defined in Annex IV of the AI Act. It covers eleven mandatory categories, including a general description of the system and its intended purpose, the development methodology, the training data used, the performance metrics and test results, the risk management measures applied, and the instructions for use provided to deployers.
Technical documentation must be kept up to date for the entire lifetime of the system. If the system undergoes substantial modification, the documentation must be revised accordingly and a new conformity assessment may be triggered.
What this means in practice
Think of technical documentation as the regulatory evidence base. Its purpose is not to explain the system to developers but to enable an external authority to verify compliance without having to reverse-engineer the system. The depth of detail required by Annex IV is substantially greater than most organisations’ current model cards or system design documents.
SMEs and start-ups are permitted to provide technical documentation in a simplified form using a template the Commission is required to produce, but the substantive requirements remain the same.
Article 11 compliance checklist
☐ Technical documentation prepared before deployment, covering all Annex IV categories
☐ General description includes intended purpose, use case scope, and foreseeable misuse
☐ Development methodology documented (architecture, model type, training approach)
☐ Training data described (types, sources, preprocessing, bias measures)
☐ Performance metrics defined and test results recorded for each intended use scenario
☐ Risk management documentation cross-referenced in technical documentation
☐ Instructions for use prepared for deployers (Article 13 content)
☐ Technical documentation kept up to date following any substantial modification
☐ Documentation stored and available for the required retention period (minimum 10 years for most systems)
Requirement 4: Record-keeping / automatic logging (Article 12)
What the regulation requires
High-risk AI systems must be technically capable of automatically recording events (logs) over their entire operational lifetime. The logging function must enable traceability: regulators and deployers must be able to reconstruct what the system did, when, and on the basis of what inputs.
Logging requirements vary by system type. For systems that use biometric identification, the logs must capture the date and time of each use, the reference database consulted, the input data that led to a match, and the identity of the persons who reviewed the results. This level of specificity gives a sense of the granularity the regulation expects more broadly.
Providers design and implement the logging capability. Deployers are responsible for retaining the logs generated; under Article 26(5), deployers of high-risk Annex III systems must retain logs for a minimum of six months, unless other EU or national law specifies a longer period.
What this means in practice
Logging is where many organisations discover a gap between what they assumed they were recording and what the regulation actually requires. The obligation is not simply to retain inference outputs but to capture the full chain of events that produced them; inputs, data lookups, decision points, and any human interventions.
This has infrastructure implications. Systems that were not designed with audit-grade logging in mind will often require significant rearchitecting to meet Article 12 obligations.
Article 12 compliance checklist
☐ Automatic logging capability built into the system — not bolted on post-deployment
☐ Logs capture: event timestamps, input data, outputs, data sources queried, and any human interventions
☐ Logs are tamper-evident and stored securely
☐ Deployer log retention processes established (minimum 6 months for Annex III systems under Article 26(5))
☐ Log format and coverage reviewed against system-specific requirements (e.g., biometric systems)
☐ Log access controls defined — logs available to market surveillance authorities on request
Requirement 5: Transparency to deployers (Article 13)
What the regulation requires
High-risk AI systems must be designed and developed in a way that ensures their operation is sufficiently transparent to enable deployers to interpret the system’s outputs and use them appropriately. Providers must supply deployers with instructions for use; a document that forms part of the technical documentation.
The instructions for use must include: the identity and contact details of the provider, the system’s capabilities and limitations, the intended purpose and foreseeable misuse scenarios, the level of accuracy and known performance limitations, the circumstances in which the system may produce results that require human intervention or special caution, hardware and software requirements, and information about any changes to the system that would require updating the instructions.
What this means in practice
Article 13 is primarily a provider obligation, but it shapes what deployers need to receive and retain. If you are deploying a third-party high-risk AI system, you should be checking that your provider has given you instructions for use that cover all of the Article 13 requirements, because your own Article 26 obligations depend partly on having been given adequate information by the provider.
If you are the provider, the instructions for use must be genuinely usable by a deployer who was not involved in building the system. Vague performance claims or generic limitations disclaimers will not satisfy Article 13.
Article 13 compliance checklist
☐ Instructions for use prepared and provided to deployers before or at the point of deployment
☐ Instructions cover: capabilities, limitations, intended purpose, foreseeable misuse
☐ Accuracy metrics and known performance degradation scenarios documented
☐ Conditions requiring human intervention or special caution identified
☐ Hardware and software requirements specified
☐ Update and change notification procedure described
☐ Instructions kept current and reissued following substantial modifications
Requirement 6: Human oversight (Article 14)
What the regulation requires
High-risk AI systems must be designed and developed in a way that allows for effective human oversight. The measures required to enable oversight must be built into the system by the provider, and must then be implemented by the deployer during actual operation.
The individuals responsible for oversight must be able to: fully understand the system’s capabilities and limitations; monitor the system’s operation and detect anomalies, malfunctions, and unexpected behaviour; disregard, override, or reverse the system’s output; and stop the system if needed via a halt function.
Article 14 acknowledges the challenge of automation bias; the tendency to over-rely on AI outputs. The oversight measures providers built into systems must specifically address this risk. For some systems (where outputs do not directly trigger or implement decisions affecting individuals), it may be sufficient to monitor at a system level rather than reviewing every individual output.
What this means in practice
Human oversight under Article 14 is one of the more operationally demanding requirements, because it sits at the boundary between what a provider builds and what a deployer implements. Providers must design override mechanisms, anomaly alerts, and halt functions into the system. Deployers must ensure qualified human reviewers are actually in place and trained to use them.
Deployers who use a high-risk AI system without implementing the oversight measures the provider has built in (or who override or ignore those mechanisms) will be in breach of their Article 26 obligations regardless of how well the system was designed.
Article 14 compliance checklist
☐ Human oversight measures designed into the system, not left to deployer policy alone
☐ Override and halt capabilities implemented and tested
☐ Anomaly detection and alert mechanisms in place
☐ Instructions for use specify who is responsible for oversight, what qualifications are needed, and what to monitor
☐ Automation bias risks identified and addressed in system design and deployer guidance
☐ Deployer has assigned qualified individuals to oversight roles
☐ Oversight procedures documented and staff trained
☐ Oversight logs maintained to demonstrate the function was exercised
Requirement 7: Accuracy, robustness, and cybersecurity (Article 15)
What the regulation requires
High-risk AI systems must achieve an appropriate level of accuracy, robustness, and cybersecurity throughout their lifecycle. Performance must be consistent and must not degrade in ways that create risks.
Robustness specifically includes resilience to errors, faults, inconsistencies, and unexpected inputs, whether accidental or adversarial. Systems must be able to handle technical failures, data anomalies, and out-of-distribution inputs without producing dangerous outputs. They must also be resilient to adversarial manipulation of inputs intended to alter the system’s behaviour (adversarial attacks).
Accuracy must be declared in the instructions for use, with the metrics used and the conditions under which they were measured. For systems that continue to learn after deployment, measures must be in place to ensure ongoing accuracy does not fall below the declared level; and that new learning does not introduce feedback loops or biases that create additional risks.
What this means in practice
Article 15 does not define a specific accuracy threshold, requirements are proportionate to the intended use and the risk the system poses. What the regulation does require is that you know what level of accuracy is appropriate, have tested for it, and have declared it honestly. A system deployed in a high-stakes context (credit scoring, medical diagnosis support, employment screening) is held to a higher standard than one in a lower-stakes setting, but the obligation to measure, document, and maintain performance applies regardless.
Cybersecurity under Article 15 should be read alongside the NIS2 Directive and, where relevant, the Cyber Resilience Act. For most organisations, existing security programmes will provide the foundation, but specific AI attack vectors such as model poisoning, inference attacks, and adversarial perturbations need explicit coverage.
Article 15 compliance checklist
☐ Accuracy levels defined, measured, and documented for the intended use scenario
☐ Accuracy metrics and measurement conditions declared in instructions for use
☐ Robustness tested against errors, faults, inconsistencies, and out-of-distribution inputs
☐ Adversarial attack resilience assessed and mitigations implemented
☐ Performance monitoring in place to detect accuracy degradation in operation
☐ For continuously learning systems: safeguards against feedback loops and post-deployment bias drift
☐ Cybersecurity measures applied, covering relevant AI-specific attack vectors
☐ Performance and security review cadence established and documented
Download the master checklist: all seven requirements
Submit your email below to get a 2-page PDF with all the high-risk requirements in one checklist.
Provider obligations versus deployer obligations: who owns what
The seven technical requirements in Articles 9–15 apply primarily to providers. But several of them depend on deployers to function in practice. The table below clarifies the split.
| Requirement | Provider’s obligation | Deployer’s obligation |
|---|---|---|
| Risk management (Art. 9) | Establish and maintain the system; document residual risks | Cooperate with provider; report issues affecting risk profile |
| Data governance (Art. 10) | Govern training, validation, and testing data | Not directly applicable unless deployer modifies the system |
| Technical documentation (Art. 11) | Prepare and maintain Annex IV documentation | Receive and retain provider documentation |
| Logging (Art. 12) | Design and implement automatic logging capability | Retain logs generated during operation (min. 6 months) |
| Transparency (Art. 13) | Prepare and provide instructions for use | Implement the system according to the instructions |
| Human oversight (Art. 14) | Build oversight measures into the system | Assign qualified persons; implement oversight measures |
| Accuracy and robustness (Art. 15) | Declare and achieve required performance levels | Monitor performance against declared levels; report degradation |
One critical point: under Article 25, a deployer who substantially modifies a high-risk AI system takes on provider obligations for the modified system. “Substantial modification” is not trivially defined, but changing the system’s intended purpose, retraining the model, or making changes that affect compliance with Articles 9–15 will typically trigger it.
What Deeploy covers in this framework
The Article 9–15 requirements describe a compliance challenge that operates at the intersection of legal obligation and operational infrastructure. Some of it lives in legal and documentation processes. Some of it lives in your MLOps stack.
Deeploy is built to address the operational side; the monitoring, logging, and documentation work that must happen continuously once a high-risk AI system is in production.
Specifically, Deeploy supports:
Logging and traceability (Article 12): Deeploy captures inference logs, input-output records, and model events automatically. Logs are stored in a structured, auditable format and retained according to configurable policies.
Performance monitoring (Article 15): Deeploy monitors model accuracy and performance metrics in production, alerting teams when performance degrades below defined thresholds. This supports both the Article 15 accuracy obligation and the post-market monitoring requirement under Article 72.
Data drift detection (Articles 10 and 15): Deeploy detects distributional shifts between production data and training data; a key signal for both data governance compliance and ongoing robustness.
Human oversight support (Article 14): Deeploy provides monitoring dashboards and anomaly alerts that give oversight personnel the visibility they need to identify unexpected behaviour and intervene.
Documentation support (Articles 9 and 11): Deeploy maintains model cards and deployment records that support technical documentation requirements and provide an audit trail for the risk management system.
What Deeploy does not replace: legal review, conformity assessment, the preparation of Annex IV documentation, or the organisational processes (training, governance structures, oversight role assignment) that Articles 9–15 also require.
Compliance is a shared responsibility between your legal, compliance, and engineering teams; Deeploy gives the engineering and MLOps side the infrastructure it needs to do its part.
Frequently asked questions
There are two routes to high-risk classification. Under Article 6(1), an AI system that is a safety component of a product covered by EU harmonised legislation (such as medical devices or machinery) is high-risk, provided its failure or malfunction would endanger health or safety. Following the Digital Omnibus, AI used solely for non-safety purposes, such as user assistance, optimisation, service efficiency, automation, convenience, or non-safety quality control, no longer qualifies under this route.
Under Article 6(2), standalone AI systems listed in Annex III are high-risk. Annex III covers eight sectors: biometric identification, critical infrastructure, education, employment, essential services, law enforcement, migration and asylum, and administration of justice.
Under Article 26, deployers must: use the system in accordance with the provider's instructions for use; assign a human oversight person with the authority and capability to intervene; monitor the system's operation; inform employees or their representatives where AI is used in the workplace; conduct a Fundamental Rights Impact Assessment where required; keep logs for the periods specified; and report serious incidents to the relevant authority.
A conformity assessment is the process by which a provider of a high-risk AI system demonstrates that the system meets the Act's requirements before placing it on the market. For most Annex III systems, providers can conduct a self-assessment based on internal documentation. Third-party assessment by a notified body is required for biometric identification systems and AI systems used as safety components of Annex I regulated products.
Annex IV of the Act specifies eleven mandatory documentation elements, including: a general description of the system and its intended purpose; a description of the development process; details of training, validation, and testing data; the risk management measures applied; the human oversight measures built in; performance metrics and known limitations; and post-market monitoring arrangements.
CE marking is required for high-risk AI systems that are either safety components of Annex I regulated products or standalone systems as listed in Annex III. The CE mark indicates conformity with the EU AI Act's requirements. Before affixing it, providers must complete the conformity assessment and sign a declaration of conformity.
Deployers must retain automatically generated logs for at least six months. Providers must retain technical documentation for ten years after the system is placed on the market. These periods may overlap with GDPR retention obligations and should be reconciled in your data governance policy.
