QMS gap analysis
We test the quality management system of a high-risk AI system against each aspect of Art. 17(1) points (a) to (m), and the risk management system that Art. 17(1)(g) places inside it against Art. 9, under PR-17-QMS v1.0. Written procedures are checked as documents, and the records each procedure names are sampled, retrieved and walked through. The client receives a gap analysis with a classified gap register, a corrective-action plan and an internal audit preparation checklist, ahead of the Annex III application date Deferred.
Deliverables
The set is designed for the three readers of a quality management system: the provider's own internal control under Annex VI point 2, which verifies that the system is in place under Art. 17; a notified body that assesses the system under Annex VII section 3; and the internal audit that ISO/IEC 42001:2023Published clause 9.2 asks for. Each type is specified with a synthetic sample on the deliverables page: the gap analysis and the corrective-action plan follow the findings register specification, and the internal audit preparation checklist follows the register or checklist specification.
| Deliverable | Type | Format | Designed to satisfy |
|---|---|---|---|
QMS gap analysis against Article 17, prEN 18286 and ISO/IEC 42001 Annex AprEN 18286PublishedISO/IEC 42001:2023Published | Findings register | XLSX; CSV; PDF summary | |
| Corrective-action plan | Findings register | XLSX; CSV; PDF summary | |
| Internal audit preparation checklist | Register or checklist | XLSX; CSV; Markdown |
Who this is for
- Annex III providers
- Annex I manufacturers
- Enterprises
A provider of a standalone Annex III system carries the full Chapter III Section 2 set, and Art. 17(1) is where the other requirements have to be run as procedures with records: the risk management system in point (g), the data management in point (f), the test and validation procedures with their frequency in point (d), the record-keeping in point (k). A manufacturer whose AI is a safety component of an Annex I product already runs a quality system and a notified body relationship under the sectoral law, and Art. 17(3) allows the Art. 17(1) aspects to sit inside that system; the practical task is the mapping from each aspect to the sectoral element that holds it, and the Annex I application date Deferred sets the pace for that route. An organisation with many AI use cases, some built and some bought, needs one register that internal audit, risk and the security function read in the same way, and a gap register with one row per Art. 17(1) aspect is that register for the systems the organisation provides.
One entry sets the urgency for standalone systems: the Annex III application date, moved by Regulation (EU) 2026/1744 with the content of Art. 17 unchanged.
Scope
The engagement covers the quality management system of one provider for one high-risk AI system under Annex III or Annex I, whether the system is already in place or still being built; the limits of every result are stated on what we cannot do. PR-17-QMS v1.0 checks three groups of elements. Documents: the written policies, procedures and instructions for each Art. 17(1) aspect, the proportionality rationale under Art. 17(2) and Art. 63(1), and the sectoral or financial-services mapping under Art. 17(3) and 17(4), each marked present, partial or absent with a location. Records: the eight testable elements of the Art. 17 obligation record, sampled for the current version and one earlier version, with a retrieval test, a simulated serious incident walk-through and an accountability walk-through. Risk management: the risk management file under Art. 17(1)(g), checked against the six testable elements of the Art. 9 obligation record as records, with the hazard register, the acceptance criteria, the prior defined metrics and thresholds under Art. 9(8) and the residual risk comparison under Art. 9(5).
The clause map that the protocol builds rests on prEN 18286Published, a published European standard from CEN-CENELEC JTC 21 with an Annex ZA mapping to the Act, and on ISO/IEC 42001:2023Published, whose management-system clauses and Annex A controls map to most Art. 17(1) points. The risk management review uses ISO/IEC 23894:2023Published as its reference process and prEN 18228Enquiry, which is at enquiry stage and whose clause content can still change, for the Art. 9 record set. Where a provider holds framework artifacts under NIST AI RMF 1.0Published, the Govern function maps to points (a) and (m) and the map records what those artifacts cover. No harmonised standard for Art. 17 or Art. 9 is cited in the Official Journal as of the anchor date, so no presumption of conformity attaches to any of these documents or to any output of the engagement; the standards page tracks the count, and each standard is evidence of structure, never a requirement in itself.
The engagement does not execute the tests that the risk management file names; PR-15-ROB v1.0 executes them under the robustness and adversarial testing service, and the gap register records the cross-reference. The engagement does not perform a conformity assessment under Art. 43, does not decide whether a change is a substantial modification, and does not give an opinion on SME, start-up or SMC status under Art. 17(2) and Art. 63(1); those decisions are recorded as the provider states them. The Art. 17(1)(e) check records the statement of means the provider gives for each Chapter III Section 2 requirement and does not test whether the means are adequate.
The protocol applies to a system the provider has classified as high-risk. Where the provider relies on Art. 6(3) to conclude that an Annex III system is not high-risk, the registration duty that follows is an unsettled point and sits outside this engagement; both readings are shown below with the working reading marked.
What we test
The table lists the testable elements of the Art. 17 and Art. 9 obligation records, with the protocol that checks each element and the artifacts it produces for the record; the Art. 9 rows are checked as records in the risk management file, and their execution sits in a separate protocol.
| Obligation | Testable element | Protocol | Artifacts |
|---|---|---|---|
| Art. 9 | The system performs consistently for its intended purpose across the operating conditions recorded in the risk management file, with a result per condition (Art. 9(6)). | PR-17-QMS v1.0 |
|
| Each test in the risk management file runs against a prior defined metric and probabilistic threshold, and the result either meets the threshold or does not (Art. 9(8)). | PR-17-QMS v1.0 | ||
| The residual risk of each hazard after the adopted measures is measured and compared with the acceptance criterion recorded for that hazard, and the overall residual risk is compared with the overall criterion (Art. 9(5)). | PR-17-QMS v1.0 | ||
| Each technical risk management measure adopted under Art. 9(2)(d), such as an input check, a filter, a fallback or a guardrail, activates on the hazard scenarios it addresses and produces the recorded effect (Art. 9(5)(a) and 9(5)(b)). | PR-17-QMS v1.0 | ||
| The system's behaviour under each reasonably foreseeable misuse condition recorded under Art. 9(2)(b) is observed and recorded against the expected behaviour. | PR-17-QMS v1.0 | ||
| Where the Art. 9(9) consideration identifies a likely adverse impact on persons under the age of 18 or other vulnerable groups, the test set contains cases that represent those groups and the results are reported for them. | PR-17-QMS v1.0 | ||
| Art. 17 | Each released version of the high-risk AI system has a modification record that states whether the change is a substantial modification and which conformity assessment step follows (Art. 17(1)(a)); verified by record sampling | PR-17-QMS v1.0 |
|
| Design verification records exist for the current version and trace each verified item to a design input (Art. 17(1)(b)); verified by record sampling | PR-17-QMS v1.0 | ||
| Quality control records for the current release show the checks and outcomes that the development procedure names (Art. 17(1)(c)); verified by record sampling | PR-17-QMS v1.0 | ||
| Examination, test and validation records exist for the current version at the frequency the procedure states, and each record names the version tested (Art. 17(1)(d)); verified by record sampling against the stated frequency | PR-17-QMS v1.0 | ||
| Dataset records for the training, validation and testing sets show the acquisition, labelling, storage and retention steps that the data management procedure names (Art. 17(1)(f)); verified by record sampling | PR-17-QMS v1.0 | ||
| A simulated serious incident walked through the reporting procedure reaches the reporting step with the market surveillance authority and the Art. 73 timeframe identified (Art. 17(1)(i)); verified by procedure walk-through | PR-17-QMS v1.0 | ||
| A sample of the records named in the record-keeping procedure is retrievable for the current version and for one earlier version within the retention period the procedure states (Art. 17(1)(k)); verified by retrieval test | PR-17-QMS v1.0 | ||
| Each responsibility in the accountability framework is held by a named role, and the role holder confirms the responsibility in a walk-through (Art. 17(1)(m)); verified by role walk-through | PR-17-QMS v1.0 |
Art. 17 and Art. 9 set no numeric threshold: neither article names a test frequency, a sampling depth, a retention period or a residual risk level, and Art. 17(2) states proportionality without a size figure. The reference for each element follows a six-level hierarchy: a harmonised standard cited in the Official Journal, of which none exists as of the anchor date; a JTC 21 draft standard named with its stage, which is prEN 18286Published for the clause structure and prEN 18228Enquiry for the risk management records; an ISO/IEC standard, which is ISO/IEC 42001:2023Published for the management-system clauses; a Commission guideline or code of practice; NIST AI RMF or a sector framework; and the provider's justified state of the art. Where a document names a frequency or a period, the gap register cites the clause and its condition. Where none does, there is no published threshold; the provider justifies the frequency, the retention period and the sampling depth against the context of use, and the element-evidence step of PR-17-QMS v1.0 records that justification for each Art. 17(1) point. No figure on this page is attributed to the Act.
Protocols used
One protocol runs the service; its version, derivation and revision history are on its page.
- PR-17-QMS v1.0QMS gap analysis protocolv1.0
PR-17-QMS v1.0 covers the written procedures for Art. 17(1) points (a) to (m), the sampled records behind eight of them, and the risk management file under Art. 17(1)(g) against the Art. 9 elements. It produces the QMS gap analysis report with the classified gap register, the risk management system review record, the corrective-action plan with an owner role and a closing evidence field per row, and the internal audit preparation checklist with one question per mapped clause. It reviews documents and sampled records at one point in the lifecycle, so it does not show that the system operated between the sampled versions or that it will operate after the review; a walk-through follows one simulated incident and one set of role holders, so it does not show that every incident type reaches the reporting step; and it checks that test records exist and sit within the recorded criteria without showing that any result is correct.
Engagement shape
The service is fixed-scope, scoped per request, and usually follows the classification and readiness assessment, whose obligation register names the route and the articles in scope. The client provides the quality management system manual, the release history and modification records, the design verification, quality control and test records, the dataset records for the training, validation and testing sets, the risk management file with its hazard register and acceptance criteria, the post-market monitoring plan, the serious incident reporting procedure with one agreed simulated scenario, the accountability framework with the role holders available for a walk-through, the internal audit programme and management review minutes, the proportionality rationale and any sectoral mapping, and read access to the record-keeping system. The work follows the order of the protocol: preparation, in which the scope is recorded, the documents are inventoried, the clause map and the sampling plan are built and the gap register is opened; execution, in which each Art. 17(1) aspect is checked as a document and as sampled records, the incident and accountability walk-throughs are run, and the risk management file is reviewed paragraph by paragraph; analysis, in which each gap is classified, the corrective action is drafted with its owner role and the audit checklist is built; and reporting, in which the gap analysis report, the plan and the checklist are delivered for the provider's review.
What we cannot do
- We do not perform conformity assessments where a notified body is required.
- We do not issue CE marking or the EU Declaration of Conformity.
- We are not a notified body.
- We do not give legal opinions on classification or liability.
- We test against requirements, prepare evidence, and structure documentation; compliance decisions remain with the provider or deployer, their notified body, and their counsel.
For this service the gap analysis is a review against the Art. 17(1) list and the published clause structures; it is not the Annex VI internal control of the provider, not an Annex VII assessment by a notified body, and no certificate follows it. The corrective-action plan names an owner role and a closing-evidence field for each gap, and the provider executes it; the mock conformity assessment service later reads the corrected system the way a notified body would.
What the client must have ready
The documentation and process elements below are read and cross-checked during the engagement; the gap register records which are present, partial or absent, with the document id and version of each.
Art. 9Risk management system
- The risk management system is documented in a risk management file that records the risks identified, the estimation and evaluation method, the measures adopted and the residual risk judgement (Art. 9(1) and 9(5)). documentation
- Each hazard is recorded with the intended purpose and the reasonably foreseeable misuse conditions under which it was identified and evaluated (Art. 9(2)(a) and 9(2)(b)). documentation
- For each risk, the file states whether design, development or adequate technical information can reasonably mitigate or eliminate it, which fixes the scope of Art. 9 for that risk (Art. 9(3)). documentation
- The interaction analysis records how the measures taken under Art. 10 to Art. 15 affect each other and the balance the provider chose (Art. 9(4)). documentation
- The acceptance criterion for the residual risk of each hazard and for the overall residual risk is stated before testing, with its rationale (Art. 9(5)). documentation
- The Art. 13 information and any deployer training are described together with the technical knowledge, experience, education and training expected of the deployer and the presumable context of use (Art. 9(5)(c)). documentation
- Where testing in real-world conditions takes place, the plan and the conditions under Art. 60 are documented (Art. 9(7)). documentation
- The prior defined metrics and probabilistic thresholds are recorded before the test runs, with the reason each is appropriate to the intended purpose (Art. 9(8)). documentation
- Test records identify the system version tested and show that a full test run took place before placing on the market or putting into service (Art. 9(8)). documentation
- The consideration of adverse impact on persons under the age of 18 and other vulnerable groups is recorded with its outcome (Art. 9(9)). documentation
- Where the provider combines Art. 9 with a risk management procedure under other Union law, a mapping shows where each aspect of Art. 9(1) to 9(9) is covered (Art. 9(10)). documentation
- The risk management system is established, implemented and maintained as a continuous iterative process that is planned and run through the entire lifecycle of the system (Art. 9(1) and 9(2)). process
- The risk management system is reviewed and updated regularly and systematically, with a defined trigger and a record of each review (Art. 9(2)). process
- Data from the post-market monitoring system under Art. 72 is analysed and other risks that arise are evaluated in the risk management cycle (Art. 9(2)(c)). process
- Risk management measures are adopted for the identified risks in the order of Art. 9(5): elimination or reduction by design and development, then mitigation and control measures, then information and training for deployers (Art. 9(2)(d) and 9(5)). process
- Testing takes place at any time during the development process as appropriate, and is repeated before placing on the market or putting into service (Art. 9(8)). process
- A provider subject to internal risk management requirements under other Union law may run the Art. 9 aspects inside that procedure (Art. 9(10)). process
Art. 17Quality management system
- The quality management system is documented in written policies, procedures and instructions (Art. 17(1)) documentation
- A strategy for regulatory compliance names the conformity assessment procedure the provider follows and the procedure for the management of modifications (Art. 17(1)(a)) documentation
- Techniques, procedures and systematic actions for design, design control and design verification are written (Art. 17(1)(b)) documentation
- Techniques, procedures and systematic actions for development, quality control and quality assurance are written (Art. 17(1)(c)) documentation
- Examination, test and validation procedures state what is carried out before, during and after development, and the frequency of each (Art. 17(1)(d)) documentation
- A list of the technical specifications and standards applied, and, where harmonised standards are not applied in full or do not cover a Chapter III Section 2 requirement, a statement of the means used for that requirement (Art. 17(1)(e)) documentation
- Data management procedures cover data acquisition, collection, analysis, labelling, storage, filtration, mining, aggregation and retention (Art. 17(1)(f)) documentation
- The post-market monitoring plan that Art. 72(3) requires is part of the quality management system documentation (Art. 17(1)(h)) documentation
- Serious incident reporting procedures name the reporting path, the authority and the Art. 73 timeframes (Art. 17(1)(i)) documentation
- Procedures for the handling of communication with authorities, notified bodies, other operators, customers and other interested parties are written (Art. 17(1)(j)) documentation
- Record-keeping procedures name the records kept, where they are kept and the retention period of each (Art. 17(1)(k)) documentation
- Resource management, including security-of-supply related measures, is described (Art. 17(1)(l)) documentation
- The accountability framework sets out the responsibilities of the management and other staff for each Art. 17(1) aspect (Art. 17(1)(m)) documentation
- A proportionality rationale records how the size of the organisation, including SME, start-up or SMC status, shaped the implementation and shows that the degree of rigour is kept (Art. 17(2)) documentation
- Where a sectoral quality management system is used, a mapping from each Art. 17(1) aspect to the element of the sectoral system that holds it (Art. 17(3)) documentation
- Where Art. 17(4) applies, a mapping from the Union financial services governance rules to the quality management system obligation, with points (g), (h) and (i) documented separately (Art. 17(4)) documentation
- Where an SME uses the simplified manner, a record of the SME status without partner or linked enterprises and of the elements simplified under the Commission guidelines (Art. 63(1)) documentation
- The quality management system operates across the lifecycle and is kept current after each modification of the system (Art. 17(1)) process
- Modifications to the high-risk AI system are managed under the written procedure before release (Art. 17(1)(a)) process
- Quality assurance activities run during development as the procedure states (Art. 17(1)(c)) process
- Examination, test and validation are repeated after development at the stated frequency (Art. 17(1)(d)) process
- The risk management system under Art. 9 runs as part of the quality management system (Art. 17(1)(g)) process
- The post-market monitoring system is set up, implemented and maintained in accordance with Art. 72 (Art. 17(1)(h)) process
- Serious incidents are reported to the market surveillance authority in accordance with Art. 73 (Art. 17(1)(i)) process
- Communication with authorities, notified bodies, other operators and customers follows the written procedure (Art. 17(1)(j)) process
- Records are kept under the record-keeping procedure for the period set in Art. 18 (Art. 17(1)(k)) process
- Resources, including security of supply, are managed under the written measures (Art. 17(1)(l)) process
- Responsibilities are assigned to roles and kept current as management and staff change (Art. 17(1)(m)) process
- Risk management, post-market monitoring and serious incident reporting continue for a financial institution that relies on Art. 17(4) (Art. 17(4)) process
Inputs take the formats listed in the inputs table of PR-17-QMS v1.0: each policy, procedure and instruction as a document export with a document id, title, version and owner role; the release history as a change log or ticket export with version ids and decision fields; the records as exports or read access to the record system with the version id on each record; the hazard register as a CSV or spreadsheet with a hazard id per row; and the record-keeping system as a read-only account or a supervised session for the retrieval test.
Questions
Do I need a new quality management system for the AI Act?
Art. 17(1) of Regulation (EU) 2024/1689 requires a provider of a high-risk AI system to have a quality management system with the aspects in points (a) to (m); it does not require a separate system. Art. 17(3) allows a provider under sectoral quality management rules to include those aspects in the existing system, and Art. 17(4) treats a financial institution's Union governance rules as meeting the obligation, except for points (g), (h) and (i). PR-17-QMS maps each aspect to the element of the existing system that holds it.
How does ISO 42001 relate to the EU AI Act?
ISO/IEC 42001:2023 is a published, voluntary management-system standard whose clauses and Annex A controls map to most Art. 17(1) points, from design to record-keeping and accountability. No harmonised standard for Art. 17 is cited in the Official Journal, so no presumption of conformity follows from it. It does not supply the Art. 17(1)(e) statement of means for uncovered Chapter III Section 2 requirements, and it does not name the Art. 72 and Art. 73 cross-references in points (h) and (i). The PR-17-QMS clause map records what each clause covers.
Is there a NIST AI RMF, ISO 42001 and EU AI Act crosswalk?
PR-17-QMS builds one in its preparation steps: a clause map with one row per Art. 17(1) aspect, the clause of prEN 18286, a published European standard not cited in the Official Journal, the clause and Annex A control of ISO/IEC 42001:2023, a published standard, and the Govern function of NIST AI RMF 1.0, a published framework. The map locates evidence. No presumption of conformity follows from any crosswalk, and a mapped clause shows where evidence may sit, not that the evidence exists.
ISO 42001 vs the AI Act: what is the difference?
Regulation (EU) 2024/1689 is law; Art. 17 binds the provider of a high-risk AI system, and Art. 43 sets the conformity assessment that follows. ISO/IEC 42001:2023 is a voluntary published standard for an organisation's AI management system, audited by a third party at the organisation's choice. The Act binds a system placed on the market; the standard structures the organisation that produces it. The PR-17-QMS gap register shows which Art. 17(1) aspects an ISO/IEC 42001:2023 system fills, fills in part, or leaves open.
Every inquiry receives a reply within 24 hours. Scope and availability are discussed per request.