WARRANTThe obligation, before the system goes on sale.
Read the verb tense. Shall be drawn up before. The documentation does not follow the product to market; it precedes it. Read the maintenance clause. Shall be kept up-to-date. The file is not a launch artefact. It is the system's living technical record, walking alongside every retraining, every fine-tune, every integration change, every dataset refresh.
Article 11(1) continues. The documentation shall be drawn up in such a way as to demonstrate that the high-risk AI system complies with the requirements set out in Section 2 of Chapter III, and to provide national competent authorities and notified bodies with the necessary information in a clear and comprehensive form to assess the compliance of the AI system with those requirements. The audience is dual. Notified bodies during conformity assessment under Article 43. National competent authorities during market surveillance under Articles 74 and following.
The documentation shall contain, at a minimum, the elements set out in Annex IV. The simplification limb was widened by Regulation (EU) 2026/1744, in force 27 July 2026: the second subparagraph of Article 11(1) now reads that SMEs, including start-ups, and SMCs, may provide the elements of the technical documentation specified in Annex IV in a simplified manner, and that the Commission shall establish a simplified form targeted at the needs of SMEs, including start-ups, and SMCs — where the original text confined that form to small and microenterprises. Where such an undertaking opts for the simplified route it must use that form, and notified bodies shall accept it. Simplified, not omitted. The nine-section structure still applies. The depth of evidence per section is what scales.
Article 11(2) handles the integration case. Where a high-risk AI system is related to a product covered by the Union harmonisation legislation listed in Section A of Annex I, a single set of technical documentation shall be drawn up containing all the information set out in paragraph 1 as well as the information required under those legal acts. The MDR file and the Annex IV file converge into one. The same is true for the Machinery Regulation, the Toy Safety Directive successor, and the rest of the New Legislative Framework family.
Article 11(3) is the delegated-act lever. The Commission is empowered to adopt delegated acts in accordance with Article 97 to amend Annex IV where necessary to ensure that, in the light of technical progress, the technical documentation provides all the information necessary to assess the compliance of the system with the requirements set out in Chapter III, Section 2. Annex IV is not frozen. Section content can shift through delegated act over the lifetime of the regulation.
The opening sentence and the nine sections it points at.
Three operative phrases. At least sets a floor, not a ceiling. The following information introduces the nine sections. As applicable to the relevant AI system permits some sections to be marked not applicable, with reasons given. Standalone software systems will not have section 1(f) photographs of internal product layout. Systems that apply no harmonised standards still answer section 7, with the alternative-solutions form.
The nine sections, in order:
§ 1 · A general description of the AI system.
The first section is the cover sheet. It tells the reader what system the file refers to, who places it on the market, what it is meant to do, and how it sits in the wider technical context. The eight sub-points:
§ 2 · A detailed description of the elements and the development process.
Section 2 is the engineering document. It is the longest section in any well-built Annex IV file, and the section a notified body will spend the most time on. Eight sub-points:
§ 3 · Detailed information about monitoring, functioning, control.
Section 3 is narrative, not lettered. Four substantive content categories sit inside the prose. Capabilities and limitations. Foreseeable unintended outcomes and risk sources. Human oversight measures. Input data specifications.
The accuracy clause is sharper than it reads. Degrees of accuracy for specific persons or groups. Aggregate accuracy is not enough. The provider states accuracy by demographic stratification where the system is intended to be used on persons. This pulls in the disaggregated-evaluation literature directly into the regulatory file.
The risk catalogue is qualitative but bounded. Health and safety. Fundamental rights. Discrimination. The provider does not list every conceivable risk. The provider lists what is foreseeable in view of the intended purpose. A credit-scoring system foresees discriminatory pricing. An employment-screening system foresees protected-class disparities. An education-grading system foresees outcome inequity.
§ 4 · Appropriateness of the performance metrics.
One sentence. The shortest section in Annex IV. The implication is heavier than the wording. The provider does not just report metrics. The provider justifies the choice of metrics. Why F1 and not AUC. Why calibration error and not accuracy alone. Why subgroup-stratified disparity and not aggregate.
For systems where harm is asymmetric, this is where the asymmetry shows up in the metric design. A medical screening system reports sensitivity at fixed specificity, not balanced accuracy. A fraud-decisioning system reports false-positive rate by customer segment, not raw precision. The regulator reads section 4 to test whether the provider has thought about the link between the metric and the harm.
§ 5 · Risk management system, in accordance with Article 9.
Section 5 inherits its content shape from Article 9. Article 9 obliges a continuous, iterative process throughout the entire lifecycle, requiring regular and systematic review and update. It runs through identification of known and reasonably foreseeable risks, estimation and evaluation of risks, evaluation of post-market data, and adoption of risk-management measures.
The Annex IV file does not duplicate Article 9; it documents how Article 9 is operationalised for the specific system. The risk register. The methodology for identification. The criteria for risk acceptability. The residual risk statement. The link between risk-management measures and the requirements of Chapter III, Section 2.
For a provider with an ISO/IEC 42001 management system, most of section 5 is produced as a natural artefact of the AI risk-management process clause. For a provider without a management system, section 5 is the section that takes the longest to write from scratch.
§ 6 · Relevant changes through the lifecycle.
Section 6 is the change log of the technical documentation itself. The kept-up-to-date clause in Article 11(1) lands here. As the system evolves, section 6 records what changed, when, and why.
The threshold for inclusion is relevant. Cosmetic UI changes are not relevant. A model checkpoint refresh that shifts subgroup accuracy is relevant. A training-data top-up is relevant. A change to the human oversight pattern is relevant. A change that crosses into Article 3(23) territory is no longer a section 6 entry; it is a substantial modification, triggering a fresh conformity assessment under Article 43(4).
The documentation discipline section 6 enforces is, in effect, a versioned audit trail of design decisions. The Annex IV file is dated. The system is dated. Section 6 is the join.
§ 7 · Standards applied and alternative solutions.
Section 7 is the conformity-route declaration. Article 40 establishes the presumption of conformity for AI systems in compliance with harmonised standards published in the Official Journal. Article 41 reserves the Commission's power to adopt common specifications where the standardisation request fails or is delayed.
The harmonised standards covering the AI Act are being developed by CEN-CENELEC JTC 21 under standardisation request M/593. ISO/IEC 42001:2023 on AI management systems is the leading candidate for citation. ISO/IEC 23894 on AI risk management, ISO/IEC 23053 on machine-learning frameworks, and the forthcoming European hENs are the rest of the field. As of May 2026 not all standardisation deliverables have been published in the OJEU. Section 7 must therefore be ready in two states. The first lists the harmonised standards applied. The second describes the alternative technical solutions where no harmonised standard has been applied yet.
§ 8 · A copy of the EU declaration of conformity.
Article 47(1) requires the provider to draw up a written, machine-readable, physical or electronically signed EU declaration of conformity for each high-risk AI system, and to keep it at the disposal of the national competent authorities for ten years after the system has been placed on the market or put into service. The declaration states that the high-risk AI system in question meets the requirements set out in Chapter III, Section 2.
The declaration's content is specified in Annex V. Identification of the system, identification of the provider, a statement that the declaration is issued under the sole responsibility of the provider, references to the harmonised standards or common specifications applied, and where applicable identification of the notified body. Section 8 of Annex IV is a copy of that declaration, sealed inside the technical documentation.
Article 47(4): By drawing up the EU declaration of conformity, the provider shall assume responsibility for compliance with the requirements set out in Section 2. The same paragraph requires the provider to keep the declaration up to date as appropriate. The declaration is the legal pivot point of the entire file.
§ 9 · Post-market monitoring system and plan.
Article 72(1) obliges providers to establish and document a post-market monitoring system in a manner proportionate to the nature of the AI technologies and the risks of the high-risk AI system. The system actively and systematically collects, documents and analyses relevant data which may be provided by deployers or which may be collected through other sources on the performance of high-risk AI systems throughout their lifetime, and allows the provider to evaluate the continuous compliance of AI systems with the requirements set out in Chapter III, Section 2.
Article 72(3) ties the system to a written plan. The plan is part of the technical documentation referred to in Annex IV. That paragraph was replaced by Regulation (EU) 2026/1744 with effect from 27 July 2026, and the instrument changed with it: instead of an implementing act establishing a template by 2 February 2026, the Commission is now to adopt guidance, including a template, on the post-market monitoring plan by 2 September 2027, taking utmost account of the Board's opinion. Guidance, not an implementing act, and a later date — so a provider drafting section 9 in 2026 is drafting without a template and should not wait for one.
Section 9 is, in effect, the operational counterpart to the static documentation in sections 1 through 8. Sections 1 through 8 describe the system as it is on the day of placing on the market. Section 9 describes how the provider will know whether that description still holds twelve months later, twenty-four months later, sixty months later. Section 9 is where Article 12 logging surfaces back into the file. The post-market monitoring system reads the logs.
Article 11 + Annex IV is the backbone of the regulation.
The Annex IV file is the document where every other obligation in Chapter III lands. Reading the cross-references is the fastest way to see why Annex IV is described internally as the backbone. Each section calls into a substantive article, and each substantive article expects evidence to land in a specific Annex IV section.
| Lands in | Calls out to | What the cross-reference enforces |
|---|---|---|
| § 2(d) | Article 10 | Data and data governance — datasheets, provenance, labelling, cleaning, bias examination. |
| § 1(h), § 2(e) | Article 13 | Transparency to the deployer — instructions for use, output interpretability. |
| § 2(e), § 3 | Article 14 | Human oversight — measures, technical means, override paths. |
| § 2(g), § 2(h), § 3 | Article 15 | Accuracy, robustness, cybersecurity — metrics, test logs, defences. |
| § 5 | Article 9 | Risk management — continuous lifecycle process. |
| § 7 | Articles 40, 41 | Harmonised standards or common specifications, presumption of conformity. |
| § 8 | Article 47, Annex V | EU declaration of conformity. |
| § 9 | Article 72 | Post-market monitoring system and plan. |
| (referenced) | Article 12 | Logging — surfaces into § 9 as the input to post-market monitoring. |
| (referenced) | Article 17 | Quality management system — wraps the lot. |
| (retention) | Article 18 | 10-year availability to national competent authorities. |
| (produces) | Article 43 | Conformity assessment — Annex IV is what the procedure assesses. |
The picture is clear. Article 11 is the obligation to draw up the file. Annex IV is the structure of the file. Articles 9, 10, 12, 13, 14, 15, 17, 47 and 72 are what the file documents. Article 18 is how long it is kept. Article 43 is how it is reviewed. Strip Annex IV out, and the substantive obligations have no shared written form. Strip the substantive obligations out, and Annex IV is empty headings.
How Annex IV sections map to Warrant evidence fields.
Warrant produces evidence packages from AI agent execution traces — each package is a record mapped to a specific EU AI Act obligation, independently verifiable without contacting Warrant. Some Annex IV sections have a field in that package and most do not. Each section below names the field where one exists and says so where none does.
Read the FIELD lines literally. The evidence schema's root properties are exactly classification, actions, authorizations, obligations, coverage_by_regime, deferred_regimes, risk_tier, refusal_reason and trace_metadata, and additionalProperties is false. There is no package root, no system root and no eval_runs root, so nothing beneath them can appear in a conforming record. Where a line says NO FIELD, no field exists — not one under a different name.
The gap follows from Annex IV's shape rather than from an omission in the schema. Annex IV documents a system across its lifetime; warrant-v1 records one decision at one moment. Sections 1(a), 2(g), 5 and 6 are system-level documentation the provider draws up and keeps, and no per-decision record produces them. What the package contributes is section 3 in part and the section 9 monitoring stream. It does not stand in for the file.
The harmonised-standards bridge · ISO/IEC 42001.
Section 7 of Annex IV asks for a list of harmonised standards applied. As of May 2026 the harmonised-standards landscape under standardisation request M/593 is in flight. The published Type-A horizontal standard expected to anchor the framework is ISO/IEC 42001:2023, the AI management system standard.
An ISO/IEC 42001-aligned management system produces, as natural artefacts, large fractions of Annex IV sections 5 (risk management), 6 (lifecycle change), 7 (standards applied), and 9 (post-market monitoring). The 42001 clauses on context establishment, leadership and commitment, risk and impact assessment, and operational planning and control align cleanly with the Article 9 risk-management content that section 5 expects.
For providers without a management system in 2026, the cleanest path to a defensible Annex IV file before the application date is to scope a 42001-aligned management system around the high-risk AI system, document it, and back-fill the Annex IV sections from the management-system artefacts. The sibling post on ISO/IEC 42001 walks through this in detail.
Questions a compliance officer asks first.
Read the source directly.
- Regulation (EU) 2024/1689 · EUR-Lex CELEX:32024R1689
- Article 11 technical documentation · annotated text
- Annex IV · annotated text
- Article 9 · risk management system
- Article 47 · EU declaration of conformity
- Article 72 · post-market monitoring
- Per-obligation Warrant evidence field mapping
Authored by Warrant Compliance, the regulatory-analysis function at Warrant. [email protected]. Editorial commentary on regulatory text. Not legal advice. The verbatim quotations of Annex IV and of Article 11 reflect the official English-language text of Regulation (EU) 2024/1689 as published in the Official Journal of the European Union on 12 July 2024, save that the second subparagraph of Article 11(1) and Article 72(3) are given as replaced by Regulation (EU) 2026/1744, published in the Official Journal on 24 July 2026 and in force from 27 July 2026. Verified against the consolidating instruments on 6 August 2026.