Template
EU AI Act Article 17 - Quality Management System Template
Article 17 is where teams have to show that their process is not ad hoc. The documentation has to show how changes are controlled, how testing is repeated, how monitoring feeds back into the process, and where written procedures still sit outside the product.
Who supplies what
What Article 17 expects, what the toolkit can add, and what your team still owns
Without connecting your agent, the toolkit can only draft the Article 17 QMS scaffold from the generated package. After adapter integration and recurring use, it can keep that scaffold tied to real change, monitoring, and follow-up outputs.
| Article 17 expects | Toolkit with generated package only | Toolkit after adapter integration | Still written and approved by your team |
|---|---|---|---|
| A controlled change path | Creates an Article 17 QMS scaffold with the current system identity, process areas, and management-review triggers. | Keeps that draft linked to real version changes, monitoring updates, and compare-report outputs for the connected system. | Write the formal change procedure, approval path, and accountability rules your organization uses. |
| Repeatable testing and review steps | Can point to the compare report and current statutory outputs already present in the package. | Can keep those testing and statutory outputs current as the connected agent is rerun over time. | Define which suites, thresholds, and review steps are mandatory before relying on the system or placing it on the market or putting it into service. |
| Monitoring feedback into the process | Can point to monitoring-related gaps and unresolved follow-up already visible in the package. | Can link the Article 17 QMS scaffold to post-market monitoring, corrective-action linkage, and follow-up signals from recurring runs. | Decide how monitoring constats feed into process updates, reviews, and escalations inside your organization. |
| Written procedures and ownership | Can list operator inputs still required for the draft to be complete. | Still does not write the formal procedures or assign legal accountability after integration. | Write the procedures, assign accountable roles, and approve the final QMS documents. |
Manual fields
What your team still adds to Article 17
The toolkit can generate a technical QMS scaffold. It does not replace the written QMS procedures, training, or organizational accountability structure.
| What you add | When you add it | Practical format to use |
|---|---|---|
| Written procedure set | Before you treat the Article 17 package as part of a real QMS review. | A short list of linked procedures covering change control, system updates, issue follow-up, and monitoring escalation. |
| Document control and approval path | When QMS documents must be versioned, approved, and updated formally. | A document-control note naming owner, versioning rule, and approval step. |
| Training and competency expectations | Before operator or engineering roles are treated as part of the QMS. | A role-based note describing who must be trained and what evidence of competency you keep. |
| Supplier and external-component controls | Whenever third-party tools, models, or vendors affect the managed system. | A short control note naming the external dependency and how it is reviewed or approved. |
| Named accountable roles | At governance sign-off or QMS review. | A simple role map naming who owns change control, monitoring follow-up, and final approval. |
How this fits into the full package
Article 17 is a QMS scaffold inside the wider package
The files below are the main evidence surfaces for Article 17. Their layout is the toolkit's structured format for these requirements, not an EU-mandated form.
| File in the package | Why it matters for Article 17 | Open file |
|---|---|---|
| Article 17 QMS scaffold - article-17-qms-lite.json | Main draft file for the Article 17 technical process scaffold. The filename remains stable for compatibility. | Open file |
| Article 16 provider obligations - article-16-provider-obligations.json | Shows the provider-owned obligations and documentation controls that feed the QMS scaffold. | Open file |
| Post-market monitoring - post-market-monitoring.json | Shows how monitoring can feed back into the process. | Open file |
| Compare report - compare-report.json | Provides the repeatable testing and change evidence the QMS scaffold references. | Open file |
FAQ
Frequently asked questions
What is the Article 17 - Quality Management System template page for?
This page explains what the Article 17 - Quality Management System template section usually needs to cover inside an EU AI Act package, which parts can be supported by structured evidence, and which parts remain owned by the provider, deployer, or legal reviewer.
Does this Article 17 - Quality Management System template page create a complete EU AI Act package?
No. It is one section-level guide. A review-ready package still needs the selected role and scope, the other applicable article-level sections, linked technical evidence, owner completion, and final human review.
What evidence should be linked to the Article 17 - Quality Management System template section?
Use evidence that is current, traceable to the relevant system version, and connected to real runs, retained records, or approved procedures. A weak package relies only on narrative text; a stronger package links the narrative to reproducible artifacts.
Who should review the Article 17 - Quality Management System template section before handoff?
The technical owner should confirm the system facts and evidence links, while compliance or legal reviewers confirm whether the section is sufficient for the selected EU AI Act role, scope, and conformity path.