Module 5 — The Annex IV Technical File

Module 5 of AI Risk Management Pro: assembling the Art. 11 technical documentation element by element with an evidence owner and a completeness state, keeping it current, and what a deployer should demand under Art. 13 instead.

The Annex IV file is where a programme's discipline becomes visible, because it cannot be written from the Regulation. Every element asks for something that either exists because somebody recorded it at the time, or does not exist and cannot be reconstructed. The purpose of this module is to make the file an assembly job rather than a writing job.

The posture that makes it tractable

Three facts change how you approach it.

It is a precondition, not a deliverable. Art. 11(1): drawn up before the system is placed on the market or put into service, and kept up to date. A programme that schedules "write the technical file" for the quarter before launch has already lost elements 2(c) and 2(d), which are records of decisions made much earlier.

It is a ten-year obligation. Art. 18 requires it kept at the disposal of national competent authorities for ten years after placing on the market. That is a records-management requirement, not a document requirement: the file must survive team changes, tool migrations and the retirement of whatever system holds it today.

It is mostly links. The file does not have to restate the risk register, the data governance evidence or the test results. It has to reference them, authoritatively and durably. A file that duplicates those artefacts will drift from them, and then you have two answers to the same question — which is worse than one.

The elements, with an owner for each

Annex IV has seven numbered points. Here they are as an assembly table: what the element wants, where the evidence comes from in this track, and who typically owns it.

1 — General description of the system. Intended purpose; provider; version and its relationship to previous versions; how the system interacts with hardware or software that is not part of it; versions of relevant software or firmware; description of all forms in which it is placed on the market; description of the hardware on which it is intended to run; where it is a component of products, photographs or illustrations of external features; a basic description of the user interface; instructions for use for the deployer. Source: product definition plus Module 2's inventory row. Owner: product.

2 — Detailed description of the elements and of the development process. This is the heavy one, and it has sub-elements:

• (a) methods and steps performed for development, including recourse to pre-trained systems or tools from third parties and how they were used, integrated or modified;
• (b) design specifications: general logic, algorithms, key design choices including rationale and assumptions, including about the persons or groups on whom the system is intended to be used; main classification choices; what the system is designed to optimise for and the relevance of the different parameters; description of the expected output;
• (c) the system architecture, how software components build on or feed into each other, computational resources used;
• (d) the data requirements — datasheets describing training methodologies and techniques and the training datasets used, including provenance, scope and main characteristics, how the data was obtained and selected, labelling procedures, data cleaning methodologies;
• (e) assessment of the human oversight measures needed under Art. 14, including the technical measures to facilitate interpretation of outputs by deployers;
• (f) where applicable, a description of predetermined changes to the system and its performance, with the technical solutions adopted to ensure continuing compliance;
• (g) the validation and testing procedures used, including information about the validation and testing data and their main characteristics; metrics used to measure accuracy, robustness and compliance with Chapter III; test logs and all test reports dated and signed;
• (h) cybersecurity measures put in place. Source: (a)-(c) and (f)-(h) from engineering; (d) is Module 4's output verbatim; (e) is Module 6's output. Owner: engineering, assembled by the programme owner.

3 — Detailed information about the monitoring, functioning and control of the system. Its capabilities and limitations in performance, including degrees of accuracy for specific persons or groups and the overall expected level of accuracy in relation to the intended purpose; foreseeable unintended outcomes and sources of risk to health, safety and fundamental rights and to discrimination; the human oversight measures needed under Art. 14; specifications on input data, as appropriate. Source: test results plus Module 3's register. Owner: engineering with the model owner.

4 — Description of the appropriateness of the performance metrics for the particular system. Source: a short justification written once. Owner: model owner. Frequently the thinnest element in a real file, and a cheap one to fix.

5 — Detailed description of the risk management system in accordance with Art. 9. Source: Module 3. Owner: programme owner. Reference the register, do not transcribe it.

6 — Description of relevant changes made by the provider to the system through its lifecycle. Source: change log. Owner: engineering. This is the element that quietly makes the file a living document: it has to be appended to, not rewritten.

7 — List of harmonised standards applied in full or in part, and where none were applied, a description of the solutions adopted to meet the Chapter III requirements, including a list of other relevant standards and technical specifications applied. Source: a standards decision. Owner: programme owner.

Then, under Art. 11(1) read with Annex IV, the file sits alongside the Art. 47 declaration of conformity and — where applicable — the Annex VI or Annex VII assessment record from Module 7.

Completeness states beat percentages

The single most useful mechanism for running this is a state per element, not a progress bar. Four states carry all the information you need:

• Complete — evidence exists, is linked, and is current.
• Drafted — written but not reviewed or not yet linked to its evidence.
• Gap, mitigated — the element cannot be fully satisfied, the reason is recorded, and a register row owns it. Element 7's "solutions adopted" clause exists for exactly this situation when no standard applies.
• Gap, unmitigated — the honest red. This is the only state that should ever block a launch decision, and making it explicit is what lets the other three be trusted.

The Technical File template included with this track implements Annex IV as a sheet per element with an evidence location, an owner and one of these states, plus a roll-up that counts unmitigated gaps rather than averaging progress. An average hides exactly the row that matters.

Where files actually fail

Four recurring failures, all avoidable at low cost if named early:

Element 2(a), third-party components. A system built on a pre-trained model or a vendor API must describe how it was used, integrated or modified. Teams that treat a foundation model as infrastructure rather than as a documented component leave this blank — and the same omission usually means nobody has checked whether the modification triggers Art. 25.

Element 2(d), provenance. Written at the end, it becomes a reconstruction. Written as a datasheet when the dataset is assembled, it costs an hour. This is the element Module 4 exists to pre-build.

Element 2(g), dated and signed test reports. The requirement explicitly says dated and signed. Test output in a CI artefact store with a 90-day retention satisfies the testing obligation and fails the documentation one.

Element 3, accuracy for specific groups. "Degrees of accuracy for specific persons or groups of persons" is a subgroup breakdown. An aggregate accuracy figure does not answer it, and the subgroup figures are the ones Module 4's bias examination already produced.

If you are a deployer, demand the equivalent

Art. 11 is a provider obligation. A deployer's lever is Art. 13: providers must design high-risk systems so that deployers can interpret and use the output appropriately, and supply instructions for use containing, among other things, the provider's identity, the characteristics, capabilities and limitations of performance including accuracy and known risks, any predetermined changes, the human oversight measures including technical measures to facilitate interpretation, the computational and hardware resources needed, and the expected lifetime with maintenance measures.

Three practical moves:

1. Get the Art. 13 instructions before signing, not at implementation. They are a conformity artefact, and their absence or thinness is the earliest reliable signal about a vendor.
2. Keep your copy under change control. Art. 26(1) requires you to use the system in accordance with the instructions; you cannot evidence that against a version you cannot produce.
3. Use Art. 25(4) when it applies. Where your modification made you the provider, the displaced provider must cooperate closely, make available the necessary information, and provide the reasonably expected technical access. That is a contractual clause worth having in advance of needing it.

Check yourself

1. We will write the technical file before launch. — Elements 2(c), 2(d) and 6 are records of decisions already made. Written late, they are reconstructions.
2. The file restates the risk register so everything is in one place. — Reference it instead. Two copies of the same fact will disagree, and then neither can be trusted.
3. Our test results live in CI. — Element 2(g) wants dated and signed test reports retained with the file, which Art. 18 keeps for ten years.
4. We report 94% accuracy. — Element 3 asks for accuracy for specific persons or groups. The subgroup figures from Module 4 are what it wants.

Next: Module 6 — Oversight and logging that survive a review →