Article 17 Audits Your Company, Not Your Model
Teams scope the EU AI Act by reading the risk tiers and then budgeting for technical documentation. The larger line item is a written quality management system with thirteen enumerated components, and it is the one an assessor can evaluate without ever looking at your weights.
Why It Gets Missed
The AI Act's famous provisions are about the system: risk classification, data quality, transparency, human oversight, accuracy and robustness. They can be read as engineering requirements, and engineering requirements get assigned to engineers, who scope them.
Article 17 is about the organisation that builds the system. It asks whether you have procedures, whether people are named against them, whether records exist, whether suppliers are managed, and whether anything happens after release. US software companies coming from a SOC 2 world find parts of this familiar and other parts entirely new, and the new parts are consistently the ones scoped last.
The Four Clusters Inside Article 17
Regulatory strategy and change control
A written strategy for regulatory compliance, including the procedures for conformity assessment and for managing modifications to the high-risk system. This is where you decide, in advance and on paper, what counts as a change significant enough to re-run conformity. Teams that skip it end up making that call under deadline pressure during a release, which is the worst possible moment.
Design, development and testing
Procedures for design and design control, for development and quality control and quality assurance, and for examination, testing and validation carried out before, during and after development — plus the technical specifications and standards you applied, including where a harmonised standard was not applied in full and what you did instead. The last clause is the one that produces real work: divergence has to be justified, not just noted.
Data and risk over the lifecycle
Systems and procedures for data management covering acquisition, collection, analysis, labelling, storage, filtration, mining, aggregation, retention and everything else performed before and for the purpose of placing the system on the market — together with the Article 9 risk management system. This cluster is where the QMS stops being paperwork and starts constraining how the data team actually operates.
After release
The post-market monitoring plan, serious-incident reporting procedures, communication arrangements with national competent authorities, notified bodies, other operators, customers and interested parties, record-keeping, resource management including security-of-supply arrangements, and an accountability framework setting out management and staff responsibilities. For a company whose release process currently ends at deploy, this is a new operational surface.
What You Already Have Versus What You Do Not
- •Document control, versioning and approval workflow
- •Internal audit and management review cadence
- •Corrective and preventive action process
- •Supplier qualification and third-party review
- •Incident response mechanics and on-call rotation
- •Named ownership and an accountability matrix
- •Data governance written across the full lifecycle
- •Risk management tied to intended purpose and foreseeable misuse
- •A change-significance rule that triggers re-assessment
- •A post-market monitoring plan with defined signals
- •Serious-incident reporting to authorities on statutory timelines
- •Justified divergence from harmonised standards, in writing
The Trap: Inheriting a Provider Obligation
The QMS is a provider duty, which is why most US SaaS companies read Article 17 once and file it. The filing is only safe if you stay a deployer. Putting your own brand on a third party's high-risk system, making a substantial modification to one, or repurposing a general system into a high-risk use each converts you into a provider for that system — at which point the QMS, the technical documentation, the conformity assessment, the EU database registration and the CE marking all arrive together. For a company selling an AI layer over someone else's model into an HR, credit, education or essential-services workflow, this is not an edge case. It is the default trajectory.
Build Order That Does Not Waste a Quarter
- Settle your role first. Provider or deployer, per system, in writing. Everything downstream depends on this and it is the answer most likely to be wrong.
- Map Article 17's elements onto existing procedures. Most companies already satisfy a third of it under other names. Produce the mapping table before writing anything new.
- Write the accountability framework early. Named owners per element make the remaining gaps someone's job rather than the programme's.
- Do data governance next. It is the longest lead time because it constrains engineering practice, not just documents.
- Define the change-significance rule before your next release. Decide what re-triggers conformity while nothing is pending.
- Stand up post-market monitoring and incident reporting last. They are operational and can follow the paperwork, but they must exist before the system is on the market.
Frequently Asked Questions
How long does a QMS actually take to build?
For a company with an existing ISO 27001 or mature SOC 2 programme, the mapping exercise is weeks and the genuinely new elements — lifecycle data governance, the risk management system, post-market monitoring — are the schedule. For a company with no formal management system at all, the honest answer is that you are building your first one and the AI-specific content is the smaller half of that project.
Who reviews the QMS, and when?
It depends on the conformity assessment route for your system. Where internal control applies, you assess your own conformity against the requirements and hold the documentation for inspection by market surveillance authorities. Where a notified body is involved, the quality management system itself is part of what gets assessed and is subject to periodic surveillance. Determining your route early changes how much external scrutiny the documents must survive.
Does the QMS have to be in a specific format or language?
The Act requires written policies, procedures and instructions, not a particular template. Language matters practically: authorities may request documentation in an official language of the member state concerned, so plan for translation of at least the core documents rather than discovering the requirement during a request.
We use a general-purpose model from a large provider. Does their compliance flow down to us?
Partly, and less than teams hope. GPAI model providers carry their own obligations including technical documentation and information to downstream providers, and what they publish is genuine input to your file. But your system's intended purpose, your data, your testing and your organisational procedures are yours. Their documentation is an ingredient in your technical file, not a replacement for your quality management system.
Is there any benefit to this beyond avoiding fines?
The QMS is the artifact that answers European enterprise procurement. Buyers in regulated sectors increasingly ask providers to demonstrate AI governance before signing, and a mapped, named-owner, documented system converts a months-long questionnaire cycle into a document send. Companies that treat Article 17 as a sales asset rather than a compliance tax tend to finish it faster, because someone other than legal wants it done.
The Cheapest Version Is the Mapping Table
Before commissioning a consultant or buying a platform, spend a day producing one table: each Article 17 element in the left column, the existing procedure that covers it in the middle, and the named owner on the right.
The blank rows are your actual programme. In most companies there are four or five of them, not thirteen — and knowing which four changes the budget conversation entirely.
This article is general information about the EU AI Act, not legal advice. Timelines, harmonised standards and simplification measures for smaller providers have been subject to ongoing revision — verify the current position with EU counsel before scoping a conformity programme against it.