High-risk AI systems carry the most extensive compliance obligations in the EU AI Act. The obligations span the entire lifecycle of the system, from design and development through market placement, deployment, and post-market operation. They fall on two distinct categories of operator: providers, who develop and place systems on the market, and deployers, who use those systems in a professional context.
This guide sets out every obligation in the high-risk framework, the legal basis for each, the practical steps required to meet it, and the current position under the Digital Omnibus proposals where those proposals affect the obligation. It covers the requirements as they stand under Regulation (EU) 2024/1689 as published, together with the Commission guidance issued through May 2026.
Before reading this guide, two preliminary determinations are required. First, your system must be classified as high-risk under Article 6. Second, your role as provider, deployer, or both must be established under Articles 3 and 25. The obligations set out below apply only once those determinations have been made. Classification and role determination are covered in separate guides in this series.
Key Definitions
| Term | Definition | Legal basis |
|---|---|---|
| High-risk AI system | An AI system listed in Annex III or forming a safety component of an Annex I regulated product requiring third-party conformity assessment | Article 6 |
| Provider | A natural or legal person that develops a high-risk AI system and places it on the market or puts it into service under its own name | Article 3(3) |
| Deployer | A natural or legal person that uses a high-risk AI system under its own authority in a professional context | Article 3(4) |
| Intended purpose | The use for which a high-risk AI system is intended by the provider, including the specific context and conditions of use | Article 3(12) |
| Reasonably foreseeable misuse | Use of a high-risk AI system in a way not intended by the provider but which may result from reasonably foreseeable human behaviour | Article 9(2)(b) |
| Substantial modification | A change to the high-risk AI system that affects its compliance with the Act or changes its intended purpose | Article 3(23) |
| Serious incident | An incident or malfunctioning of a high-risk AI system that directly or indirectly leads to death, serious harm to health, serious damage to property, or serious disruption to critical infrastructure | Article 3(49) |
| Post-market monitoring | A systematic process to collect and review experience from high-risk AI systems placed on the market | Article 3(26) |
High-Risk Obligation Map
| Obligation | Provider | Deployer | Legal basis | Application date |
|---|---|---|---|---|
| Risk management system | Yes | No | Article 9 | 2 August 2026 |
| Data governance | Yes | No | Article 10 | 2 August 2026 |
| Technical documentation | Yes | No | Article 11, Annex IV | 2 August 2026 |
| Record-keeping and logging | Yes | Yes | Articles 12, 26(6) | 2 August 2026 |
| Transparency and instructions for use | Yes | No | Article 13 | 2 August 2026 |
| Human oversight | Yes (design) | Yes (implementation) | Article 14 | 2 August 2026 |
| Accuracy, robustness, cybersecurity | Yes | No | Article 15 | 2 August 2026 |
| Quality management system | Yes | No | Article 17 | 2 August 2026 |
| Documentation keeping | Yes | No | Article 18 | 2 August 2026 |
| Automatically generated logs | Yes | Yes | Articles 19, 26(6) | 2 August 2026 |
| Corrective actions | Yes | No | Article 20 | 2 August 2026 |
| Cooperation with authorities | Yes | Yes | Articles 21, 26(5) | 2 August 2026 |
| Conformity assessment | Yes | No | Article 43 | 2 August 2026 |
| Declaration of Conformity | Yes | No | Article 47 | 2 August 2026 |
| CE marking | Yes | No | Article 48 | 2 August 2026 |
| Registration | Yes | Yes (some) | Article 49 | 2 August 2026 |
| Authorised Representative | Yes (non-EU) | No | Article 22 | 2 August 2026 |
| Post-market monitoring | Yes | Yes (reporting) | Article 72 | 2 August 2026 |
| Serious incident reporting | Yes | Yes | Articles 73, 26(5) | 2 August 2026 |
| AI literacy | Yes | Yes | Article 4 | 2 February 2025 |
| Fundamental Rights Impact Assessment | No | Yes (Annex III) | Article 27 | 2 August 2026 |
| Individual notification | No | Yes | Article 26(8) | 2 August 2026 |
1. Risk Management System
Article 9(1) states: “A risk management system shall be established, implemented, documented and maintained in relation to high-risk AI systems.”
The risk management system is the foundation of provider compliance. Every other technical and documentation obligation connects back to it. The system must be a continuous, iterative process running across the entire lifecycle of the AI system, not a one-time assessment completed before market placement.
What Article 9 Requires
Article 9(2) specifies that the risk management system must cover the identification and analysis of known and reasonably foreseeable risks that the high-risk AI system may pose to health, safety, or fundamental rights. It must estimate and evaluate risks that may emerge from the intended use and from reasonably foreseeable misuse. It must evaluate risks based on data gathered from post-market monitoring.
Article 9(4) requires providers to adopt risk management measures, giving priority to measures that eliminate or reduce risks through design and development, then mitigation and control measures for risks that cannot be eliminated, and finally information to deployers. Residual risks must be communicated in the instructions for use.
| Risk management system component | What is required | Legal basis |
|---|---|---|
| Risk identification | Identify and analyse all known and reasonably foreseeable risks to health, safety, and fundamental rights | Article 9(2)(a) |
| Risk estimation | Estimate and evaluate risks arising from intended use and reasonably foreseeable misuse | Article 9(2)(b) |
| Risk evaluation | Evaluate risks based on post-market monitoring data throughout the lifecycle | Article 9(2)(c) |
| Risk treatment | Adopt appropriate risk management measures, prioritising design-based elimination | Article 9(4) |
| Testing for risk | Test the system against the defined risk management measures before market placement | Article 9(6) |
| Residual risk communication | Document residual risks in the instructions for use provided to deployers | Article 9(4)(c) |
| Lifecycle review | Review and update the risk management system throughout the system’s lifecycle | Article 9(9) |
Article 9(6) states: “High-risk AI systems shall be tested for the purpose of identifying the most appropriate and targeted risk management measures. Testing shall ensure that high-risk AI systems perform consistently for their intended purpose and that they are in compliance with the requirements set out in this Section.”
Interaction with Standards
Where harmonised standards are available and the provider complies with them, Article 40 provides a presumption of conformity with the requirements of the Act covered by those standards. As of May 2026, the primary harmonised standards for high-risk AI systems remain in development under CEN/CENELEC JTC 21. ISO 42001 on AI management systems provides relevant international reference material referenced by practitioners in the interim.
2. Data Governance
Article 10(1) states: “High-risk AI systems which make use of techniques involving the training of models with data shall be developed on the basis of training, validation and testing data sets that meet the quality criteria referred to in paragraphs 2 to 5.”
Data governance is one of the most operationally demanding obligations in the high-risk framework. It applies to providers who train models on data. Providers using pre-trained models without further training on their own datasets must still address data governance in relation to the data used during validation and testing.
Data Quality Requirements
Article 10(2) sets out the criteria that training, validation, and testing datasets must meet. They must be subject to appropriate data governance and management practices. They must be relevant, sufficiently representative, and to the best extent possible free of errors and complete with respect to the intended purpose. They must have appropriate statistical properties. They must take into account the characteristics or elements particular to the specific geographical, contextual, behavioural, or functional setting within which the high-risk AI system is intended to be used.
| Data governance requirement | What is required | Legal basis |
|---|---|---|
| Data governance practices | Establish design choices, data collection methods, data preparation, and data labelling practices | Article 10(2)(a)-(f) |
| Representativeness | Ensure datasets are sufficiently representative of the population the system will affect | Article 10(2)(b) |
| Error minimisation | Identify and address errors, gaps, and inconsistencies in datasets | Article 10(2)(c) |
| Bias examination | Examine datasets for possible biases that could affect fundamental rights | Article 10(2)(f) |
| Statistical properties | Define appropriate statistical properties including representativeness of subgroups where relevant | Article 10(2)(e) |
| Special category data | Address the use of special category personal data under GDPR Article 9 where used for bias detection | Article 10(5) |
Article 10(3) states that training, validation, and testing datasets “shall take into account, to the extent required by the intended purpose, the characteristics or elements that are particular to the specific geographical, contextual, behavioural or functional setting within which the high-risk AI system is intended to be used.”
Article 10(5) provides a limited basis for processing special category personal data for the purpose of detecting and correcting biases in high-risk AI systems, subject to appropriate safeguards. This provision operates alongside, and does not override, GDPR requirements.
Practical Data Governance Steps
The data governance obligation requires providers to document the entire data pipeline. This includes the source and collection methodology for training data, the criteria applied to determine data quality, the labelling methodology and quality controls, the validation approach, the testing approach and results, and the steps taken to identify and address bias in the dataset. All of this must be reflected in the technical documentation.
3. Technical Documentation
Article 11(1) states: “The technical documentation of a high-risk AI system shall be drawn up before that system is placed on the market or put into service and shall be kept up to date.”
Technical documentation is both a standalone obligation and the evidential basis for demonstrating conformity with every other requirement in the high-risk framework. It must be produced before market placement and maintained throughout the system’s lifecycle.
What Annex IV Requires
Annex IV of the Act specifies the content of technical documentation in detail. The documentation must cover:
| Annex IV section | Content required |
|---|---|
| General description | Description of the AI system including its intended purpose, version history, interaction with hardware and software, and deployment form |
| Design and development | Description of the methods and steps used in development, design choices and underlying logic, training methodologies, and validation and testing procedures |
| System architecture | Diagram of system architecture showing how software components interact |
| Computational resources | Description of computational resources used to develop, train, and test the system |
| Data requirements | Description of training methodologies and techniques, training datasets and their characteristics, data governance practices, and pre-processing steps |
| Risk management | Description of the risk management system and the measures taken |
| Accuracy and performance metrics | Metrics used to measure accuracy, robustness, and other relevant performance indicators |
| Testing results | Results of testing including pre-market testing and testing for relevant known or reasonably foreseeable risks |
| Standards applied | List of harmonised standards applied and, where standards not applied, solutions adopted to satisfy requirements |
| EU Declaration of Conformity | Copy of the EU Declaration of Conformity |
| Intended purpose description | Instructions for use and description of intended purpose |
Article 11(3) empowers the Commission to adopt implementing acts specifying simplified technical documentation requirements for SMEs. As of May 2026, the Commission has not yet adopted such implementing acts, though the Digital Omnibus proposals reinforce the intention to do so.
Documentation Maintenance
Technical documentation is not a document produced once. Article 11(1) requires it to be kept up to date throughout the system’s lifecycle. Any change to the system, its intended purpose, or the context of its deployment that affects its compliance with the Act’s requirements must be reflected in updated technical documentation. A substantial modification under Article 3(23) requires the documentation to be redrawn as if for a new system.
4. Record-Keeping and Automatic Logging
Articles 12 and 19 require high-risk AI systems to enable automatic logging of events relevant to compliance. Article 26(6) requires deployers to retain logs generated during their operation of the system.
Provider Obligations on Logging
Article 12(1) states: “High-risk AI systems shall technically allow for the automatic recording of events (‘logs’) over the lifetime of the system.”
Article 19(1) states: “Providers of high-risk AI systems shall keep the logs automatically generated by their high-risk AI systems, to the extent such logs are under their control. Without prejudice to applicable Union or national law, the logs shall be kept for a period of at least six months, unless provided otherwise by applicable Union or national law or Union or national law applicable to the operator.”
The logging requirement is a technical design obligation as well as a data retention obligation. The system must be built to generate the logs that are required. Providers cannot retrospectively add logging capabilities after deployment.
What Logs Must Capture
Article 12(2) specifies that logging must capture, at a minimum: the period of each use of the system, 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 the verification. These specifics apply to biometric identification systems. For other high-risk systems, logging requirements are calibrated to the intended purpose and the risks involved.
Deployer Obligations on Log Retention
Article 26(6) states: “Deployers of high-risk AI systems shall keep the logs automatically generated by that high-risk AI system to the extent such logs are under their control for a period of at least 6 months, unless provided otherwise by applicable Union or national law or Union or national law applicable to the deployer.”
Log retention by deployers serves a specific enforcement function. When a national competent authority investigates an incident, the logs held by the deployer provide the primary evidentiary record of how the system was used and what decisions it generated or influenced.
5. Transparency and Instructions for Use
Article 13(1) states: “High-risk AI systems shall be designed and developed in such a way as to ensure that their operation is sufficiently transparent to enable deployers to interpret the system’s output and use it appropriately.”
Transparency under Article 13 is a technical design requirement, not merely a disclosure obligation. The system must be designed to produce outputs that a competent deployer can interpret and act on appropriately.
Instructions for Use
Article 13(3) requires providers to supply deployers with instructions for use in an appropriate digital format. The instructions must cover the identity and contact details of the provider, the characteristics and capabilities of the system including its intended purpose and limitations, changes to the system covered by the conformity assessment, the level of accuracy and the relevant accuracy metrics, the data requirements for correct operation, the expected lifetime of the system, the maintenance and care required, and the human oversight measures required.
| Instructions for use content | What must be included | Legal basis |
|---|---|---|
| Provider identity | Name, registered trade name, address, and contact details | Article 13(3)(a) |
| System characteristics | Intended purpose, level of accuracy, and known limitations | Article 13(3)(b) |
| Performance metrics | Accuracy metrics and their meaning for specific persons or groups | Article 13(3)(b)(ii) |
| Input data | Specifications on the form and nature of data required for correct operation | Article 13(3)(b)(iii) |
| Operational conditions | Conditions under which the system can be expected to perform as intended | Article 13(3)(b)(iv) |
| Human oversight | Measures required to enable human oversight, including technical means | Article 13(3)(b)(v) |
| Lifetime and maintenance | Expected operational lifetime and maintenance requirements | Article 13(3)(b)(vi) |
| Residual risks | Description of residual risks that cannot be eliminated through design | Article 13(3)(b)(vii) |
| Changes covered | Specification of changes covered by the conformity assessment | Article 13(3)(c) |
6. Human Oversight
Article 14(1) states: “High-risk AI systems shall 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 the AI system is in use.”
Human oversight is both a design obligation on providers and an implementation obligation on deployers. The Act requires the capability to be built into the system and requires deployers to actually exercise it.
Provider Obligations on Human Oversight Design
Article 14(3) specifies that the system must be designed and developed with measures enabling those responsible for oversight to understand the capabilities and limitations of the system, detect and address anomalies, interpret outputs correctly, decide not to use the system or to override its output, and intervene or interrupt the system through a stop function where necessary.
| Human oversight design requirement | What is required | Legal basis |
|---|---|---|
| Capability visibility | System enables oversight persons to understand what the system can and cannot do | Article 14(3)(a) |
| Anomaly detection | System enables detection of anomalies, dysfunctions, and unexpected performance | Article 14(3)(b) |
| Output interpretation | System outputs are interpretable and presented in a way enabling correct assessment | Article 14(3)(c) |
| Override capability | Oversight persons can decide not to use the system or override its outputs | Article 14(3)(d) |
| Intervention capability | Oversight persons can intervene or interrupt the system through a stop function | Article 14(3)(e) |
Deployer Obligations on Human Oversight Implementation
Article 26(1) states: “Deployers shall take appropriate technical and organisational measures to ensure they use high-risk AI systems as intended and in accordance with the respective instructions for use.”
Article 26(4) states: “Deployers shall assign the monitoring of the functioning of the high-risk AI system to natural persons who have the necessary competence, training and authority, as well as the necessary support.”
Human oversight by deployers is not satisfied by nominally assigning a staff member to monitor AI outputs. The oversight person must have genuine competence, genuine authority to act on their assessment, and genuine access to the intervention mechanisms the system provides. Deployers who assign oversight to staff without the competence to exercise it meaningfully, or without authority to override AI outputs, are not meeting the Article 26 standard.
7. Accuracy, Robustness, and Cybersecurity
Article 15(1) states: “High-risk AI systems shall be designed and developed in such a way that they achieve an appropriate level of accuracy, robustness, and cybersecurity, and that they perform consistently in those respects throughout their lifecycle.”
Accuracy
Article 15(2) requires providers to declare the levels of accuracy for the high-risk AI system and the relevant accuracy metrics in the instructions for use. Accuracy must be measured against the specific intended purpose and the population the system is designed to affect. A system performing accurately on average but inaccurately for particular demographic groups does not meet the Article 15 standard if those groups are within the intended scope of the system.
Robustness
Article 15(3) states: “High-risk AI systems shall be resilient as regards errors, faults or inconsistencies that may occur within the system or the environment in which the system operates, in particular when interacting with natural persons or other systems.” The system must behave predictably when inputs vary, when the operating environment changes, or when adversarial inputs are introduced.
Cybersecurity
Article 15(5) states: “High-risk AI systems shall be resilient against attempts by unauthorised third parties to alter their use, outputs or performance by exploiting the system vulnerabilities.” Providers must address the specific cybersecurity risks associated with AI systems, including data poisoning, model poisoning, adversarial examples, and model theft. Where a high-risk AI system is also covered by the Cyber Resilience Act or the NIS2 Directive, those requirements apply in addition to Article 15.
| Requirement | What is required | Legal basis |
|---|---|---|
| Accuracy declaration | Declare accuracy levels and metrics in instructions for use | Article 15(2) |
| Consistency | Achieve consistent performance throughout the system lifecycle | Article 15(1) |
| Error resilience | System performs consistently despite errors, faults, or inconsistencies in inputs | Article 15(3) |
| Fallback plans | Implement technical fallback plans where errors cannot be prevented | Article 15(3) |
| Cybersecurity architecture | Design the system to resist attacks targeting training data, outputs, and model parameters | Article 15(5) |
8. Quality Management System
Article 17(1) states: “Providers of high-risk AI systems shall put in place a quality management system that ensures compliance with this Regulation. That system shall be documented in a systematic and orderly manner in the form of written policies, procedures and instructions.”
The quality management system is the organisational framework that holds all other obligations together. It must cover every stage of the AI system lifecycle and be maintained throughout the period during which the system is on the market.
What the QMS Must Cover
| QMS component | What must be addressed | Legal basis |
|---|---|---|
| Regulatory compliance strategy | Overall approach to achieving and maintaining compliance | Article 17(1)(a) |
| Design and development procedures | Procedures for examining, testing, and validating the system before market placement | Article 17(1)(b) |
| Development and quality control procedures | Techniques and processes used in development and quality assurance | Article 17(1)(c) |
| Examination, testing, and validation | Pre-market and ongoing validation procedures | Article 17(1)(d) |
| Technical standards | Standards applied and procedures for ensuring compliance where standards are not applied | Article 17(1)(e) |
| Data management | Systems and procedures for data management including collection, processing, and storage | Article 17(1)(f) |
| Risk management system | Reference to and integration with the Article 9 risk management system | Article 17(1)(g) |
| Post-market monitoring | System and plan for post-market monitoring under Article 72 | Article 17(1)(h) |
| Incident reporting | Procedures for reporting serious incidents under Article 73 | Article 17(1)(i) |
| Communication | Procedures for communicating with authorities, deployers, and other operators | Article 17(1)(j) |
| Documentation systems | Systems for creating, updating, and retaining all required documentation | Article 17(1)(k) |
| Resource management | Management of resources required to maintain the QMS | Article 17(1)(l) |
| Accountability | Roles and responsibilities of management in ensuring compliance | Article 17(1)(m) |
ISO 42001, the international standard on AI management systems, provides a recognised framework that maps closely to the Article 17 requirements. Providers implementing ISO 42001 as the basis of their QMS will satisfy many of the structural requirements, though they must supplement it to address the specific EU AI Act obligations not covered by the standard.
9. Conformity Assessment
Article 43(1) states: “Before placing a high-risk AI system on the market or putting it into service, providers shall ensure that the system has been subject to a conformity assessment in accordance with this Article.”
Conformity assessment is the process by which a provider demonstrates that their high-risk AI system meets the requirements of Chapter III, Section 2 of the Act. The procedure varies depending on whether the system requires third-party assessment by a notified body or whether the provider can conduct a self-assessment.
Self-Assessment versus Third-Party Assessment
| System type | Assessment procedure | Who conducts it |
|---|---|---|
| Annex III high-risk systems (most categories) | Internal control procedure based on Annex VI | Provider (self-assessment) |
| Annex III biometric identification systems | Third-party conformity assessment by notified body OR internal control based on Annex VI with conditions | Notified body or provider |
| Annex I product-embedded systems | Conformity assessment procedure applicable to the Annex I product under sector legislation | Notified body (as required by sector legislation) |
| Systems subject to harmonised standards | Internal control with presumption of conformity | Provider |
Article 43(4) states that for high-risk AI systems already covered by harmonised standards or common specifications, providers may demonstrate conformity through compliance with those standards or specifications, which creates a presumption of conformity under Article 40.
What Conformity Assessment Produces
Completion of conformity assessment results in the provider drawing up an EU Declaration of Conformity under Article 47 and affixing CE marking under Article 48. Both are preconditions for market placement. The Declaration of Conformity must be kept for 10 years after the system is placed on the market or put into service.
Article 47(1) states: “Providers of high-risk AI systems shall draw up a written EU declaration of conformity for each high-risk AI system and keep it at the disposal of the national competent authorities for a period of 10 years after the high-risk AI system has been placed on the market or put into service.”
10. Registration
Article 49(1) states: “Before placing on the market or putting into service a high-risk AI system listed in Annex III, the provider or, where applicable, the authorised representative shall register themselves and their system in the EU database referred to in Article 71.”
Registration in the EU database is a precondition for market placement for Annex III high-risk systems. The EU database is publicly accessible for most categories, enabling downstream operators, deployers, and affected individuals to access information about high-risk AI systems in use.
What Must Be Registered
| Registration information | Who provides it | Legal basis |
|---|---|---|
| Provider name and contact details | Provider | Annex VIII, Section A |
| Authorised representative details | Provider or authorised representative | Annex VIII, Section A |
| System name, version, and description | Provider | Annex VIII, Section A |
| Intended purpose | Provider | Annex VIII, Section A |
| Countries where system is placed on market | Provider | Annex VIII, Section A |
| Conformity assessment details | Provider | Annex VIII, Section A |
| Declaration of Conformity reference | Provider | Annex VIII, Section A |
Article 49(2) addresses the Article 6(3) exception. Where a provider determines that their Annex III system does not pose a significant risk of harm under Article 6(3) and therefore should not be treated as high-risk, they must register that determination in the EU database with a brief statement of the reasons.
11. Provider and Deployer Duties: High-Risk Obligations Compared
Provider Post-Market Duties
Once a high-risk AI system is on the market, providers carry ongoing obligations that extend throughout the system’s operational lifetime.
Article 72(1) states: “Providers of high-risk AI systems which are placed on the Union market shall follow up on the performance of their high-risk AI systems that are placed on the market or put into service, for the purpose of identifying the need for any corrective or preventive action.”
| Post-market provider obligation | What is required | Legal basis |
|---|---|---|
| Post-market monitoring plan | Establish a plan setting out the methods, frequency, and scope of monitoring | Article 72(3) |
| Performance data collection | Collect data from deployers and users to monitor system performance | Article 72(1) |
| Risk reassessment | Reassess risks identified through post-market monitoring and update risk management measures | Article 72(1) |
| Serious incident reporting | Report serious incidents and malfunctions to national market surveillance authorities without undue delay | Article 73(1) |
| 15-day reporting window | Report serious incidents within 15 days of becoming aware, or 10 days if a risk to life is involved | Article 73(2) |
| Corrective action | Take immediate corrective action where a system poses a risk, including withdrawal from market if necessary | Article 20(1) |
| Authority notification | Notify competent authorities and deployers in all member states where the system has been placed on market | Article 20(2) |
Deployer Duties
Article 26 sets out the full set of obligations applicable to deployers of high-risk AI systems. These obligations are independent of the provider’s compliance. A deployer cannot satisfy Article 26 by pointing to the provider’s EU Declaration of Conformity.
| Deployer obligation | What is required | Legal basis |
|---|---|---|
| Technical and organisational measures | Implement measures ensuring the system is used as intended | Article 26(1) |
| Provider instructions | Use the system in accordance with the provider’s instructions for use | Article 26(3) |
| Staff competence | Assign oversight and operation to staff with necessary competence and authority | Article 26(4) |
| Risk monitoring | Monitor operation for risks and report anomalies to provider | Article 26(5) |
| Incident reporting | Report serious incidents to the provider and, where required, to national authorities | Article 26(5) |
| Log retention | Retain automatically generated logs for at least six months | Article 26(6) |
| Data protection coordination | Conduct data protection impact assessment under GDPR where personal data is processed | Article 26(9) |
| Individual notification | Inform natural persons subject to the high-risk AI system that they are subject to it | Article 26(8) |
| Fundamental Rights Impact Assessment | Conduct FRIA before deployment of Annex III systems | Article 27 |
The Fundamental Rights Impact Assessment
Article 27(1) states: “Prior to deploying a high-risk AI system listed in Annex III, with the exception of high-risk AI systems listed in points 1, 6 and 7 of that Annex, deployers that are bodies governed by public law, or private entities providing public services, and deployers of high-risk AI systems referred to in point 5(b) of Annex III, shall perform a fundamental rights impact assessment for the systems covered by those rules.”
The FRIA requires deployers to document the intended use of the system, the period and frequency of use, the categories of natural persons affected, the specific risks of harm to fundamental rights, the measures taken to address those risks, and the human oversight arrangements in place.
| FRIA component | What must be documented | Legal basis |
|---|---|---|
| Intended use description | Precise description of how and for what purpose the system will be used | Article 27(2)(a) |
| Deployment period | Start date and duration or frequency of deployment | Article 27(2)(b) |
| Affected persons | Categories of natural persons and groups subject to the system | Article 27(2)(c) |
| Specific risks | Risks of harm to fundamental rights of affected persons | Article 27(2)(d) |
| Mitigation measures | Measures taken to address identified fundamental rights risks | Article 27(2)(e) |
| Oversight arrangements | Human oversight measures and accountability structures | Article 27(2)(f) |
| Responsible persons | Roles within the organisation responsible for the FRIA and for compliance | Article 27(2)(g) |
12. Authorised Representative for Non-EU Providers
Article 22(1) states: “Prior to making their high-risk AI systems available on the Union market, providers established in third countries shall, by written mandate, appoint an authorised representative which is established in the Union.”
Non-EU providers of high-risk AI systems must appoint an EU-established Authorised Representative before the system is made available on the EU market. This obligation applies from 2 August 2026. Appointment after market placement does not remedy the prior breach.
Authorised Representative Obligations
| Obligation | What is required | Legal basis |
|---|---|---|
| Mandate availability | Provide a copy of the mandate to market surveillance authorities upon request | Article 22(3) |
| Documentation verification | Verify that technical documentation and Declaration of Conformity are correctly prepared | Article 22(3)(a) |
| Record retention | Keep technical documentation, Declaration of Conformity, and certificate for 10 years | Article 22(3)(b) |
| Authority cooperation | Provide authorities with all documentation necessary to demonstrate compliance on request | Article 22(3)(c) |
| Risk cooperation | Cooperate with competent authorities to reduce and mitigate risks | Article 22(3)(d) |
| Registration | Comply with registration obligations under Article 49 where the provider has not done so | Article 22(3)(e) |
| Mandate termination | Terminate the mandate and immediately notify the relevant market surveillance authority if the provider acts contrary to the Act | Article 22(4) |
13. The Digital Omnibus: Current Position on High-Risk AI Requirements
The Digital Omnibus package, published by the Commission in February 2025, proposes amendments to the EU AI Act affecting the high-risk AI framework. As of May 2026, the proposals remain under negotiation between Parliament and Council and have not been adopted. The obligations set out in this guide reflect the current law, not the proposed amendments.
The following proposals are relevant to the high-risk AI framework:
| Digital Omnibus proposal | Current rule | Proposed change | Status |
|---|---|---|---|
| High-risk AI application timeline | Fixed date of 2 August 2026 | Maximum 16 months from availability of harmonised standards | Under negotiation |
| SME technical documentation | Standard Annex IV requirements apply | Commission empowered to adopt simplified requirements for SMEs | Reinforced in proposals; implementing acts not yet adopted |
| FRIA scope | Applies to public bodies and private entities providing public services | Proposals to clarify and potentially simplify scope | Under negotiation |
| AI system definition | Current OECD-based definition | Proposed narrowing to exclude certain traditional software | Under negotiation |
| Deployer obligations proportionality | Article 26 applies uniformly | Additional proportionality measures for deployers in lower-risk contexts within Annex III | Under negotiation |
The Commission’s stated rationale for the timeline adjustment is that harmonised standards under CEN/CENELEC JTC 21 have developed more slowly than anticipated, leaving providers without clear technical benchmarks for conformity assessment. This is a genuine practical difficulty. It does not, however, affect the legal deadline as it currently stands.
Providers and deployers should structure compliance programmes against the current 2 August 2026 deadline. If the Digital Omnibus adjustments are adopted before that date, transition arrangements will be addressed in the adopting legislation. Planning on the basis that the deadline will move is not a sound compliance approach.
Frequently Asked Questions
We use a high-risk AI system from a vendor who has provided an EU Declaration of Conformity. Are we compliant?
The Declaration of Conformity covers the vendor’s obligations as provider. It does not satisfy your obligations as deployer. You must independently implement human oversight measures, conduct a Fundamental Rights Impact Assessment if you fall within Article 27 scope, retain operational logs for six months, inform affected individuals of the system’s use, and assign competent staff to monitor operation. The vendor’s conformity documentation is relevant to your due diligence but does not transfer compliance to you.
What is the difference between the risk management system and the quality management system?
The risk management system under Article 9 is a technical and analytical process. It identifies, estimates, evaluates, and mitigates risks that the AI system may pose. The quality management system under Article 17 is an organisational framework. It governs how the provider ensures compliance with all requirements across the system lifecycle, of which the risk management system is one component. The QMS references and integrates the risk management system but covers much more, including development procedures, data management, post-market monitoring, and incident reporting.
Our system was placed on the market in early 2026. Do we still need to complete conformity assessment before August 2026?
Yes. Article 43(1) requires conformity assessment to be completed before the system is placed on the market. The August 2026 date is the universal application date for high-risk AI obligations, not a deadline by which conformity assessment must be completed for systems already on the market. Systems placed on the market after the obligations apply must have completed conformity assessment before placement. Systems placed on the market before August 2026 and remaining there after that date must comply with all provider obligations by August 2026 unless the transitional provisions in Article 111 apply.
How long must we retain technical documentation?
Article 18(1) states that providers must retain technical documentation and quality management system documentation for 10 years after the high-risk AI system is placed on the market or put into service. If the system is placed on the market in August 2026, documentation must be retained until at least August 2036. This retention obligation is independent of whether the provider continues to support or sell the system.
We are a deployer. Our vendor has not provided instructions for use. What do we do?
Article 13(3) requires providers to supply instructions for use. If a vendor has not provided them, you should request them formally and document the request. Operating a high-risk AI system without instructions for use prevents you from meeting your Article 26 obligations, including implementing appropriate human oversight and using the system as intended. You should not deploy a high-risk AI system without the documentation the Act requires the provider to supply.
What constitutes a serious incident requiring reporting under Article 73?
Article 3(49) defines a serious incident as an incident or malfunctioning of a high-risk AI system that directly or indirectly leads to the death of a person, serious harm to the health of a person, a serious and irreversible disruption to the provision of an essential service, a breach of obligations under Union law protecting fundamental rights, or serious damage to property or the environment. Providers must report such incidents to the relevant national market surveillance authority within 15 days of becoming aware, or 10 days where the incident involves a risk to life.
Our system does not use training data. Do the data governance requirements apply?
Article 10(1) applies to “high-risk AI systems which make use of techniques involving the training of models with data.” If your system does not use model training techniques, Article 10 data governance requirements do not apply in the same form. However, you must still address data quality in your technical documentation and risk management system if your system processes data during operation, and the accuracy and robustness requirements under Article 15 apply regardless of whether training data is used.
Can we rely on ISO 42001 to satisfy the quality management system requirement?
ISO 42001 provides a recognised framework that maps closely to the Article 17 requirements. Implementing ISO 42001 will satisfy many of the structural QMS requirements, but providers must supplement it to address EU AI Act-specific obligations not covered by the standard, including the specific documentation requirements of Annex IV, the Article 9 risk management framework, and the incident reporting obligations under Article 73. ISO 42001 certification does not create a presumption of conformity with Article 17, as no harmonised standard has been published for this purpose as of May 2026.
What happens if the Digital Omnibus adjusts the August 2026 deadline after we have already completed our compliance work?
If the Digital Omnibus adjustments are adopted and extend the application timeline, the adopting legislation will set out transitional arrangements. Providers who have already completed conformity assessment, technical documentation, and QMS implementation will not be required to repeat that work. Early compliance does not create a disadvantage. It removes execution risk and positions providers to place their systems on the EU market immediately when the obligations apply, regardless of the final date.
This guide reflects the text of Regulation (EU) 2024/1689 as published in the Official Journal on 12 July 2024, the Digital Omnibus proposals published in February 2025, and applicable guidance issued by the European AI Office through May 2026. It is published for general informational purposes and does not constitute legal advice. Providers and deployers of high-risk AI systems should obtain advice specific to their products, operations, and regulatory context.
