Annex IV Technical Documentation Template

Article 11 of the EU AI Act requires providers of high-risk AI systems to draw up technical documentation. They must do this before the system is placed on the market or put into service. The documentation must stay up to date. Providers must make it available to competent authorities on request.

Annex IV lists the information the documentation must contain at least, as applicable to the system. Below, each of its nine points is summarised with guidance. The full template is the DOCX above.

Jump to the worked example

Annex IV or Annex 4?

They are the same annex. The official text of Regulation (EU) 2024/1689 writes it with a Roman numeral, "Annex IV"; "Annex 4" is the same annex written with an Arabic numeral. Its title is "Technical documentation referred to in Article 11(1)". Other EU acts also have an Annex IV, on a different subject. In the Cyber Resilience Act, Regulation (EU) 2024/2847, Annex IV lists critical products with digital elements. Technical documentation for general-purpose AI models sits in Annexes XI and XII instead.

Section 1: General Description of the AI System

This section establishes the identity and scope of the system. Include:

• Intended purpose — What the system does, who it's for, and the specific context of use
• Provider name — The name of the provider. Annex IV asks only for the name. The contact address goes on the system or its packaging (Article 16(b)) and in the EU declaration of conformity (Annex V, point 2)
• System version — Current version and its relationship to previous versions
• Hardware and software interactions — How the system interacts with other hardware, software, or AI systems not part of the system itself
• Software and firmware versions — All relevant version numbers and update requirements
• Distribution forms — How the system is delivered (software package, embedded in hardware, API, download, etc.)
• Hardware requirements — The hardware on which the system is intended to run
• User interface — Basic description of the interface provided to the deployer
• Instructions for use — Instructions for use for the deployer, and a basic description of the user interface, where applicable

Section 2: Detailed Description of System Elements & Development Process

The most substantial section. Document:

• Development methods — Steps taken, including use of pre-trained systems or third-party tools and how they were integrated or modified
• Design specifications — General logic, key design choices with rationale, assumptions made, classification choices, optimisation targets, and expected output quality
• System architecture — How software components build on each other, integration into overall processing, and computational resources used
• Data requirements — Training methodologies, dataset descriptions, provenance, scope, characteristics, acquisition methods, labelling procedures, and data cleaning methods
• Human oversight assessment — Measures needed per Article 14 and technical measures for output interpretation
• Pre-determined changes — If applicable, describe any planned changes to the system and how continuous compliance will be maintained
• Validation and testing — Procedures, validation and testing data, and metrics, including for potentially discriminatory impacts. Test logs and all test reports, dated and signed by the responsible persons
• Cybersecurity measures — The cybersecurity measures put in place

Section 3: Monitoring, Functioning & Control

Detail the system's operational characteristics:

• Capabilities and limitations in performance
• Degrees of accuracy for specific persons or groups the system is intended for, and overall expected accuracy
• Foreseeable unintended outcomes and sources of risk to health, safety, fundamental rights, and discrimination
• Human oversight measures per Article 14
• Technical measures enabling deployers to interpret output
• Input data specifications where appropriate

Section 4: Performance Metrics Appropriateness

Describe why the chosen performance metrics are appropriate for the specific AI system. This should explain the rationale for selecting certain metrics over alternatives and how they meaningfully capture the system's performance in its intended context.

Section 5: Risk Management System

Provide a detailed description of the risk management system established per Article 9. This is a continuous, iterative process that runs throughout the entire lifecycle and must include:

• Identification and analysis of known and reasonably foreseeable risks
• Estimation and evaluation of risks from intended use and reasonably foreseeable misuse
• Evaluation of risks from analysis of data gathered through post-market monitoring
• Adoption of appropriate risk management measures

Section 6: Lifecycle Changes

Describe the relevant changes the provider makes to the system through its lifecycle. This gives authorities a traceable history of how the system changed.

Section 7: Standards & Technical Specifications

List all harmonised standards applied, either in full or in part, with references to their publication in the Official Journal of the EU. Where no harmonised standards were applied:

• Provide a detailed description of the solutions adopted to meet the requirements of Chapter III, Section 2
• List any other relevant standards and technical specifications applied

Section 8: EU Declaration of Conformity

Include a copy of the EU declaration of conformity referred to in Article 47. The provider keeps the declaration up to date as appropriate. It stays at the disposal of national competent authorities for 10 years after the system is placed on the market or put into service.

Section 9: Post-Market Performance Evaluation

Describe the system in place to evaluate the AI system's performance in the post-market phase, as required by Article 72. This must include:

• The post-market monitoring plan referred to in Article 72(3), on which the monitoring system is based
• How the monitoring system collects, documents and analyses data on the system's performance throughout its lifetime (Article 72(2))

Worked example: a CV-screening system (Annex III, point 4(a))

This example is fictional and illustrative. The system, the provider and every figure are invented.

Annex III, point 4(a), covers "AI systems intended to be used for the recruitment or selection of natural persons, in particular to place targeted job advertisements, to analyse and filter job applications, and to evaluate candidates". Our fictional system parses job applications and shows recruiters a ranked shortlist. Recruiters make every decision. The provider treats the system as high-risk and documents it against Annex IV.

Point 2(b): design specifications

the design specifications of the system, namely the general logic of the AI system and of the algorithms; the key design choices including the rationale and assumptions made, including with regard to persons or groups of persons in respect of who, the system is intended to be used; the main classification choices; what the system is designed to optimise for, and the relevance of the different parameters; the description of the expected output and output quality of the system; the decisions about any possible trade-off made regarding the technical solutions adopted to comply with the requirements set out in Chapter III, Section 2;

What the fictional provider writes:

• General logic — Version 2.1 parses each CV into skills, qualifications, years of experience and languages. A ranking model scores each application against the criteria the recruiter sets for the vacancy.
• Design choices and assumptions — The system is intended for applicants to office roles in the EU. Name, photo, date of birth, address and nationality are removed before scoring. We assume CVs are in English, Italian or German.
• Main classification choices — Each application gets a score from 0 to 100 and one of three bands: strong match, possible match, or review manually. The system has no reject class.
• What it optimises for — The model optimises for agreement with past recruiter shortlists. Required qualifications carry the most weight. Years of experience count up to ten, to limit age effects.
• Expected output and trade-offs — The output is a ranked shortlist with the three factors behind each score. We chose a simpler, explainable model over a slightly more accurate one, so recruiters can check each ranking (Articles 13 and 14).

Point 2(d): data requirements

where relevant, the data requirements in terms of datasheets describing the training methodologies and techniques and the training data sets used, including a general description of these data sets, information about their provenance, scope and main characteristics; how the data was obtained and selected; labelling procedures (e.g. for supervised learning), data cleaning methodologies (e.g. outliers detection);

What the fictional provider writes:

• Training data sets — 120,000 applications for 1,400 office vacancies, from 2021 to 2024, in Italy, Germany and Ireland. Each record pairs a parsed CV with the recruiter's shortlist decision.
• Provenance and selection — Three employers supplied the data under written agreements. We excluded vacancies with fewer than 20 applicants and applications no recruiter reviewed.
• Labelling procedure — The label is the recruiter's original shortlist decision. Two trained reviewers re-checked a sample of 5,000 records. A third reviewer settled disagreements.
• Data cleaning — We removed duplicate applications and unreadable files. Implausible values, such as 60 years of experience, were flagged and checked by hand. Career-gap fields were dropped as a possible gender proxy.
• Link to data governance — The examination for possible biases under Article 10(2)(f) is kept in the data governance file. Subgroup accuracy results go under points 2(g) and 3.

The rest of the file builds on these entries. Human oversight goes under point 2(e) and testing under point 2(g). The risk management system goes under point 5, changes under point 6.

For high-risk systems under Article 6(2) and Annex III, these requirements apply from 2 December 2027 (Article 113, point (c)(i)). For Annex III points 2 to 8, the provider follows internal control under Annex VI (Article 43(2)).

This example covers only points 2(b) and 2(d). It is not a complete Annex IV file and does not show that any system complies. Information, not legal advice.

Annex IV generator

LandingRed drafts Annex IV technical documentation from the AI system record you already keep in its inventory. It also pulls in records linked to that system: risk assessment, data governance, human oversight, cybersecurity, post-market monitoring plan and EU declaration of conformity.

Where your records lack a fact, the generator is instructed to leave a visible placeholder for you to fill in. Check every draft before relying on it. Every AI-drafted section is marked as a draft and records which model produced it and when.

An AI draft counts towards completeness only after a person has reviewed and edited it. On every plan, you can write each section yourself in the built-in editor. Each approval saves a fixed, hash-sealed snapshot.

See how documentation fits the rest of the workflow on the EU AI Act compliance page.

The generator produces a draft for your review. The provider remains responsible for the content. It is not an official form or template.

Frequently asked questions

What is Annex IV of the EU AI Act?

Annex IV lists the minimum content of the technical documentation for a high-risk AI system. The provider draws it up before the system is placed on the market or put into service, and keeps it up to date (Article 11(1)). Annex IV has nine points, from a general description of the system to the post-market monitoring plan.

Who has to produce Annex IV technical documentation?

The provider of the high-risk AI system draws it up (Article 11(1)). Importers verify that the provider has drawn it up in accordance with Article 11 and Annex IV (Article 23(1)(b)). For Annex III points 2 to 8, providers follow internal control under Annex VI, without a notified body (Article 43(2)). A notified body is involved under the Annex VII procedure (Article 43(1)). One may also be involved through the sectoral procedure for products covered by Annex I, Section A (Article 43(3)).

When does the technical documentation have to be ready?

Before the high-risk AI system is placed on the market or put into service. Providers must then keep it up to date throughout the system's lifecycle. Annex III high-risk obligations apply from 2 December 2027. So providers should treat documentation as a design-time activity, not a launch-week scramble.

Is there a simplified version for SMEs, start-ups and small mid-caps?

Yes. Under Article 11(1), SMEs, including start-ups, and small mid-cap enterprises (SMCs) may provide the Annex IV elements in a simplified manner. The Commission must establish a simplified technical documentation form for them. A company that opts for the simplified manner must use that form, and notified bodies must accept it. Our free DOCX is not that form.

Does the EU AI Act prescribe a format for Annex IV documentation?

The Act prescribes content, not a general format. One exception: SMEs, start-ups and SMCs that opt for the simplified manner must use the Commission's form (Article 11(1)). Our free DOCX follows the nine Annex IV points. LandingRed can also draft the documentation from your AI system inventory, for you to review and edit.

Related resources

• Annex III high-risk classification guide — check whether your system is high-risk
• Model documentation and data lineage: what Annex IV point 2(d) asks for
• Free AI Act risk self-assessment — get a shareable readiness report