Module 4 — Technical Documentation (Art. 11 and Annex IV)

Module 4 of the AI Act Provider certification: the Annex IV file element by element, when it must exist, how long it is kept, and the simplified form available to small providers.

The Annex IV file is the evidence base for everything else. The conformity assessment is carried out against it, the declaration of conformity asserts what it demonstrates, and a market surveillance authority reads it before it reads anything you wrote about yourself.

It is also the artefact that reveals whether the rest of Chapter III was done. A risk management system that exists produces a section here; one that does not, cannot.

What Art. 11 requires

Technical documentation shall be drawn up before the system is placed on the market or put into service and kept up to date. It shall be drawn up in such a way as to demonstrate that the high-risk system complies with the Chapter III Section 2 requirements, and to provide national competent authorities and notified bodies with the information necessary in a clear and comprehensive form to assess compliance.

Two consequences.

"Before" is a hard gate. You cannot place a system on the market and document it afterwards. The obligation is dated to market placement, and so is the declaration that depends on it.

"Clear and comprehensive" is a quality standard, not a volume standard. A file that is technically complete but unreadable does not provide the information necessary in a clear form. Reviewers are not obliged to reconstruct your argument from artefacts.

Where the system is related to a product covered by the Annex I legislation, Art. 11(2) requires a single set of technical documentation containing all the information required under both regimes. Two parallel files is a finding, not a strategy.

The Annex IV elements

1. A general description of the AI system, including its intended purpose, the name of the provider, the version, how it interacts with hardware or software that is not part of the system itself, the versions of relevant software or firmware, the forms in which it is placed on the market, the description of hardware on which it is intended to run, photographs or illustrations of external features where relevant, and the basic description of the user interface provided to the deployer.

2. A detailed description of the elements of the system and of the process for its development, including the methods and steps performed, any pre-trained systems or tools provided by third parties and how they were used, integrated or modified; the design specifications, the general logic, the key design choices including rationale and assumptions; the classification choices; what the system is designed to optimise for and the relevance of the different parameters; the description of the expected output; the risk management decisions; the validation and testing procedures and the test logs; and the cybersecurity measures.

3. Detailed information about the monitoring, functioning and control of the system, in particular its capabilities and limitations in performance, including the degrees of accuracy for specific persons or groups on which it is intended to be used and the overall expected level of accuracy in relation to its intended purpose; the foreseeable unintended outcomes and sources of risk to health and safety, fundamental rights and discrimination; the human oversight measures needed under Art. 14, including the technical measures put in place to facilitate the interpretation of outputs by deployers; and specifications on input data as appropriate.

4. A description of the appropriateness of the performance metrics for the specific system.

5. A detailed description of the risk management system in accordance with Art. 9.

6. A description of relevant changes made by the provider to the system through its lifecycle.

7. A list of the harmonised standards applied in full or in part, and where none were applied, a description of the solutions adopted to meet the Chapter III Section 2 requirements, including a list of other relevant standards and technical specifications applied.

8. A copy of the EU declaration of conformity.

9. A detailed description of the system in place to evaluate the performance of the system in the post-market phase in accordance with Art. 72, including the post-market monitoring plan.

The elements that are hardest to produce late

Three of the nine cannot realistically be reconstructed after the fact.

Element 2's "key design choices including rationale and assumptions". Rationale is a contemporaneous artefact. Six months later a team can state what it did but only reconstruct why, and a reconstructed rationale reads as one.

Element 3's "degrees of accuracy for specific persons or groups on which the system is intended to be used". Note the phrasing: not overall accuracy, but accuracy for the groups the system will be used on. That is a disaggregated evaluation, and it requires having held out data that supports the disaggregation. If you did not plan for it, you cannot compute it afterwards.

Element 6's "relevant changes made through its lifecycle". A change log is either kept or it is not.

The rest can be written up. These three have to be produced as you go, which is the practical argument for treating Annex IV as a living file that development contributes to rather than a document that compliance writes at the end.

Standards, and what "none applied" means

Element 7 asks which harmonised standards you applied. Where a harmonised standard exists and is applied, Art. 40 gives a presumption of conformity with the requirements it covers — which is the cheapest compliance route available.

Where none were applied — which, for much of the AI Act's requirement set, remains the position while standardisation work continues — you must describe the solutions adopted to meet the requirements. The unavailability of standards was one of the reasons the Digital Omnibus deferred the Chapter III dates; it is not a reason for the file to be silent. A description of your own solution, mapped requirement by requirement, is what the element asks for.

Keeping it, and keeping it current

Art. 18 requires the provider to keep at the disposal of national competent authorities, for ten years after the system is placed on the market or put into service:

• the technical documentation;
• the documentation of the quality management system;
• documentation concerning changes approved by notified bodies, where applicable;
• decisions and other documents issued by notified bodies, where applicable;
• the EU declaration of conformity.

Ten years is longer than most product lifecycles and considerably longer than most document retention defaults. It is also longer than many vendor relationships, which is a reason to hold the file yourself rather than rely on a supplier's systems.

"Kept up to date" in Art. 11 does real work alongside element 6: a file describing version 1.0 of a system that is now on version 4.2 does not demonstrate that the system on the market complies.

Check yourself

1. We will assemble the Annex IV file for the audit. — Art. 11 requires it drawn up before the system is placed on the market, and the Art. 43 conformity assessment is carried out against it.
2. Element 3 asks for accuracy — we report a single overall figure. — It asks for the degrees of accuracy for specific persons or groups on which the system is intended to be used, which requires disaggregated evaluation planned in advance.
3. No harmonised standards exist for our requirement. — Then element 7 requires a description of the solutions you adopted, mapped to the requirements.
4. How long do we keep it? — Ten years after market placement or putting into service, under Art. 18, alongside the QMS documentation and the declaration of conformity.

Previous: Module 3 — Data and data governance (Art. 10) Next: Module 5 — Logging, instructions, oversight by design →