Chapter 7: High-Risk Provider — What Providers Must Do
The Provider’s Role in the Compliance Ecosystem
Providers carry the heaviest burden under the EU AI Act, and deliberately so. The provider is the entity that designs, develops, and places the AI system on the market. The provider makes the foundational decisions — what data to train on, what architecture to use, what safeguards to build in, what the system’s intended purpose is. Because these decisions shape everything that follows, the law holds the provider accountable for getting them right.
Deployer obligations, as covered in Chapter 6, are largely about responsible use. Provider obligations are about responsible creation. The two are designed to work together: the provider builds a system that is safe, transparent, and well-documented; the deployer uses it properly, monitors it, and maintains human oversight.
If the provider fails — if the system is poorly designed, inadequately tested, or insufficiently documented — the deployer’s ability to comply is undermined. This is why the AI Act places the primary compliance burden on providers and gives deployers the right to receive comprehensive documentation and support.
Overview of Provider Obligations
Provider obligations for high-risk AI systems are primarily defined in Articles 8 through 21, with Article 16 providing the central list. They can be grouped into four phases of the AI system lifecycle:
Phase 1: Design and development — Risk management, data governance, technical performance, human oversight design.
Phase 2: Before placing on the market — Technical documentation, conformity assessment, CE marking, EU database registration.
Phase 3: Deployment support — Instructions for use, transparency, deployer support.
Phase 4: Post-market — Monitoring, incident reporting, corrective action, quality management.
Phase 1: Design and Development
Risk Management System (Article 9)
What the law requires: Providers must establish, implement, document, and maintain a risk management system throughout the entire lifecycle of the high-risk AI system. This system must be a continuous iterative process planned and run throughout the lifecycle, requiring regular systematic review and updating.
What this means in practice: Before you write a single line of code, you need a systematic process for identifying what could go wrong with your AI system and how to prevent it. The risk management system must identify and analyse the known and reasonably foreseeable risks that the system may pose to health, safety, or fundamental rights, estimate and evaluate the risks that may emerge when the system is used in accordance with its intended purpose and under conditions of reasonably foreseeable misuse, evaluate risks based on data gathered from post-market monitoring, and adopt appropriate risk management measures to address identified risks.
The risk management measures must ensure that residual risks are judged acceptable when the system is used in accordance with its intended purpose. The provider must also consider the risks when the system is used by people with particular levels of technical knowledge, experience, education, or training — and the environment in which the system is intended to be used.
Data and Data Governance (Article 10)
What the law requires: Training, validation, and testing data sets must be subject to appropriate data governance and management practices. These practices must address the relevant design choices, data collection processes and the origin of data, the relevant data preparation processing operations (annotation, labelling, cleaning, updating, enrichment, aggregation), the formulation of relevant assumptions about the information the data is supposed to measure and represent, an assessment of the availability, quantity, and suitability of the data, examination in view of possible biases that are likely to affect the system, the identification of possible data gaps or shortcomings and how those can be addressed, and appropriate measures to detect, prevent, and mitigate possible biases.
What this means in practice: You need to be able to demonstrate that your training data was carefully selected, properly processed, checked for bias, and documented. This is not just about having a large dataset — it is about having the right dataset and being able to prove it.
Training, validation, and testing datasets must be relevant, sufficiently representative, and to the best extent possible free of errors and complete in view of the intended purpose. They must take into account the characteristics of the persons or groups on whom the system is intended to be used. These requirements apply not only to the initial development but to any updates or retraining of the system.
Technical Performance: Accuracy, Robustness, Cybersecurity (Article 15)
What the law requires: High-risk AI systems must 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.
What this means in practice: The system must work as intended with a measurable level of accuracy, resist errors and inconsistencies (robustness), and be protected against attempts to manipulate its behaviour through adversarial inputs, data poisoning, or other attacks (cybersecurity). These properties must be maintained not just at launch but throughout the system’s life.
The levels of accuracy and the relevant accuracy metrics must be declared in the accompanying instructions for use. The system must be resilient against attempts by unauthorised third parties to alter its use, outputs, or performance by exploiting system vulnerabilities.
Human Oversight Design (Article 14)
What the law requires: Providers must design and develop the high-risk AI system so that it can be effectively overseen by natural persons during the period in which the system is in use, including by providing appropriate human-machine interface tools.
What this means in practice: The deployer’s ability to assign competent oversight, intervene in the system’s operation, and override its outputs depends directly on what the provider builds into the system at the design stage. This includes providing tools and interfaces that allow the oversight officer to understand the system’s outputs, detect anomalies, and take corrective action. If the system does not support effective human oversight by design, the deployer cannot compensate for that gap through operational measures alone.
Phase 2: Before Placing on the Market
Technical Documentation (Article 11)
What the law requires: The technical documentation must be drawn up before the system is placed on the market or put into service and must be kept up to date. It must contain, at a minimum, the information set out in Annex IV.
What this means in practice: You need a comprehensive document (or set of documents) that describes the system in sufficient detail for authorities to assess its compliance. Annex IV specifies the contents, which include a general description of the AI system, a detailed description of the elements of the AI system and of the process for its development, detailed information about the monitoring, functioning, and control of the AI system, a description of the appropriateness of the performance metrics, a detailed description of the risk management system, a description of any change made to the system through its lifecycle, a list of the harmonised standards applied, a description of the conformity assessment procedure applied, and an EU declaration of conformity.
Key point: Technical documentation is not a one-time deliverable. It must be updated whenever the system changes. Keeping documentation current is an ongoing obligation.
Conformity Assessment (Article 43)
What the law requires: Before placing a high-risk AI system on the market or putting it into service, the provider must carry out a conformity assessment to demonstrate that the system complies with the requirements of the AI Act.
What this means in practice: There are two types of conformity assessment. For most high-risk AI systems listed in Annex III, the provider can conduct an internal conformity assessment based on Annex VI. This means the provider itself verifies and documents compliance — there is no requirement for a third-party audit. However, for AI systems used for biometric identification (Annex III point 1) and for AI systems that are safety components of products regulated under certain EU product legislation (Pathway 2), a third-party conformity assessment by a notified body may be required.
The internal conformity assessment requires the provider to verify that the quality management system is in compliance, examine the information in the technical documentation, and verify that the design and development process and post-market monitoring are consistent with the technical documentation.
CE Marking (Article 48) and EU Declaration of Conformity (Article 47)
What the law requires: After successfully completing the conformity assessment, the provider must draw up an EU declaration of conformity and affix the CE marking to the AI system or its documentation.
What this means in practice: The CE marking signals to the market and to authorities that the system has been assessed and meets the requirements of the AI Act. The EU declaration of conformity is a formal document stating that the system complies, identifying the provider, the system, the applicable legislation, and the harmonised standards or specifications applied.
EU Database Registration (Article 49)
What the law requires: Before placing a high-risk AI system on the market or putting it into service, the provider must register the system in the EU database referred to in Article 71.
What this means in practice: The EU maintains a publicly accessible database of high-risk AI systems. Providers must register their systems in this database, providing information such as the provider’s name and contact details, a description of the intended purpose, the risk classification, the conformity assessment procedure followed, and the status of the system (on the market, withdrawn, recalled).
Important note for deployers: If you are a deployer that is a public body or an entity acting on behalf of a public body, you may also have registration obligations under Article 49(3) and (4). This is a deployer obligation, not a provider obligation, but it connects to the provider’s registration. Verify your specific situation.
Phase 3: Deployment Support
Instructions for Use (Article 13)
What the law requires: High-risk AI systems must be accompanied by instructions for use in an appropriate digital format or otherwise, that include concise, complete, correct, and clear information that is relevant, accessible, and comprehensible to deployers.
What this means in practice: This is the document that deployers rely on to fulfil their obligations (as described in Chapter 6, Obligation 1). The quality of the IFU directly determines how effectively deployers can comply. The IFU must include the provider’s identity, the system’s characteristics, capabilities, and limitations of performance (including the intended purpose, the level of accuracy, robustness, and cybersecurity, any known circumstance that may lead to risks, the system’s performance with respect to the persons or groups on whom it is intended to be used, and specifications for input data), the human oversight measures, the expected lifetime of the system, and any necessary maintenance and care measures.
Key point: The IFU is not a marketing document. It must be honest about the system’s limitations, biases, and risks. If the system performs poorly on certain demographic groups, the IFU must disclose this. If the system requires specific conditions to function properly, the IFU must specify them.
Transparency Obligations (Article 13(3))
What the law requires: 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 a system’s output and use it appropriately.
What this means in practice: The system must be designed so that deployers can understand what the system is doing and why. This does not mean the system must be fully explainable in a technical sense, but deployers must have enough information to use it responsibly and to fulfil their own duty to notify affected individuals under Article 26(11) and to answer their requests for an explanation under Article 86.
Phase 4: Post-Market
Post-Market Monitoring System (Article 72)
What the law requires: Providers must establish and document a post-market monitoring system in a manner that is proportionate to the nature of the AI technology and the risks of the high-risk AI system.
What this means in practice: After you place the system on the market, you must actively collect and analyse data about how the system is performing in real-world conditions. The post-market monitoring system must actively and systematically collect, document, and analyse relevant data that may be provided by deployers or that may be collected through other sources about the performance of the system throughout its lifetime. This data must feed back into the risk management system and the update cycle for the system.
Serious Incident Reporting (Article 73)
What the law requires: Providers of high-risk AI systems placed on the Union market shall report any serious incident to the market surveillance authorities of the Member States where that incident occurred, immediately after the provider has established a causal link between the AI system and the serious incident or the reasonable likelihood of such a link, and, in any event, not later than 15 days after the provider or, where applicable, the deployer, becomes aware of the serious incident.
What this means in practice: A serious incident is defined as an incident or malfunctioning of an AI system that directly or indirectly leads to death or serious damage to health, a serious and irreversible disruption of the management or operation of critical infrastructure, an infringement of obligations under Union law intended to protect fundamental rights, or serious damage to property or the environment.
You must have a process in place to identify serious incidents, assess causality, and report them within the 15-day deadline. This requires monitoring channels, internal escalation procedures, and pre-prepared reporting templates.
Corrective Action (Article 20)
What the law requires: Providers who consider or have reason to consider that a high-risk AI system that they have placed on the market or put into service is not in conformity with this Regulation must immediately take the necessary corrective actions to bring that system into conformity, to withdraw it, or to recall it, as appropriate.
What this means in practice: If you discover that your system does not comply — through your own monitoring, through deployer reports, through authority actions, or through any other means — you must act immediately. You must also inform the relevant national authorities and, where applicable, the notified body that issued the conformity assessment certificate.
Quality Management System (Article 17)
What the law requires: Providers must establish a quality management system that ensures compliance with the AI Act. The quality management system must be documented in the form of written policies, procedures, and instructions, and must include a strategy for regulatory compliance, techniques and procedures for the design, development, and examination of the AI system, techniques and procedures for development and quality control, examination, test, and validation procedures, technical specifications including standards to be applied, systems and procedures for data management, the risk management system, monitoring of the system after placing on the market, procedures for reporting serious incidents, communication with authorities and deployers, and systems and procedures for record-keeping.
What this means in practice: This is the overarching management framework that ties all other provider obligations together. It is not a single document but a system of documented processes that ensure consistent, auditable compliance across all obligations.
Provider vs. Deployer: The Responsibilities Compared
| Area | Provider | Deployer |
|---|---|---|
| Risk management | Design, implement, maintain risk management system (Art 9) | Monitor for risks during operation (Art 26(5)) |
| Data quality | Training, validation, testing data (Art 10) | Input data during operation (Art 26(4)) |
| Documentation | Technical documentation (Art 11), IFU (Art 13) | Receive and follow IFU (Art 26(1)) |
| Human oversight | Design system to enable oversight (Art 14) | Assign and empower oversight officer (Art 26(2)) |
| Logging | Design system to generate logs (Art 12) | Retain logs for ≥6 months (Art 26(6)) |
| Transparency | Provide information to deployers (Art 13) | Inform workers (Art 26(7)), inform individuals (Art 26(11)), explain decisions (Art 86) |
| Conformity | Conduct assessment, CE marking, registration (Art 43–49) | Not required |
| Monitoring | Post-market monitoring system (Art 72) | Operational monitoring and reporting (Art 26(5)) |
| Incidents | Report serious incidents (Art 73) | Report risks to provider (Art 26(5)) |
| Quality system | Establish and maintain QMS (Art 17) | Not required |
The pattern is clear: the provider creates the conditions for compliance; the deployer maintains compliance in operation. Neither can do the other’s job.
Self-Check: Provider Obligations Compliance
For each high-risk AI system you provide, assess your current status:
| # | Obligation | Status |
|---|---|---|
| 1 | Is a risk management system documented and maintained? | |
| 2 | Are data governance practices documented for training, validation, and testing data? | |
| 3 | Are accuracy, robustness, and cybersecurity levels defined and tested? | |
| 4 | Is the system designed to enable effective human oversight? | |
| 5 | Is technical documentation complete and up to date? | |
| 6 | Has a conformity assessment been conducted? | |
| 7 | Is CE marking affixed and EU declaration of conformity issued? | |
| 8 | Is the system registered in the EU database? | |
| 9 | Are Instructions for Use complete, honest, and current? | |
| 10 | Is a post-market monitoring system in place? | |
| 11 | Is a serious incident reporting procedure established? | |
| 12 | Is a corrective action procedure in place? | |
| 13 | Is a quality management system documented? |
Any item marked incomplete is a gap that needs to be addressed before the enforcement deadline of 2 December 2027.
Summary
Providers of high-risk AI systems carry the most extensive obligations under the EU AI Act, spanning the entire lifecycle from design through post-market monitoring. These obligations are organised across four phases: design and development (risk management, data governance, technical performance, human oversight design), pre-market (technical documentation, conformity assessment, CE marking, EU database registration), deployment support (instructions for use, transparency), and post-market (monitoring, incident reporting, corrective action, quality management). The provider’s obligations are complementary to the deployer’s — the provider creates the foundation, the deployer operates on it. A quality management system ties all obligations together into an auditable framework. If you are both a provider and a deployer (for the same system or across different systems), you must satisfy both sets of obligations independently. Chapter 8 covers the two mandatory impact assessments — FRIA and DPIA — that may apply to both providers and deployers.
← Back to Blog Summary