Article 17 requires providers of high-risk AI systems to run a documented quality management system covering thirteen elements, from a compliance strategy to an accountability framework. It can be proportionate to company size, and some sectors may fold it into existing governance. Treat it as a written operating system for how you build and change AI.
The thirteen elements
Article 17(1) lists written policies, procedures and instructions covering:
- A regulatory compliance strategy, including how compliance is shown and how changes are managed.
- Design, design control and design verification.
- Development, quality control and quality assurance.
- Examination, test and validation procedures before, during and after development, with frequency.
- Technical specifications and standards applied, and alternatives where harmonised standards are not fully used.
- Data management, from acquisition to retention.
- The risk management system under Article 9.
- Post-market monitoring under Article 72.
- Serious incident reporting under Article 73.
- Communication with authorities, notified bodies, other operators and customers.
- Record-keeping of documentation and information.
- Resource management, including security of supply.
- An accountability framework setting out management and staff responsibilities.
Proportionality
Article 17(2) says implementation can be proportionate to the provider's size, but the required rigour and level of protection must remain. Paragraphs 3 and 4 let providers subject to certain sectoral or financial services rules fold these elements into existing quality or governance systems.
For a small team this means short, real documents rather than a binder nobody opens.
A lean way to build it
- One page per element: purpose, owner, procedure, evidence location.
- A change procedure: what counts as a substantial modification, who decides, what gets retested.
- A data register: sources, licences, quality checks, retention.
- A test plan template reused for each release.
- An incident runbook tied to the Article 73 duty.
- A responsibility matrix naming a person, not a team, for each element.
Where it links to other articles
The QMS is the container for risk management, technical documentation and monitoring. Writing it first gives those a home. See also the post on technical documentation and post-market monitoring.
Using existing frameworks
If you already run an information security or quality system, map it to the thirteen elements and fill gaps rather than starting again. Safeguard's compliance and evidence automation can help hold policies, controls and evidence in one place, and the framework mapping demo shows the idea with existing frameworks. It does not certify a QMS.
Click through it at your own pace, or open it full screen.
Start with the change procedure and the incident runbook. They are short, they matter most in practice, and they force the conversations about ownership that the other eleven elements depend on.
Quick check
Do small providers need all thirteen elements?
The elements are listed for all providers of high-risk systems, but implementation can be proportionate to size while keeping the required rigour.
Can I reuse my existing quality system?
Where the article allows it, for certain sectors, you can fold elements into existing systems. Map and fill the gaps.
Sources
- AI Act Article 17, quality management system (an unofficial reader; confirm wording against the Official Journal)
Last reviewed: 19 October 2026.
