Quality Management Systems: What Article 17 Requires

You can do everything Articles 9 through 15 asks (manage the risk, write the technical file, build the logging, declare your accuracy metrics) and still fail your conformity assessment, because Article 17 asks for the one thing none of those delivers on its own: evidence that the work is run as a system rather than assembled in a scramble before launch.

Article 17 is the quality management system obligation. It is easy to skip past, because it doesn’t describe a feature of your AI system the way the risk and transparency articles do. It describes how your organisation is run and how it oversees its compliance obligations.

What Article 17 actually requires

Article 17(1) is direct. Providers of high-risk AI systems “shall put a quality management system in place 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.”

Two words carry the weight. Documented means it has to exist on paper (or in a wiki, a handbook, a set of linked docs) — not in your head and not in the shared understanding of three engineers who have worked together for years. Ensures compliance means the QMS is the mechanism that makes every other obligation repeatable: the reason your next model version gets the same risk assessment, the same data checks, and the same sign-off as the last one.

If you are the provider of a high-risk system, this applies to you regardless of size. A 14-person startup shipping a CV-screening tool has the same Article 17 obligation as a multinational — the depth differs, which we’ll come to, but the obligation itself does not.

The thirteen aspects it has to cover

Article 17(1) lists thirteen aspects, (a) through (m), that the QMS must include “at least.” This is the checklist a notified body or market surveillance authority will hold your documentation against, so it’s worth reading as a test rather than prose:

• (a) A regulatory compliance strategy: How you handle conformity assessment and how you manage modifications to the system.
• (b) Design controls: The techniques and procedures for designing, design control, and design verification.
• (c) Development controls: Development, quality control, and quality assurance procedures.
• (d) Testing and validation procedures: What examination, test, and validation you run before, during, and after development, and how often.
• (e) Technical specifications and standards: Which standards you apply, and where harmonised standards don’t fully cover a requirement, the means you use to meet it anyway.
• (f) Data management: Your procedures for data acquisition, collection, analysis, labelling, storage, filtering, aggregation, and retention. This is the operational side of your Article 10 data governance.
• (g) The risk management system referred to in Article 9.
• (h) The post-market monitoring system referred to in Article 72.
• (i) Serious incident reporting procedures under Article 73.
• (j) Communication handling: How you deal with national competent authorities, notified bodies, other operators, customers, and other interested parties.
• (k) Record-keeping: Systems and procedures for keeping all relevant documentation and information.
• (l) Resource management: Including security-of-supply measures.
• (m) An accountability framework: Setting out the responsibilities of management and staff for all of the above.

Read that list again and notice what it is doing. Half the entries point at other articles. The risk management system (g) is Article 9. Post-market monitoring (h) is Article 72. Incident reporting (i) is Article 73. Data management (f) operationalises Article 10. The QMS is not a separate pile of work. It is the index and the operating manual that connects the work you are already doing for the rest of the Act, plus the parts the other articles leave unsaid: who signs off, how often you test, what happens when you change the model.

That last point (m) forces you to identify who is responsible. A regulator asking how you assure quality does not want to hear “we all keep an eye on it.” They want a document that says the Head of Engineering owns design verification and the named compliance lead owns the conformity strategy.

How proportionality works (and where it stops)

The fear most small teams should have about Article 17 is that “quality management system” means the ISO-9001 apparatus a regulated manufacturer runs — a full-time quality department, audit cycles, a controlled-document library. Article 17(2) is the answer to that fear, and it’s worth quoting because people misread it in both directions:

Article 17(2): “The implementation of the aspects referred to in paragraph 1 shall be proportionate to the size of the provider’s organisation. Providers shall, in any event, respect the degree of rigour and the level of protection required to ensure the compliance of their high-risk AI systems with this Regulation.”

The first sentence is the relief. A 14-person company does not need the documentation volume of a 5,000-person firm. Your QMS can be a set of well-maintained markdown docs and a clear sign-off process rather than a quality-management software suite.

The second sentence is the limit, and it’s where over-confident reading gets teams into trouble. Proportionality scales the amount of processes, not the rigour. You still have to address all thirteen aspects. You cannot point at 17(2) and say a small company gets to skip incident-reporting procedures.

You probably have most of it already

Here is the practical reframe for a working team. Walk through the thirteen aspects and most will map to something you already do.

Take a fictional provider, an eight-engineer company selling an AI tool that ranks shift-workers for promotion, which lands it in the Annex III employment category and makes it high-risk. They already have a code review process (that’s part of c). They already run model-evaluation suites before each release (d). They have a data pipeline with documented sources and labelling rules (f). They keep a risk log (g). They have a Slack channel and an email alias for customer issues (the raw material for j).

What they don’t have is any of it written as a system. Nobody can hand a regulator a single document that says “this is how we assure the quality of this system, here is who owns each part, here is how often each check runs, and here is what we do when we change the model.” Building the Article 17 QMS, for a team like this, is mostly an exercise in indexing and formalising work that already exists. Start working on your QMS before the 2 December 2027 high-risk deadline gets too close, because the gaps you find (a missing monitoring system, an absent accountability map, etc.) take real time to set up.

Where Article 17 becomes serious

Three parts of Article 17 carry more weight than they may first appear to.

The QMS itself gets audited. Most high-risk systems use an internal conformity assessment, where you self-assess. But for systems that need a notified body, like biometric systems where harmonised standards don’t yet cover the requirements, the Annex VII procedure has the notified body assess and approve the quality management system directly, certify it, and re-examine any later changes to it. For those providers, the QMS is an externally audited and certified object.

It has a ten-year shelf life. Article 18 requires you to keep the QMS documentation, alongside the technical documentation and the declaration of conformity, for ten years after the system is placed on the market. A QMS that only describes how you work today, with no version history, doesn’t meet that requirement. The document has to be maintained and dated as the system evolves.

Failing it is a tier-two violation. Article 17 sits among the high-risk provider obligations, so non-compliance falls in the €15 million or 3% of global turnover penalty tier. The QMS will be among the first things a market surveillance authority asks to see, because it reveals at a glance whether your compliance is systematic or improvised. A thin or missing QMS invites a closer look at everything else.

If you run a sectoral or financial quality system

Two carve-outs prevent double work. Article 17(3) lets providers already subject to a quality management obligation under other EU sectoral law fold the Article 17 aspects into that existing system rather than running a parallel one. And Article 17(4) gives financial institutions a deeper allowance: if you are subject to internal-governance requirements under EU financial services law, complying with those is deemed to satisfy Article 17 except for the risk management system, post-market monitoring, and incident reporting (points (g), (h), and (i)), which you still have to add on top.

If you already maintain an ISO 9001 or similar quality system, use it as the frame. It won’t cover the AI-specific aspects on its own, but it gives you the document structure, the version control, and the sign-off habits the Act expects, so the job becomes extending a system you have rather than inventing one.

What to do now

1. Map the thirteen aspects against what you already do. For each of (a) through (m), write down: do we do this, where is it written, and who owns it? The gaps will be obvious — usually post-market monitoring, incident reporting, and the accountability framework.
2. Name owners. Article 17(m) is not satisfied by good intentions. Identify who is responsible for each aspect. This is the cheapest part and the one regulators will check first.
3. Write the index before the detail. A two-page document that lists your thirteen aspects, points to where each lives, and states who owns it and how often it runs is worth more than a polished policy on one aspect and silence on the rest.
4. Date it and keep the history. Build version control in from the start, because Article 18 expects ten years of it.

The other high-risk articles describe what your system has to be. Article 17 describes how you stay able to prove it, release after release. Build the index first, fill the gaps it exposes, and the conformity assessment stops being a scramble.