Module 7 — Assurance: QMS, Internal Audit, Conformity Readiness

Module 7 of AI Risk Management Pro: the Art. 17 quality management system as the wrapper, internal control under Annex VI against a notified body under Annex VII, running a readiness review, and extracting supplier evidence under Art. 25(4).

By this module the artefacts exist: an inventory with derived classifications, a running register, data governance evidence, an Annex IV file, and an oversight and logging design. Assurance is the layer that makes them trustworthy to someone who did not build them — which is the only test that counts, because every asker in Module 1's list is exactly that person.

Art. 17: the QMS as the wrapper

Art. 17(1) requires providers of high-risk systems to put a quality management system in place that ensures compliance with the Regulation, documented in a systematic and orderly manner in the form of written policies, procedures and instructions. It then lists what it shall include, at least. Read as a table of "do we have a written procedure for this?":

Two observations that save work.

Most of this is already written, badly indexed. (b), (c), (d), (f) and (k) usually exist as engineering and data practice in some form. The QMS task is frequently to index and formalise rather than to author — to produce a document that says where each procedure lives, who owns it, and when it was last reviewed.

(m) is the one nobody has. An accountability framework naming management responsibilities is exactly the Module 1 mandate. If the mandate was written, (m) is done; if not, this is where its absence surfaces.

Art. 17(2) allows implementation to be proportionate to the size of the provider's organisation, and Art. 17(3) lets providers already subject to a sectoral QMS obligation — financial institutions in particular — integrate the AI Act elements into that system rather than running a parallel one. For a bank, the right answer is almost always integration.

Art. 43: which route, and the error that costs most

Conformity assessment is where planning errors are expensive, so settle it early and write it down.

Annex VI — conformity assessment based on internal control. The provider verifies that its QMS conforms to Art. 17, examines the technical documentation against the Chapter III requirements, and verifies consistency between the design and development process and the post-market monitoring plan. No third party is involved. Under Art. 43(2), this is the route for Annex III points 2 to 8.

Annex VII — involving a notified body. Assessment of the quality management system and of the technical documentation by a notified body. Under Art. 43(1), this applies to Annex III point 1 (biometrics) in defined circumstances — specifically, where the provider has not applied harmonised standards or has applied them only in part, or where such standards do not exist and no common specifications are available.

Annex I products follow the conformity assessment procedure in the relevant sectoral legislation (Art. 43(3)), with the AI Act requirements folded in.

The expensive error: budgeting for a notified body on an Annex III point 4 employment system or a point 5(b) credit system. Those are points 2 to 8, and they go through internal control. The absence of a harmonised standard does not change the route for them — it changes what you write in Annex IV element 7, which asks for a description of the solutions adopted where standards were not applied.

Also note Art. 43(4): a high-risk system that has already undergone a conformity assessment shall undergo a new one whenever it is substantially modified, regardless of whether the modified system is intended to be further distributed. Module 8 covers what counts.

And the paperwork that follows assessment: the Art. 47 EU declaration of conformity, drawn up and kept for ten years, machine-readable and signed; Art. 48 CE marking, affixed visibly, legibly and indelibly, or on packaging and documentation for digital-only systems; and Art. 49 registration in the EU database before placing on the market — including, under Art. 49(2), registration for systems the provider has concluded are not high-risk in reliance on Art. 6(3).

Running a readiness review

A readiness review is an internal audit with a narrow brief: not "do we understand the obligations" but "can we produce the file today". Four tests find most of what matters, and they are deliberately mechanical.

Test 1 — the file test. For every live high-risk system, open the Annex IV file. Count elements in the "gap, unmitigated" state from Module 5. The number should be zero before placing on the market; any non-zero number is the agenda.

Test 2 — the acceptance test. Sample ten rows marked "accepted" in the register. For each, is there a specific measure and a dated test result? This test fails more often than any other, and it fails against Art. 9(5)-(8).

Test 3 — the reconstruction test. Pick one decision from three months ago and reconstruct it end to end from logs: inputs, model version, output, reviewer, action, outcome. Module 6's seven fields.

Test 4 — the competence test. For every oversight assignment, is there a dated, system-specific training record and documented authority to overturn? Art. 26(2), Art. 99(4) band.

Each test produces either evidence or a register row with an owner and a date. A readiness review that produces a report instead of register rows has not closed the loop.

Getting evidence out of suppliers

Most organisations' exposure runs through systems they did not build, and the evidence they need is held by someone with no incentive to volunteer it. Three levers, in descending order of strength.

Art. 25(4) — the cooperation duty. Where a deployer's modification has made it the provider, the displaced provider shall cooperate closely, make available the necessary information, and provide the reasonably expected technical access and other assistance for compliance, in particular regarding the Annex IV documentation. This is a statutory duty, and it is far stronger than a commercial request — but it only bites once Art. 25 has been triggered.

Art. 13 instructions for use. A conformity artefact, not marketing material. Request it pre-contract; its thinness is the earliest reliable quality signal about a vendor. Specifically ask for Art. 13(3)(b): characteristics, capabilities and limitations of performance, including the level of accuracy, robustness and cybersecurity, known and foreseeable circumstances that may lead to risks, performance regarding specific persons or groups, and the specifications for the input data.

Contract. Audit rights, a notification obligation for substantial modifications, a commitment to supply Annex IV material on request, and an exit path. For DORA-regulated entities these clauses mostly already exist under Art. 28-30 of DORA — the task is to extend the existing ICT third-party arrangements to cover AI-specific evidence rather than to write a new annex. The AI Vendor Due Diligence pack sold separately on this site works this question as 32 questions with scoring and eight contract clauses.

What to do when a vendor simply will not answer: record it. A register row naming the missing evidence, its owner and the decision taken to proceed anyway is a defensible position. An unrecorded gap is not.

Check yourself

1. We need a notified body for our CV-screening system. — No. Annex III point 4 is in points 2 to 8, assessed by internal control under Annex VI (Art. 43(2)).
2. No harmonised standard covers our requirement, so we cannot self-assess. — The route is unchanged. Describe the solutions adopted in Annex IV element 7.
3. We concluded under Art. 6(3) that the system is not high-risk, so there is nothing to register. — Art. 49(2) requires registration anyway, and Art. 6(4) requires the documented assessment first.
4. We are a bank with an existing QMS, so we need a second one for AI. — Art. 17(3) lets you integrate the AI Act elements into the sectoral system.

Next: Module 8 — The operating cadence →