EU AI Act Art.17 Quality Management System: A Developer's Implementation Guide

Post #1 in the sota.io EU AI Act Quality Management System Series

If you are building or deploying a high-risk AI system, August 2, 2026 is not just an API-version cutover — it is the date your Quality Management System (QMS) must be operational and documented. Article 17 of the EU AI Act (Regulation 2024/1689) mandates that every provider of a high-risk AI system maintain a formal QMS. This is not an optional add-on. It is a prerequisite for the CE marking process under Art.43, and non-compliance carries penalties under Art.99.

This guide unpacks what Art.17 actually requires, maps each element to the work your engineering and compliance teams are already doing, and gives you a practical roadmap for the 58 days remaining before enforcement.

What is a QMS Under the EU AI Act?

The EU AI Act defines a QMS as the documented system that ensures your high-risk AI system continuously meets the Regulation's requirements — from initial design through post-market monitoring. Unlike ISO 9001 (which governs general product quality), the Art.17 QMS is AI-specific and cross-references many other articles.

Art.17(1) states that providers "shall put a quality management system in place that ensures compliance with this Regulation." The QMS is not a one-time audit artefact. It governs your entire development lifecycle.

The Eight Mandatory QMS Elements

Art.17(2) lists the minimum contents. Below, each element maps to your engineering processes.

1. Regulatory Compliance Strategy

Your QMS must document how you will achieve compliance with the AI Act — including which conformity assessment route you are using under Art.43. For most software-based high-risk AI systems, this is the self-assessment route. Document the regulatory basis, your chosen route, and the internal owner responsible for compliance.

Practical output: A compliance charter signed by your CTO or Head of Engineering. One page is enough if it names the route, the responsible person, and the review cadence.

2. Design and Design Control Procedures

This covers how you design, iterate on, and validate changes to your AI model. Your team already has design review meetings, architecture decision records, and pull request templates. Art.17 requires these to be formalised — not reinvented.

Practical output: A design control SOP that documents: design review gate criteria, what counts as a substantial modification triggering re-assessment, and who has final approval authority.

3. Examination, Testing, and Validation Procedures

Before deployment, during development, and after significant changes — your AI system needs documented testing procedures. This ties directly to Art.9 (risk management system) and Art.15 (accuracy, robustness, cybersecurity). The test scope must cover the specific risks your system is classified under.

Practical output: A test plan template that includes bias testing, adversarial robustness testing, and performance on edge-case datasets. Version-controlled in your repository alongside the model artefacts.

4. Technical Specifications and Standards

You must document which technical standards you apply — including any harmonised standards (CEN/CENELEC) adopted under the AI Act, or alternative solutions where harmonised standards do not yet exist. This is the technical evidence layer for your CE marking process (Art.47).

Practical output: A standards register listing applicable standards (ISO/IEC 42001:2023, ISO/IEC 27001, ISO/IEC 23894), your compliance level for each, and where the evidence lives.

5. Data Management Procedures

Under Art.10 (data and data governance), you must document how you select, pre-process, and validate training, validation, and testing datasets. Art.17 requires this to be a QMS element — meaning it must be repeatable, auditable, and version-controlled.

Practical output: A data lineage document for each model version. At minimum: data source, collection date, pre-processing steps applied, bias scan results, and the responsible data engineer.

6. Risk Management

Art.9 mandates a continuous risk management process. Under Art.17, this process must be embedded in your QMS — not a separate document that is never updated. The risk register should be reviewed at every major release and whenever your system's deployment context changes.

Practical output: A risk register template covering: intended purpose and foreseeable misuse, risk controls implemented, residual risk acceptability, and review history.

7. Post-Market Monitoring

Art.72 requires providers to maintain a post-market monitoring (PMM) plan covering how you will detect, collect, and analyse data about system performance in real-world use. Art.17 requires this plan to be part of your QMS. If you are also a deployer, Art.26 adds further monitoring obligations on top.

Practical output: A PMM plan defining: KPIs tracked (error rate, prediction drift, user complaints), alerting thresholds, escalation path to your QMS owner, and the reporting cadence to your internal compliance function.

8. Record-Keeping and Serious Incident Reporting

Art.11 (technical documentation) and Art.12 (record-keeping) define what you must store. Art.73 defines when and how to report serious incidents to national competent authorities. Art.17 requires procedures for both to be embedded in your QMS.

Practical output: A data retention policy specifying 10-year retention for technical documentation (the AI Act default for high-risk systems), and an incident response runbook with NCA notification thresholds and timelines.

SME Simplifications: Art.62

If your company qualifies as an SME (fewer than 250 employees, or fewer than 750 under the GPAI-specific threshold), Art.62 provides access to simplified obligations and regulatory sandbox support (Art.57). Your QMS documentation can be lighter weight — but the eight elements above must still be addressed. The regulatory sandboxes offer supervised testing environments where you can validate your QMS approach with NCA oversight before formal submission.

QMS vs. ISO 42001: What is the Relationship?

ISO/IEC 42001:2023 (AI Management System) is the international standard for AI management systems. It covers much of the same ground as Art.17 — risk management, data governance, transparency, human oversight. EU national accreditation bodies are developing harmonised standards that will map ISO 42001 requirements to the AI Act. When these harmonised standards are published, conformity to them will create a presumption of conformity to the corresponding AI Act articles.

For now: implementing ISO 42001 is the strongest head-start you can get on your Art.17 QMS. It will not be a perfect one-to-one match, but the structural overlap is high.

Who Owns the QMS?

Art.17 does not prescribe an organisational structure, but the QMS must have an accountable owner. In most engineering-led companies, this is the:

• CTO or VP Engineering for overall ownership
• Principal Engineer or Architect for design control
• ML Engineer or Data Scientist for data management and model testing
• Legal or Compliance Counsel for regulatory strategy and NCA interface
• Head of SRE or Platform Engineering for post-market monitoring infrastructure

The QMS is a cross-functional artefact. If it lives only in Legal, engineers will not update it. If it lives only in Engineering, it will lack the regulatory framing NCAs expect.

Running Your QMS on EU Infrastructure

One practical consideration that is frequently overlooked: your QMS records, training datasets, model logs, and incident reports are evidence under EU law. If they are stored on infrastructure subject to the US CLOUD Act, a US government demand could compel their disclosure — outside EU data protection rules.

Storing your QMS artefacts on EU-hosted infrastructure (Hetzner, OVHcloud, or a managed PaaS like sota.io that runs exclusively on Hetzner Germany) removes this jurisdictional ambiguity. Market surveillance authorities under Art.74 expect to be able to access your records. The access pathway should be governed by GDPR and EU law — not by US court orders.

QMS Documentation Checklist for August 2, 2026

Before the enforcement date, you need:

• Compliance charter (regulatory route, responsible owner)
• Design control SOP (version-controlled, named approver)
• Test plan template (pre-deployment + post-change)
• Standards register (ISO 42001, ISO 27001, applicable harmonised standards)
• Data lineage document per model version
• Risk register (Art.9 compliant, reviewed at each release)
• Post-market monitoring plan (Art.72)
• Data retention policy and incident reporting runbook (Art.73 thresholds)

What is Next in This Series

In Part 2, we will build the Art.9 risk management system in detail: how to structure your risk register, what risk categories the AI Act recognises for your domain, and how to document residual risk acceptability in a way that survives NCA scrutiny.

In Parts 3–5, we will cover the Art.10 data governance requirements, the Art.11-12 technical documentation requirements, and the complete QMS audit readiness checklist — what to expect when your NCA or notified body reviews your QMS.

sota.io is an EU-native managed PaaS built on Hetzner Germany — no US parent company, no CLOUD Act exposure. Deploy your AI systems and store your EU AI Act compliance evidence on infrastructure that stays under EU jurisdiction. Get started free.