Skip to content

The Quality Management System Requirement for AI Providers (Article 17)

9 min read · updated August 11, 2026

Article 17 is the article that decides how much of the EU AI Act is a new programme and how much is a set of additions to one you already run. Read element by element, most of it is a quality management system of a very recognisable kind — and four items in the list have no equivalent in ISO 9001 at all.

Who has to have one

Article 17(1) of Regulation (EU) 2024/1689 requires providers of high-risk AI systems to put a quality management system in place that ensures compliance with the Regulation. It must be documented in a systematic and orderly manner in the form of written policies, procedures and instructions, and it must include at least the aspects the article then lists.

Two words in that sentence are worth pausing on. “Providers” means the obligation is on whoever places the system on the market or puts it into service under their own name or trademark — and Article 25 can make a deployer, distributor or importer into a provider if they rebrand a system, substantially modify it, or change its intended purpose so that it becomes high-risk. “At least” means the list is a floor. See where the provider/deployer line actually falls.

Not legal advice. Whether your organisation is a provider, and whether a given system is high-risk, are the two questions that decide whether any of this applies, and both are fact-specific. Take advice before building or before deciding you do not need to.

The thirteen elements, (a) to (m)

Summaries of this article frequently give the count as nine or ten. The adopted text runs (a) to (m) — thirteen. The list, compressed:

  • (a) a strategy for regulatory compliance, including compliance with conformity assessment procedures and procedures for managing modifications to the system;
  • (b) techniques, procedures and systematic actions for design, design control and design verification;
  • (c) techniques, procedures and systematic actions for development, quality control and quality assurance;
  • (d) examination, test and validation procedures before, during and after development, and how often they are run;
  • (e) technical specifications, including standards, to be applied — and where harmonised standards are not applied in full, the means used to meet the Section 2 requirements anyway;
  • (f) systems and procedures for data management, covering acquisition, collection, analysis, labelling, storage, filtration, mining, aggregation and retention, and any other operation performed before and for the purpose of placing the system on the market;
  • (g) the risk management system of Article 9;
  • (h) the post-market monitoring system of Article 72;
  • (i) procedures for reporting a serious incident under Article 73;
  • (j) handling communication with national competent authorities, notified bodies, other operators, customers and other interested parties;
  • (k) systems and procedures for record-keeping of all relevant documentation and information;
  • (l) resource management, including security-of-supply measures;
  • (m) an accountability framework setting out the responsibilities of management and other staff for all of the above.

What you probably already have

If an organisation holds an ISO 9001 certificate, or runs a regulated quality system under the medical devices or machinery frameworks, a large share of this list already exists under different names and can be evidenced rather than built.

  • (b), (c) and (d) are design control, production quality assurance and verification and validation. ISO 9001 clauses 8.3 and 8.6 cover the ground; the AI-specific addition is that the “design output” includes a trained artefact whose behaviour is not fully specified by its design inputs, so the verification step has to be empirical.
  • (e) is the standards register every quality system keeps. What is new is the second half: an explicit account of how you meet the requirement where you have not applied a harmonised standard in full, which is the ordinary case while those standards are still being written.
  • (j) is regulatory affairs and customer communications, and (k) is document and records control — ISO 9001 clause 7.5 almost verbatim.
  • (l) is resource management, clause 7.1, with a supply-continuity element that will be familiar to anyone who has managed a critical-component supply chain.
  • (m) is the responsibility and authority clause, 5.3. Rewriting the RACI to name the AI system is usually the whole task.

The mapping is not a shortcut around certification. It is the reason a gap analysis should start from the existing quality manual rather than from a blank compliance template — and the reason organisations pursuing an ISO/IEC 42001 management system often find the incremental work smaller than expected.

The four that are genuinely new

Four elements have no clean ISO 9001 analogue, and these are where the real work is.

(f) data management as a quality process. A conventional QMS controls documents and materials. Article 17(1)(f) controls a dataset across ten named operations, and it is the operational companion to the Article 10 data governance requirements. Data lineage, labelling instructions and labeller quality, filtration criteria and their justification, and retention rules all become auditable artefacts. Most organisations have this knowledge distributed among the people who built the pipeline and written down nowhere.

(g) the Article 9 risk management system. This is a continuous, iterative process running across the whole lifecycle, aimed at risks to health, safety and fundamental rights — not at risks to the business. Enterprise risk registers rarely have a fundamental rights column, and adding one is not a formatting change.

(h) post-market monitoring. Article 72 requires a documented post-market monitoring plan, in a template the Commission is to provide, which actively collects and analyses performance data over the system’s lifetime. Reactive support ticketing is not that. See what the monitoring plan has to contain.

(i) serious incident reporting. Article 73 sets reporting deadlines to market surveillance authorities that are short enough to require a rehearsed procedure rather than a policy: the general rule is immediate reporting and in any event within a defined number of days of the provider establishing the causal link or its reasonable likelihood, with a tighter deadline for widespread infringements and for incidents involving a person’s death. If your organisation does not know today who signs one of those, the procedure does not exist. See the incident reporting duty in detail.

Proportionality and the financial-sector carve-out

Article 17(2) states that implementation of these aspects shall be proportionate to the size of the provider’s organisation, while preserving the degree of rigour and the level of protection required. That is a genuine concession to small providers on form — the depth of documentation, the number of separate procedures — and not on substance. A microenterprise does not get to skip a risk management system; it gets to run one that fits on fewer pages.

Article 17(3) allows providers already subject to quality management obligations under sectoral Union law to fold these aspects into that existing system rather than run a parallel one. Article 17(4) goes further for financial institutions subject to internal governance requirements under Union financial services law: they are deemed to have complied with the Article 17(1) obligation by complying with those rules, except for points (g), (h) and (i) — risk management, post-market monitoring and incident reporting. Those three survive the carve-out, which tells you which parts of the article the co-legislators considered irreplaceable. See how this sits alongside financial-sector model governance.

The full text of the article is on EUR-Lex, and the QMS has to exist before the conformity assessment, not after it.

The date this bites has moved. Stand-alone Annex III high-risk obligations were to apply from 2 August 2026 under Article 113; the digital omnibus on AI, Regulation (EU) 2026/1744, published in the Official Journal on 24 July 2026 and in force from 27 July 2026, moves that to 2 December 2027, and high-risk systems embedded in products under Annex I to 2 August 2028. Nothing above turns on any other element of that amending Regulation; check the consolidated AI Act text for the rest.