The AI Act Quality Management System: What Article 17 Actually Asks an Engineering Org to Run

The phrase “quality management system” reads to most engineering leaders as a demand for ISO paperwork and a new binder nobody opens. Article 17 of the AI Act is asking for something you very largely already run — it just wants it written down, owned, and evidenced.

When a provider of a high-risk AI system reads that it must establish a quality management system, the instinct is to reach for a consultancy that will stand up a parallel governance function next to the one engineering already operates. That instinct is expensive and usually wrong. Article 17 does not describe a bureaucracy. It describes documented, auditable processes across the model lifecycle, most of which a serious engineering organisation performs already under different names. The work is not to build a QMS from nothing. It is to see which of your current practices already satisfy it, name the genuine gaps, and produce the paper trail without duplicating everything twice under a compliance label.

What Article 17 actually asks for

Article 17 of Regulation (EU) 2024/1689 sits in the obligations for providers of high-risk systems. It requires that the quality management system be “documented in a systematic and orderly manner in the form of written policies, procedures and instructions”, and it lists thirteen aspects that system has to cover — points (a) to (m). Read them as engineering concerns rather than legal ones and the shape is familiar:

• A strategy for regulatory compliance, including conformity assessment and, critically, the procedure for managing modifications to the system.
• Techniques and systematic actions for design, design control and design verification.
• Techniques for development, quality control and quality assurance.
• Examination, test and validation procedures, run before, during and after development, and how often.
• Technical specifications and standards applied, and how compliance with the requirements is ensured.
• Data management: acquisition, collection, analysis, labelling, storage, filtration, aggregation and retention.
• The risk management system required by Article 9, post-market monitoring under Article 72, and serious-incident reporting under Article 73.
• Handling of communication with authorities and notified bodies, record-keeping, resource management, and an accountability framework setting out who is responsible for what.

Nothing there is exotic to a team that ships software responsibly. Design control is architecture review. Development quality assurance is your code review and CI gates. Test and validation is your evaluation harness and release testing. Data management is your training-data lineage and retention policy. The accountability framework is your RACI. Article 17 is not asking you to invent these things. It is asking you to be able to show them, as a coherent system, on the day a notified body or market surveillance authority asks.

Map it onto the SDLC you already run

The productive move is to lay Article 17’s thirteen points against your existing software and model development lifecycle and mark, honestly, where each is already satisfied. Most organisations find that the majority already have a home. Design verification lives in your architecture decision records. Quality control lives in pull-request policy and branch protection. The testing procedures of point (d) are your model evaluation suite and your pre-release checklist. The data management of point (f) is whatever you do for dataset versioning and provenance. This mapping is the same discipline as translating any regulation into concrete deliverables rather than a policy document — the exercise we set out in the AI Act’s obligations translated into actual engineering work.

Doing the mapping first does two things. It stops you paying to rebuild controls you already have, and it turns a vague obligation into a short, specific list of what is genuinely missing. That list, not a fresh binder, is the actual scope of the work.

Where the genuine gaps sit

Three points are where the mapping usually comes up short, and they are the same three every time.

The modification procedure, point (a). Engineering teams have change control for code. Far fewer have a defined, documented procedure for what constitutes a substantial modification to the AI system — a retrain, a material change to the training set, a shift in intended purpose — and what that modification triggers by way of re-testing and, potentially, fresh conformity assessment. This is a change-governance question, and it is the one most likely to be missing entirely.

The risk management system, point (g). Article 17 folds in the Article 9 obligation, which is a continuous, iterative process across the whole lifecycle, not a one-off assessment. If you have not stood that up as a running system, the QMS has a hole in it. We have written separately on what that actually requires in a technology function’s reading of Article 9.

Post-market monitoring, point (h). Point (h) pulls in Article 72: a documented plan to collect and analyse performance data once the system is in real use, with a feedback loop back into the risk process. Most teams monitor for uptime and errors. Monitoring for the specific degradations the AI Act cares about — drift, performance decay against the intended purpose, emerging risks to health, safety and fundamental rights — is usually the missing piece, as we set out in our reading of post-market monitoring for high-risk AI.

The financial-institution shortcut, and its catch

If you are a financial institution already subject to internal governance requirements under Union financial services law, Article 17(3) gives you a partial pass. The obligation to put a quality management system in place is deemed fulfilled by complying with those internal governance rules — with one sharp exception. Points (g), (h) and (i) are carved out. Risk management, post-market monitoring and serious-incident reporting still have to be addressed separately and specifically for the AI system. So the very three areas most likely to be missing in the first place are exactly the ones the financial-services shortcut does not cover. If your governance rests on, say, an existing internal-governance and ICT-risk framework of the kind we describe in our reading of DORA Article 6, that carries much of the QMS — but not those three.

Proportionality is not an escape hatch

Article 17(2) states that implementation of the thirteen aspects “shall be proportionate to the size of the provider’s organisation”. A ten-person team is not expected to run the documentation apparatus of a multinational. But proportionality reduces depth, not existence. Every in-scope provider still needs each aspect present in some form — a lighter modification procedure, a leaner monitoring plan, a shorter accountability framework — but present, written, and owned. “We are small” is not a reason for a point to be absent.

Evidence without duplication

The goal is a QMS that points at what engineering already does, not one that copies it into a compliance system that then drifts out of sync. In practice that means the QMS document references your live artefacts — the ADR repository, the CI configuration, the evaluation results, the dataset registry, the incident runbook — rather than restating them. When those artefacts are the evidence, the system stays true because it is the same system engineering runs every day. When the QMS is a separate description of an idealised process, it is wrong within a quarter, and a supervisor reading it against your actual pipeline will see that.

The obligation bites from 2 December 2027 for stand-alone high-risk systems and 2 August 2028 for those embedded in regulated products, after the Digital Omnibus adopted in mid-2026 moved the original dates. That is enough time to do this properly — and precisely enough time to waste building a second bureaucracy you will then have to keep alive alongside the first.

A quality management system you have to maintain twice is not a control. It is a liability with a compliance label on it.