EU AI Act Article 17 quality management system: building the QMS documentation
This guide builds the written document set that Art. 17(1) requires: a policy, and at least one procedure and one record type for each of the thirteen points (a) to (m), with the preparation steps of PR-17-QMS v1.0 and the clause structure of prEN 18286Published, published. At the end the reader holds a document register with one entry per point, a proportionality record under Art. 17(2), a frozen and hashed set, and a check that fails on any point without a procedure and a record.
What the obligation asks for
Art. 17(1) of Regulation (EU) 2024/1689 requires the provider to document the quality management system in a systematic and orderly manner in the form of written policies, procedures and instructions, covering at least the aspects in points (a) to (m). The article names three kinds of document. A policy states what the provider commits to and who owns the commitment. A procedure or instruction states how an activity is carried out, by which role, at which trigger and with which output. A record is the output of a procedure that ran, and the eight testable elements of the Art. 17 obligation page are all verified by sampling, retrieving or walking through records: the modification record per released version (Art. 17(1)(a)), the design verification records (Art. 17(1)(b)), the quality control records (Art. 17(1)(c)), the test and validation records at the stated frequency (Art. 17(1)(d)), the dataset records (Art. 17(1)(f)), the serious incident walk-through (Art. 17(1)(i)), the record retrieval test (Art. 17(1)(k)) and the role walk-through (Art. 17(1)(m)). The seventeen documentation elements of the same record are the written procedures with a stated content, and this guide builds both layers so that the records exist when the procedures first run. The duty applies from the Annex III application date Deferred for a system classified under Art. 6(2), and from the Annex I date Deferred for a system under Art. 6(1); Regulation (EU) 2026/1744 moved those dates and left the content of Art. 17(1) unchanged, as the regulation entry for each date records.
Three paragraphs shape the size of the set. Art. 17(2) makes the implementation proportionate to the size of the provider's organisation, in particular where the provider is an SME, including a start-up, or an SMC, and requires the provider in any event to keep the degree of rigour and the level of protection the Regulation requires; Regulation (EU) 2026/1744 inserted the reference to SMEs, start-ups and SMCs. Art. 17(3) lets a provider that already runs a quality management system under sectoral Union law include the Art. 17(1) aspects in that system. Art. 17(4) deems the obligation fulfilled for a financial institution that complies with the internal governance rules under Union financial services law, except for points (g), (h) and (i), which the institution documents in full. Art. 63(1), as amended by Regulation (EU) 2026/1744, lets an SME, including a start-up, that has no partner or linked enterprises comply with certain elements of the system in a simplified manner, following guidelines the Commission develops; the derogation was extended from microenterprises to SMEs, and Art. 63(2) keeps every other requirement of the Regulation in force for the same provider. The set this guide builds is examined twice in the conformity assessment: under Annex VI point 2 the provider verifies that the established quality management system meets Art. 17, and under Annex VII point 3 a notified body assesses the same system and the provider informs it of any intended change to the approved system. The clause structure of the set comes from prEN 18286Published, a published European standard with an Annex ZA mapping to the Act and not cited in the Official Journal; the standards page shows its stage. The clause-by-clause crosswalk to ISO/IEC 42001:2023Published, published, is in the related guide on ISO/IEC 42001 and Art. 17 and is not repeated here.
Inputs
The inputs are the subset of the PR-17-QMS v1.0 input table that the preparation steps use, plus the tools the examples call. The full table is on the protocol page.
- Every existing policy, procedure, instruction and record template of the provider that touches the high-risk AI system, in any format that preserves text, with a document id and a version per document where one exists.
- The release history of the high-risk AI system with version ids, and the decision field of the change process where one exists.
- The existing record stores: the design review tool, the test runner output, the dataset documentation, the incident tracker and the document management system, with read access.
- The risk management file, the post-market monitoring plan and the serious incident reporting procedure, where drawn up, each with a version id.
- The organisation chart or role list of the management and staff who act on the high-risk AI system.
- The statement of the provider's size status under Art. 17(2) and, where claimed, the SME status without partner or linked enterprises under Art. 63(1), as the provider states it.
- For an Art. 17(3) or Art. 17(4) provider: the index of the sectoral quality management system or of the financial services governance documents.
- A shell with
find,sha256sumandpythonwith the PyYAML parser installed.
Procedure
Each step names the protocol step or the clause it derives from and the record it produces. Code blocks follow the step they belong to. Every document id, title, version, path, hash and count in the examples is synthetic.
Record the system, the version, the provider role, the Annex route and the Art. 43 route the strategy will name.
Record review scope record: system, version, provider role, Annex I or Annex III route, conformity assessment route under Art. 43
[AIAssuranceLabs procedure; PR-17-QMS step 1]
Fix the document convention: three kinds (policy, procedure, record), an id scheme, a version rule and an owner role field.
Record document convention record: id scheme per kind, version rule, owner role field, status values
[Regulation (EU) 2024/1689, Art. 17(1); prEN 18286, published, clauses on documentation requirements; ISO/IEC 42001:2023 §7.5]
Open the register with one entry per point (a) to (m), each naming a procedure and a record type.
Record document register: one entry per Art. 17(1) point with the documents that serve it, each with id, kind, owner role and status
[Regulation (EU) 2024/1689, Art. 17(1) points (a) to (m); PR-17-QMS step 2]
Draft the compliance strategy with the Art. 43 route, the modification procedure and the substantial-modification rule.
Record regulatory compliance strategy: Art. 43 route, conformity assessment steps, substantial-modification rule, re-assessment trigger
[Regulation (EU) 2024/1689, Art. 17(1)(a) and Art. 43(4); PR-17-QMS step 9]
Draft each procedure with the content its point names, including the frequency under (d) and the retention period under (k).
Record one procedure per point with the fields the point names: activities and frequency under (d), data operations under (f), reporting path, authority and Art. 73 timeframes under (i), records, location and retention period under (k)
[Regulation (EU) 2024/1689, Art. 17(1)(b), (c), (d), (f), (i), (j), (k) and (l); PR-17-QMS steps 13, 18, 20 and 22]
Draft the applied standards list with the stage of each document. State the means used for each Chapter III Section 2 requirement that no harmonised standard covers.
Record applied specifications and standards list: designation, stage, OJEU citation flag, requirement addressed, statement of means per Chapter III Section 2 requirement not covered
[Regulation (EU) 2024/1689, Art. 17(1)(e); PR-17-QMS step 15]
Draft the accountability framework as responsibilities of named roles for each Art. 17(1) point, one row per responsibility.
Record accountability framework: one responsibility per role per Art. 17(1) point, with the role holder to confirm in the walk-through
[Regulation (EU) 2024/1689, Art. 17(1)(m); ISO/IEC 42001:2023 §5.3 and Annex A control A.3.2; PR-17-QMS step 23]
Define a record template per testable element with version id, date, outcome or decision field and storage location.
Record record template per testable element: fields, version id field, date field, outcome or decision field, storage location
[Regulation (EU) 2024/1689, Art. 17(1)(a), (b), (c), (d) and (f); PR-17-QMS steps 10, 11, 12, 14 and 16]
Write the proportionality record: size status as the provider states it, elements simplified, and the degree of rigour kept.
Record proportionality record: size status as stated by the provider, elements implemented in a simplified manner with the guideline reference, statement that the degree of rigour is kept
[Regulation (EU) 2024/1689, Art. 17(2) and Art. 63(1); PR-17-QMS step 4]
Where Art. 17(3) or 17(4) applies, map each Art. 17(1) point to the sectoral or governance element that holds it. Keep points (g), (h) and (i) documented in full.
Record sectoral or financial services mapping: Art. 17(1) point, element of the sectoral or governance system that holds it, points (g), (h) and (i) marked as documented in full
[Regulation (EU) 2024/1689, Art. 17(3) and 17(4); PR-17-QMS step 5]
Freeze the set: hash every file the register points to and file the list with its set identifier.
Record frozen document set: path and content hash per file, set identifier, filing date field
[prEN 18286, published, clauses on document and record control; ISO/IEC 42001:2023 §7.5.3; AIAssuranceLabs procedure]
Run the completeness check. File the register, the frozen set and the check output for the Annex VI or Annex VII examination.
Record completeness check output: points without a procedure, points without a record, documents with status missing or without an owner role, exit code
[AIAssuranceLabs procedure; PR-17-QMS step 8; Regulation (EU) 2024/1689, Annex VI point 2 and Annex VII point 3]
Example for step 3. The register below has one entry per Art. 17(1) point. Each entry lists the documents that serve it with an id, a kind, an owner role and a status; the owner role is a role name, never a person. The status values are approved for a released document, draft for a document under review, in-use for a record type whose store exists, and missing for a document the register names and the provider does not yet hold. Two entries are left incomplete on purpose: point (e) has no record and point (h) has no procedure, so that the check in step 12 has something to report. Every id, title and version is synthetic.
# Synthetic example: qms-register.yaml for demo-system 2.4.0
system: demo-system
version: "2.4.0"
route: annex-vi-internal-control # annex-vi-internal-control | annex-vii-notified-body | annex-i-sectoral
size_status: sme-no-linked-enterprises # as stated by the provider; the register records, it does not decide
points:
- id: a
aspect: strategy for regulatory compliance, conformity assessment, management of modifications
documents:
- { id: POL-001, kind: policy, title: AI quality policy and regulatory compliance strategy, owner_role: head of quality, status: approved }
- { id: PRC-012, kind: procedure, title: change control and substantial-modification decision, owner_role: head of quality, status: approved }
- { id: REC-CHG, kind: record, title: modification record per released version, owner_role: head of quality, status: in-use }
- id: b
aspect: design, design control and design verification
documents:
- { id: PRC-020, kind: procedure, title: design control and design verification, owner_role: engineering lead, status: approved }
- { id: REC-DVR, kind: record, title: design verification record with design input trace, owner_role: engineering lead, status: in-use }
- id: c
aspect: development, quality control and quality assurance
documents:
- { id: PRC-021, kind: procedure, title: development and quality assurance, owner_role: engineering lead, status: approved }
- { id: REC-QCR, kind: record, title: quality control record per release, owner_role: engineering lead, status: in-use }
- id: d
aspect: examination, test and validation before, during and after development, with frequency
documents:
- { id: PRC-030, kind: procedure, title: examination, test and validation with stated frequency, owner_role: test lead, status: draft }
- { id: REC-TST, kind: record, title: test and validation run record with version id, owner_role: test lead, status: in-use }
- id: e
aspect: technical specifications and standards applied; means for uncovered Section 2 requirements
documents:
- { id: PRC-050, kind: procedure, title: standards selection and coverage statement, owner_role: regulatory affairs lead, status: draft }
- id: f
aspect: data management from acquisition to retention
documents:
- { id: PRC-040, kind: procedure, title: data management, owner_role: data lead, status: approved }
- { id: REC-DAT, kind: record, title: dataset lineage record per set, owner_role: data lead, status: in-use }
- id: g
aspect: risk management system under Art. 9
documents:
- { id: PRC-090, kind: procedure, title: risk management, owner_role: risk owner, status: approved }
- { id: RMF-001, kind: record, title: risk management file with hazard register, owner_role: risk owner, status: in-use }
- id: h
aspect: post-market monitoring system under Art. 72
documents:
- { id: REC-PMM, kind: record, title: post-market monitoring plan and analysis records, owner_role: product owner, status: missing }
- id: i
aspect: serious incident reporting under Art. 73
documents:
- { id: PRC-073, kind: procedure, title: serious incident reporting with authority and timeframes, owner_role: head of quality, status: approved }
- { id: REC-INC, kind: record, title: incident register, owner_role: head of quality, status: in-use }
- id: j
aspect: communication with authorities, notified bodies, operators, customers and interested parties
documents:
- { id: PRC-060, kind: procedure, title: communication with authorities and customers, owner_role: head of quality, status: approved }
- { id: REC-COR, kind: record, title: correspondence register, owner_role: head of quality, status: in-use }
- id: k
aspect: record-keeping of all relevant documentation and information
documents:
- { id: PRC-070, kind: procedure, title: record control with location and retention period, owner_role: head of quality, status: approved }
- { id: REC-REG, kind: record, title: record register, owner_role: head of quality, status: in-use }
- id: l
aspect: resource management, including security of supply
documents:
- { id: PRC-080, kind: procedure, title: resource and supplier management, owner_role: operations lead, status: approved }
- { id: REC-SUP, kind: record, title: supplier and resource register, owner_role: operations lead, status: in-use }
- id: m
aspect: accountability framework for management and other staff
documents:
- { id: POL-002, kind: policy, title: accountability framework, owner_role: managing director, status: approved }
- { id: PRC-100, kind: procedure, title: role assignment and review, owner_role: managing director, status: approved }
- { id: REC-ROL, kind: record, title: role register with walk-through confirmations, owner_role: managing director, status: in-use }
Example for step 5. The fields below are the ones the procedure for point (d) carries when it is drafted from the article text. The frequency is a value the provider sets and justifies, because Art. 17(1)(d) asks for the frequency and names none; the justification is the row the element-evidence step of PR-17-QMS v1.0 records. The values shown are synthetic.
# Synthetic example: header block of PRC-030, examination, test and validation procedure
doc_id: PRC-030
version: 3
owner_role: test lead
point: d
activities:
- phase: before development
activity: acceptance criteria review against the risk management file
frequency: once per planned release
- phase: during development
activity: unit and integration test run
frequency: every merge to the release branch
- phase: after development
activity: full validation run on the held-out set
frequency: every release candidate and every twelve weeks in service
frequency_rationale: RMF-001 hazard H-07 names data drift; the interval is the provider's justified value, not a value from the Act
record_type: REC-TST
record_fields: [run_id, version_id, date, test_set_id, metric, threshold, result, signatory_role]
Example for step 11. The first command lists every file under the policy, procedure and record-template folders, sorts the list so that the output is stable between runs, and writes one digest per file. The second command hashes the list itself, which gives the set a single identifier for the register. The third command runs before the Annex VI or Annex VII examination and fails when any frozen file has changed or disappeared. The paths are synthetic.
# Synthetic example: freeze every file the register points to.
find docs/qms/policies docs/qms/procedures docs/qms/record-templates -type f \
\( -name '*.md' -o -name '*.yaml' -o -name '*.pdf' \) -print0 \
| sort -z | xargs -0 sha256sum > qms-frozen-set.txt
wc -l qms-frozen-set.txt
# Set identifier for the register: the digest of the sorted list.
sha256sum qms-frozen-set.txt | cut -c1-16
# Before the examination: exit code 1 if any frozen file changed or is missing.
sha256sum --check --quiet qms-frozen-set.txt
Example for step 12. The script loads the register, checks that all thirteen points (a) to (m) have an entry, that every point lists at least one procedure and at least one record, that every document carries an owner role, and that no document the register names has the status missing. It prints one line per failure and exits with code 1 when any point fails, so that it can run as a repository check before the set is filed. It needs the PyYAML parser.
# Synthetic example: check qms-register.yaml for a procedure and a record per Art. 17(1) point.
import sys
import yaml
POINTS = list("abcdefghijklm")
KINDS = {"policy", "procedure", "record"}
with open("qms-register.yaml", encoding="utf-8") as f:
register = yaml.safe_load(f)
entries = {p["id"]: p for p in register.get("points", [])}
failures = []
for pid in POINTS:
entry = entries.get(pid)
if entry is None:
failures.append((pid, "no entry in register"))
continue
docs = entry.get("documents") or []
kinds = {d.get("kind") for d in docs}
if "procedure" not in kinds:
failures.append((pid, "no procedure"))
if "record" not in kinds:
failures.append((pid, "no record type"))
for d in docs:
if d.get("kind") not in KINDS:
failures.append((pid, "%s: kind %r is not policy, procedure or record" % (d.get("id"), d.get("kind"))))
if not d.get("owner_role"):
failures.append((pid, "%s: no owner role" % d.get("id")))
if d.get("status") == "missing":
failures.append((pid, "%s: status missing" % d.get("id")))
for pid in entries:
if pid not in POINTS:
failures.append((pid, "entry id is not an Art. 17(1) point"))
for pid, reason in failures:
print("FAIL (%s) %s" % (pid, reason))
complete = sum(
1 for p in POINTS
if {"procedure", "record"} <= {d.get("kind") for d in entries.get(p, {}).get("documents", [])}
)
print("%d of %d points have a procedure and a record; %d failures" % (complete, len(POINTS), len(failures)))
sys.exit(1 if failures else 0)
On the synthetic register above the script reports three failures: point (e) has no record type, point (h) has no procedure, and the post-market monitoring record REC-PMM carries the status missing. The register is then eleven of thirteen points complete, and the two open points carry a finding in the gap register that PR-17-QMS v1.0 opens in its preparation steps, before any record is sampled. Every count is an output of this example, never a requirement of the Act.
A pitfall that vendor documentation omits
Quality-management templates and GRC tooling deliver Art. 17 as a manual: one document with thirteen headings and a paragraph of policy under each. Art. 17(1) asks for three kinds of document, and the Art. 17 obligation record names the resulting finding first: the quality management system exists as a policy statement without the procedures and instructions the article names. A heading that says the provider tests before, during and after development is a policy; the procedure under point (d) states which activity runs at which phase and at which frequency, and the record shows that a run happened on a named version. The same record names the two findings a manual cannot avoid: examination, test and validation procedures that state what is tested but not the frequency Art. 17(1)(d) asks for, and modification management with no rule for deciding whether a change is a substantial modification, so that the re-assessment step in the compliance strategy is never triggered. Under Annex VI point 2 the provider verifies the established system against Art. 17, and under Annex VII point 3 the notified body assesses it and the provider informs the notified body of any intended change to the approved system; a manual gives neither examination a record to read, which is why the check in step 12 fails on a point that has a policy and nothing else.
Proportionality is the second pitfall. Art. 17(2) scales the implementation to the size of the organisation and keeps the degree of rigour and the level of protection in the same sentence, so a smaller provider writes shorter procedures and fewer roles while every point keeps a procedure and a record. The simplified manner under Art. 63(1) is narrower still: it is open to an SME, including a start-up, with no partner or linked enterprises, it covers the elements the Commission guidelines name, and Art. 63(2) keeps Art. 9 to 15, Art. 72 and Art. 73 in force for the same provider. Art. 17(4) has the same shape for a financial institution: the governance rules under Union financial services law stand in for the system, and points (g), (h) and (i) are documented in full regardless. The proportionality record in step 9 records the size status as the provider states it; PR-17-QMS v1.0 does not decide that status, and its Limitations section says so.
Regulation (EU) 2024/1689 sets no numeric threshold in Art. 17: no test frequency for point (d), no retention period for point (k) beyond the one Art. 18(1) sets, no sampling depth, and no size figure in Art. 17(2). No harmonised standard for Art. 17 is cited in the Official Journal as of the anchor date, so no presumption of conformity exists at the first level of the source hierarchy. The structure comes from level 2, prEN 18286Published, published and not cited in the Official Journal, and level 3, ISO/IEC 42001:2023Published, published; neither document publishes a frequency, a period or a depth, so each value is the provider's justified choice against the context of use, recorded per point in the element-evidence step of the protocol. The methodology index states the same hierarchy for every protocol.
What the result shows and what it does not
The register, the frozen set and the check output show, for one version at one point in the lifecycle, that a written procedure and a record type exist for each Art. 17(1) point under a policy, who owns each document, and that the set has not changed since it was frozen. They do not show that the quality management system operates: a record type in the register is a template until the procedure runs, and the eight testable elements are verified by sampling, retrieving and walking through records that the procedures produce after this guide ends; the execution steps of PR-17-QMS v1.0 do that sampling, and the protocol cannot show that the system operated between the sampled versions or that it will operate after the review. The check does not read the content of a procedure, so a procedure under point (d) that names no frequency passes the check and fails the protocol's documentation check. The classification of a change as a substantial modification and the SME, start-up or SMC status under Art. 17(2) and Art. 63(1) are the provider's decisions, which the register records and does not decide. The result is evidence for the provider's own verification under Annex VI point 2 or for the notified body's assessment under Annex VII point 3; the decision whether the system meets Art. 17 remains with the provider, their notified body where one is required, and their counsel. The QMS gap analysis service runs the full protocol and delivers the gap register, corrective-action plan and internal audit checklist, and its scope limits are on what we cannot do.
Related pages
The obligation, the protocol, the related guides on the ISO/IEC 42001 crosswalk and on the two conformity assessment routes that examine this set, and the hubs for the three roles this guide serves are listed below.
- Obligations
- Protocols
- Related guides
Every inquiry receives a reply within 24 hours. Scope and availability are discussed per request.