Article 17 of the AI Act: Quality Management System for High-Risk AI Providers

Normative Precision: Article 17 Regulates Quality, Not Registration

It is fundamental to clarify a frequent confusion in secondary literature: Article 17 of Regulation (EU) 2024/1689 does not regulate the registration of systems in the European Union database. That obligation specifically corresponds to Article 49. Article 17 focuses exclusively on the obligation to implement a Quality Management System (QMS) that ensures compliance with the regulation by providers of high-risk AI systems.

This distinction is critical for compliance teams. While registration (Art. 49) is a punctual administrative act of inscription, the QMS (Art. 17) is a continuous organizational infrastructure that covers the entire lifecycle of the system. Confusing the two can lead organizations to underestimate the operational burden of Article 17, which requires systematic written policies, procedures, and instructions, not just an inscription form.

The two duties answer different regulatory questions. Registration concerns the system’s entry in the Union database under Article 49; the quality system concerns how the provider organizes and maintains compliance under Article 17. Completing one does not, by itself, complete the other. A database entry cannot stand in for documented internal processes, and a documented QMS cannot stand in for a registration that the regulation separately requires.

Treating the QMS as continuous infrastructure also clarifies why it reaches beyond the moment when a system is prepared for registration. Its policies, procedures, and instructions must provide an organized basis for the provider’s compliance work over the system’s lifecycle. The distinction is therefore practical as well as formal: registration records an administrative step, while Article 17 calls for an operating management framework that can support the provider’s activities and responsibilities over time.

Mandatory Content of the Quality Management System

Paragraph 1 of Article 17 establishes that the QMS must be documented in a systematic and orderly manner in the form of written policies, procedures, and instructions. The regulation lists thirteen minimum aspects that must be included. This is not an exhaustive list, but a normative floor: providers may add additional elements if their context requires it.

Among the most relevant elements are the regulatory compliance strategy (letter a), which must include conformity assessment procedures and modification management; design and development techniques (letters b and c); and examination, testing, and validation procedures (letter d), which must specify the frequency of their implementation. It is also mandatory to include the risk management system (Art. 9) and the post-market monitoring system (Art. 72) within the QMS.

The thirteen aspects are a minimum scope for documentation, not a requirement to create thirteen separate manuals or departments. Providers can organize the material in a form suited to their organization, provided that the required subjects remain covered and the QMS is systematic and orderly. The distinction between required coverage and document format matters: combining subjects in one procedure does not remove the obligation to address each applicable aspect, while a large collection of documents does not establish coverage merely by its volume.

The listed elements connect policy to implementation. A compliance strategy should explain how conformity assessment is handled and how modifications are managed; design and development procedures should describe the techniques used to control and assure quality; and examination, testing, and validation procedures should state how often those activities take place. Defining frequency makes the procedures operational: it records when checks are intended to occur rather than leaving their timing unstated.

Data management has a broad set of expressly identified stages, including acquisition, analysis, labelling, storage, and preservation. A procedure that addresses only one stage would not, on that account alone, describe the full data-management aspect shown in the table. The QMS can make responsibilities and handling steps visible across those stages, while the particular documentation arrangement remains for the provider to establish within the regulation’s requirements.

The post-market and accountability elements extend the QMS beyond development activities. The listed minimum aspects include monitoring after a system is placed on the market and notification of serious incidents, as well as a framework assigning responsibilities to management and staff. Taken together, these subjects show why the QMS is not only a set of design controls: it must also describe how specified organizational responsibilities and continuing obligations are addressed.

Proportionality and Adaptation to Organization Size

Paragraph 2 of Article 17 introduces a principle of proportionality: the application of the QMS aspects must be proportional to the size of the provider's organization. This means a startup is not required to have the same documentary complexity as a large corporation, provided that the necessary degree of rigor and level of protection to ensure conformity are respected.

However, this proportionality is not an exemption. The legal text explicitly warns that, in any case, providers must respect the necessary rigor. For SMEs, this implies adapting the granularity of procedures, not eliminating them. For example, an SME may integrate risk management into a single governance document, while a large enterprise might have separate departments for each aspect.

Proportionality concerns how the required QMS aspects are applied, not whether the provider must address them. An organization may scale the detail, organization, and granularity of its documentation to its size, but it still needs a systematic account of the relevant procedures and responsibilities. A shorter set of integrated documents can therefore be an appropriate form; brevity alone does not show that the necessary rigor has been preserved.

The regulation does not supply a numerical threshold that translates organization size into a fixed number of documents, procedures, or staff roles. The provider therefore has to choose an arrangement that remains sufficient for the required level of rigor and protection. The practical question is not whether a small organization can use fewer documents than a large one, but whether its chosen documents still describe the required controls clearly enough to support conformity.

The data-governance example illustrates a choice of organization rather than a waiver of content. One protocol may bring acquisition, labelling, and preservation together instead of assigning each phase its own manual. The consolidated format still needs to address the relevant stages and provide the documentation needed for the provider’s stated purpose. The length or number of documents does not, by itself, establish that the protocol is adequate.

Linkage with Other AI Act Obligations

The QMS does not operate in a vacuum. Article 17.1.g requires the inclusion of the risk management system from Article 9, and 17.1.h requires the creation and maintenance of the post-market monitoring system from Article 72. This creates an integrated compliance architecture where the QMS is the container that unifies technical and organizational obligations.

Furthermore, the QMS must support the human oversight required by Article 14. The design and development procedures (Art. 17.1.b-c) must include measures to ensure the system can be effectively supervised by humans. If the QMS does not document how human oversight is implemented, the provider cannot demonstrate compliance with Article 14 to market surveillance authorities.

Integration means that related duties should be reflected in the QMS rather than treated as disconnected references. The risk-management system required by Article 9 and the post-market monitoring system required by Article 72 are expressly among the QMS aspects identified in Article 17. A provider can use its QMS structure to show where those systems fit, how their procedures are maintained, and which responsibilities apply. Including a reference to another article without describing the corresponding processes would not, by itself, explain how the obligations are handled.

Human oversight links system design to the way people are expected to supervise the system. The design and development procedures identified in Article 17 can document the measures intended to support the oversight required by Article 14. That documentation helps make the relationship between design choices and oversight arrangements understandable; it does not by itself prove that oversight is effective in operation. The provider’s procedures and implementation must remain aligned with the applicable obligation.

The integration flow also connects the QMS to technical documentation under Annex IV. The relevant point is that QMS procedures should govern how technical documentation is generated and maintained, so the documents form part of an organized compliance process rather than an isolated file. The checklist can help confirm whether a procedure exists, but the existence of a procedure should not be confused with proof that every resulting document is complete or that every underlying requirement has been met.

Compliance Checklist and Consequences of Non-Compliance

To demonstrate compliance with Article 17 to authorities, providers must be able to present a documented QMS covering the thirteen minimum aspects. Non-compliance with this obligation is considered a serious infringement, subject to sanctions of up to 15 million euros or 3% of total worldwide annual turnover, whichever is higher, according to Article 99.

The checklist below allows verifying the existence of mandatory elements. It does not replace legal advice but serves as an initial self-assessment tool to identify gaps in documentation.

A useful self-assessment distinguishes the presence of a document from the substance it is meant to demonstrate. A provider can ask whether the QMS is described systematically, whether conformity assessment and modification management are addressed, whether the listed data-handling stages appear in procedures, and whether management and staff responsibilities are defined. A “yes” is a prompt for review, not a legal conclusion: the provider still needs to consider whether the documented arrangements cover the applicable requirements and preserve the necessary rigor.

The checklist is intentionally limited to an initial review of documented elements. It does not assess every operational detail, establish that a procedure is being followed, or replace an assessment of the provider’s circumstances under the regulation. In particular, proportionality cannot be reduced to company size alone as a checkbox: the chosen level of documentation must also retain the rigor needed to support conformity.

The stated maximum penalties should be read within the scope of Article 99 and the relevant infringement category, rather than as an automatic consequence of every documentation gap. The applicable sanction depends on the legal classification and circumstances of the infringement. The checklist can help identify omissions for attention, but it cannot determine that classification or predict a particular penalty.

Keep exploring

Corrections and transparency

If you spot incorrect or outdated information, send us a correction with the page and source we should review.