EU AI Act Annex IV technical documentation for a high-risk AI system

Structure (11 sections)

1. 1. 0. High-risk classification and documentation scope (front matter)

   Annex IV has no such item, but the first thing any reviewer establishes is why you consider this system high-risk and by which route. State whether the system falls under Art. 6(1) (a safety component of, or itself, a product covered by the Union harmonisation legislation in Annex I and subject to third-party conformity assessment) or Art. 6(2) (an Annex III use case); and, if it is an Annex III use case for which you claim the Art. 6(3) exception because it does not pose a significant risk of harm to health, safety or fundamental rights, record the basis for that assessment and note that Art. 6(4) requires the assessment to be registered before placing on the market or putting into service. Also state the application date: following the AI Omnibus deferral, the high-risk rules apply from 2 December 2027 on the Annex III route and from 2 August 2028 on the Annex I embedded route, so the documentation schedule should count back from those dates rather than from the general application date of 2 August 2026. Finally declare the system name, version range and form of supply (SDK, API, embedded firmware) the file covers; every later Annex IV item is scoped to it.

   Evidence to attach

   • · Classification determination record showing the Art. 6(1) or 6(2) route and its basis
   • · Where the Art. 6(3) exception is claimed: the assessment and the Art. 6(4) registration record
   • · Statement of the system versions this file covers
   • · Compliance schedule counted back from the applicable date

   Common pitfalls

   • · Claiming "not high-risk" without performing the Art. 6(3) assessment or the Art. 6(4) registration — forfeiting the exception while also not meeting the high-risk duties;
   • · Mixing up the Annex I and Annex III application dates and building a schedule eight months out;
   • · Omitting the version range, so every model update reopens the question of whether the file is still valid.

2. 2. 1. General description of the AI system (Annex IV item 1)

   Work through the eight sub-items of Annex IV item 1: (a) intended purpose, provider name and system version and its relation to previous versions; (b) how the system interacts, or can be used to interact, with hardware or software — including other AI systems — that is not part of the system itself; (c) the versions of relevant software or firmware and any requirements for version updates; (d) every form in which the system is placed on the market or put into service (software packages embedded in hardware, downloads, APIs); (e) the hardware the system is intended to run on; (f) where the system is a component of a product, photographs or illustrations showing external features, marking and internal layout; (g) a basic description of the user interface provided to the deployer; (h) instructions for use for the deployer (see also the Art. 13 section below). "Intended purpose" is the most consequential sentence in the file: it bounds risk management, data governance, accuracy metrics and post-market monitoring, and the vaguer it is, the less any later item can converge. State reasonably foreseeable misuse explicitly as well, since Art. 9 risk management must cover it.

   Evidence to attach

   • · Intended-purpose statement and a list of reasonably foreseeable misuse
   • · Version lineage with a description of differences from previous versions
   • · Interface and integration documentation (API specs, SDK docs, hardware interfaces)
   • · List of supply forms and the distribution channel for each
   • · Photographs or illustrations of external features and internal layout where the system is a product component
   • · Screenshots of the deployer-facing user interface

   Common pitfalls

   • · An intended purpose written as marketing copy ("an intelligent assistant that boosts enterprise efficiency"), against which out-of-scope use cannot be judged;
   • · Omitting supply forms under (d), especially where the same model ships both as an API and as an on-premise deployment;
   • · Leaving reasonably foreseeable misuse blank or "none", which leaves the Art. 9 risk management open-ended;
   • · Version lineage giving only version numbers and no substantive delta, so a notified body cannot judge whether an Art. 43(4) substantial modification has occurred.

3. 3. 2. Detailed description of the elements and development process (Annex IV item 2)

   The longest Annex IV item, with eight sub-items: (a) the methods and steps used to develop the system, including any recourse to pre-trained systems or third-party tools and how they were used, integrated or modified; (b) design specifications — the general logic of the system and its algorithms, the key design choices with their rationale and assumptions including about the persons or groups the system is intended for, the main classification choices, what the system optimises for and the relevance of the different parameters, the expected output and output quality, and the trade-off decisions taken on technical solutions to meet Chapter III Section 2; (c) the system architecture, explaining how software components build on or feed into each other and integrate into the overall processing, plus the computational resources used to develop, train, test and validate; (d) data requirements as datasheets describing training methodologies and techniques and the training datasets used, including a general description, provenance, scope and main characteristics, how data was obtained and selected, labelling procedures (e.g. for supervised learning) and data-cleaning methodologies (e.g. outlier detection); (e) an assessment of the human oversight measures needed under Art. 14, including the technical measures needed to facilitate deployers’ interpretation of outputs under Art. 13(3)(d); (f) where applicable, a detailed description of pre-determined changes and the technical solutions adopted to ensure continued conformity with Chapter III Section 2; (g) the validation and testing procedures used, including the validation and testing data and its main characteristics, metrics for accuracy, robustness and the other Chapter III Section 2 requirements as well as potentially discriminatory impacts, and dated test logs and test reports signed by the responsible persons, including for the pre-determined changes under (f); (h) the cybersecurity measures in place. Sub-items (d) and (g) may point to a standalone data card and evaluation report, but give the index and a summary here — an internal link alone is not enough.

   Evidence to attach

   • · Development methodology, and a record of any third-party pre-trained models or tools used and how they were modified
   • · Design specification covering key design choices, rationale, assumptions and trade-off decisions
   • · Architecture diagram and an inventory of compute used at each of development, training, validation and testing
   • · Data card / datasheet answering Annex IV item 2(d) (see the data card template)
   • · Labelling rules, labeller training and quality-control records
   • · Validation and testing reports, including subgroup fairness metrics and dated, signed test logs
   • · Description of pre-determined changes and their scope under Art. 43(4)
   • · Cybersecurity measures and the evidence they were tested

   Common pitfalls

   • · Test logs under (g) with no date and no signature, where the text expressly requires them "dated and signed by the responsible persons";
   • · "Potentially discriminatory impacts" left blank or reported only in aggregate, with no subgroup results or sample sizes;
   • · A third-party base model with no account of how it was integrated or modified, leaving the responsibility boundary undecidable;
   • · Pre-determined changes under (f) drafted so broadly ("the model will be continuously optimised") that the Art. 43(4) protection is effectively forfeited and any update may count as a substantial modification;
   • · Compute resources described only as "a GPU cluster", which cannot support verification of item 2(c).

4. 4. 3. Monitoring, functioning and control (Annex IV item 3)

   Annex IV item 3 requires: the system’s 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 the intended purpose; the foreseeable unintended outcomes and sources of risk to health and safety, fundamental rights and discrimination in view of the intended purpose; the human oversight measures needed under Art. 14, including the technical measures put in place to facilitate deployers’ interpretation of outputs; and specifications on input data as appropriate. The heart of this item is writing the limitations honestly: name the input distributions, populations and scenarios where performance degrades, and carry those same limitations into the Art. 13 instructions for use so deployers can calibrate their oversight. Make input specifications verifiable: language, resolution, sampling rate, data recency, required pre-processing, and what the system does with out-of-specification input (refuse, degrade gracefully, or emit output with no warning).

   Evidence to attach

   • · Capability and limitation statement, broken down by population, scenario and input distribution
   • · Subgroup accuracy report with confidence intervals
   • · Register of foreseeable unintended outcomes and an analysis of risk sources
   • · Input data specification and the behaviour on out-of-specification input
   • · Description of the technical measures that make outputs interpretable to deployers under Art. 13(3)(d)

   Common pitfalls

   • · A single overall accuracy figure, with the "degrees of accuracy for specific persons or groups" required by the text entirely absent;
   • · A limitations section that says "performs well under normal conditions of use" — effectively blank;
   • · Limitations acknowledged in the technical file but absent from the instructions for use, so deployers cannot set effective oversight;
   • · Silent output on out-of-specification input, undisclosed in the file.

5. 5. 4. Appropriateness of the performance metrics (Annex IV item 4)

   Annex IV item 4 is a single line — "a description of the appropriateness of the performance metrics for the specific AI system" — and is therefore the item most often treated as a formality. The question to answer is why these particular metrics measure performance under the intended purpose. Tie the metrics to the failure modes that matter: where a false accept costs far more than a false reject (security screening, for example), accuracy alone is inappropriate and recall or miss rate with a justified threshold is required; where classes are heavily imbalanced, explain why F1 or AUC-PR beats accuracy; where the output is generative text, explain how the factuality, harmfulness and refusal-rate metrics chosen map to concrete harms. Describe the evaluation set too: provenance, size, how it is isolated from training data, whether it covers the vulnerable groups named in item 3, and its own limitations. Once metrics and thresholds are written here they become the baseline for post-market monitoring (Art. 72) and serious-incident determination (Art. 73), so do not commit to metrics you cannot keep measuring.

   Evidence to attach

   • · Justification table mapping each metric to a failure mode and the harm it would cause
   • · Evaluation-set description (provenance, size, evidence of isolation from training data, subgroup coverage)
   • · Rationale for the thresholds chosen and a sensitivity analysis
   • · The plan for continuing to measure these metrics, wired into post-market monitoring

   Common pitfalls

   • · Writing only "industry-standard metrics are used", without explaining why they fit this intended purpose;
   • · Leakage between evaluation and training sets (same-source sampling, incomplete deduplication), which voids every metric;
   • · Choosing flattering but harm-irrelevant metrics (reporting only BLEU for a generation task), which reviewers challenge immediately;
   • · Committing to metrics that cannot be collected in production, so post-market monitoring breaks at once.

6. 6. 5. Detailed description of the risk management system (Annex IV item 5, Art. 9)

   Annex IV item 5 requires a detailed description of the risk management system under Art. 9, which is a continuous, iterative process running across the lifecycle and subject to regular systematic review — not a one-off document. Set out: the method for identifying and analysing risks, covering both the known and reasonably foreseeable risks when the system is used for its intended purpose and those arising under reasonably foreseeable misuse; risk estimation and evaluation, including new risks fed back from post-market monitoring; the risk-management measures adopted and the priority logic behind them — eliminate or reduce through design and development first, then adequate mitigation and control measures, then information and training for deployers; how residual risk is judged and communicated; how testing confirms the measures work, including testing under real-world conditions; and specific consideration of vulnerable groups such as minors. Cross-reference each risk entry to the specific design choices, limitations and metrics in items 2, 3 and 4, so a reviewer can follow one risk to one measure to one test.

   Evidence to attach

   • · Risk register (risk, measure, verification, residual risk, review date)
   • · The risk-management procedure and where it sits within the quality management system
   • · Effectiveness test reports, including testing under real-world conditions
   • · Residual-risk communication materials, i.e. the parts carried into the instructions for use
   • · Records of periodic review and evidence that post-market monitoring data feeds back in

   Common pitfalls

   • · Treating risk management as a one-off document with no review records, contrary to the continuous, iterative nature of Art. 9;
   • · A risk list covering safety risks only, with nothing on fundamental rights or discrimination;
   • · Inverted priority: risks that could be designed out are instead "flagged in the instructions for use";
   • · Residual risk acknowledged in the technical file but never carried into the instructions the deployer actually receives.

7. 7. 6. Relevant changes made through the lifecycle (Annex IV item 6)

   Annex IV item 6 requires a description of the relevant changes made by the provider through the lifecycle. In practice this is a change register that must answer three questions: what changed, when, and whether it amounts to a substantial modification under Art. 43(4) (which requires a fresh conformity assessment). Useful fields: change id; date; type (model weights, training data, inference parameters, thresholds, pre/post-processing, UI, deployment environment); reason (defect fix, performance tuning, regulatory requirement, post-market finding); whether it falls inside the pre-determined changes declared under item 2(f); impact-assessment conclusion; whether validation testing was repeated; and the approver. Note the express rule: for systems that continue to learn after being placed on the market, changes pre-determined by the provider at the initial conformity assessment and contained in the information under Annex IV item 2(f) do not constitute a substantial modification — which is precisely the commercial value of drafting item 2(f) well.

   Evidence to attach

   • · Change register with the fields above, including approver and date
   • · Substantial-modification determinations assessed against Art. 43(4)
   • · Regression test reports for each change
   • · Mapping of each change against the pre-determined scope declared under item 2(f)
   • · Changes that triggered re-assessment, with the notified-body correspondence

   Common pitfalls

   • · Substituting Git history for a change register, so substantial-modification determinations and approvals are invisible;
   • · Model-weight updates left out, with only code changes recorded;
   • · Every change ruled "not substantial" with no declared item 2(f) scope to support it;
   • · No re-validation after a change, leaving the metrics in the file inconsistent with the running system.

8. 8. 7. Harmonised standards applied, or alternative solutions (Annex IV item 7)

   Annex IV item 7 requires a list of the harmonised standards applied in full or in part whose references have been published in the Official Journal; where none have been applied, a detailed description of the solutions adopted to meet the Chapter III Section 2 requirements, together with a list of the other relevant standards and technical specifications applied. In practice the harmonised standards under this Regulation are not all published yet, so most companies take the "no harmonised standards + detailed description of alternatives" route. Write that route as a clause-by-clause mapping table: each requirement in Arts. 9 to 15 → the solution adopted in this system → the other standards referenced (for example ISO/IEC 42001 on AI management systems, ISO/IEC 23894 on AI risk management, ISO/IEC 42005 on AI system impact assessment, ISO/IEC 27001 on information security management, the NIST AI RMF) → where the evidence sits. State plainly that citing those standards creates no presumption of conformity — only harmonised standards published in the Official Journal do that — and that they serve only to argue the adequacy of the solution.

   Evidence to attach

   • · Clause-by-clause mapping of Arts. 9–15 requirements to the solutions adopted
   • · Version numbers and scope of each standard referenced
   • · Where harmonised standards exist: whether applied in full or in part, and any deviations
   • · Third-party certificates (ISO/IEC 42001, ISO/IEC 27001) with their audit scope

   Common pitfalls

   • · Treating an ISO/IEC 42001 certificate as a presumption of conformity and claiming "AI Act compliant" — the certification scope is not the same as the Regulation’s requirements;
   • · A mapping table naming standards but not clauses or evidence locations, so nothing can be verified;
   • · A certificate whose scope statement does not cover the system described in this file;
   • · No explanation of why a published harmonised standard was not applied.

9. 9. 8. Copy of the EU declaration of conformity (Annex IV item 8, Art. 47 and Annex V)

   Annex IV item 8 requires a copy of the EU declaration of conformity referred to in Art. 47. The content of the declaration itself is fixed by Annex V: the system name and type and any additional unambiguous reference allowing identification and traceability; the name and address of the provider or, where applicable, its authorised representative; a statement that the declaration is issued under the sole responsibility of the provider; a statement that the system conforms with this Regulation and, if applicable, with any other Union law requiring an EU declaration of conformity; where the system processes personal data, a statement that it complies with Regulations (EU) 2016/679 and (EU) 2018/1725 and Directive (EU) 2016/680; references to any relevant harmonised standards or other common specification relied on; where applicable, the name and identification number of the notified body, a description of the conformity assessment procedure performed and the identification of the certificate issued; and the place and date of issue, the name and function of the signatory, an indication of for or on whose behalf they signed, and the signature. Item 5 is not boilerplate: it requires the company to be able to demonstrate GDPR compliance at the moment the declaration is issued, so the DPIA and the TIA must both be in place alongside this file.

   Evidence to attach

   • · The signed EU declaration of conformity, checked item by item against Annex V
   • · Signing authority for the signatory, showing they may sign for the provider
   • · Notified body certificate where the Annex VII route is used
   • · Index to the DPIA, TIA and transfer mechanism documents supporting the personal-data statement in item 5
   • · Record of where and how the CE marking is affixed (Art. 48)

   Common pitfalls

   • · A personal-data compliance statement in the declaration that the company cannot back with a DPIA and transfer documentation;
   • · A signatory with no signing authority, or a signatory who has left and a declaration never refreshed;
   • · The harmonised-standards field left blank while Annex IV item 7 also gives no alternative solution;
   • · No fresh declaration after a version update, so the declared version differs from the one on sale.

10. 10. 9. Post-market performance evaluation system and monitoring plan (Annex IV item 9, Art. 72)

    Annex IV item 9 requires a detailed description of the system in place to evaluate performance in the post-market phase under Art. 72, including the post-market monitoring plan referred to in Art. 72(3). Note that Art. 72(3) was replaced in full by Art. 1(30) of Regulation (EU) 2026/1744 (the AI Omnibus): the plan is still part of the technical documentation, but the former empowerment for the Commission to adopt an implementing act laying down a template and element list (originally due by 2 February 2026) is gone, replaced by "the Commission, taking utmost account of the opinion of the Board, shall adopt guidance, including a template, on the post-market monitoring plan by 2 September 2027". Do not schedule around an implementing act that no longer exists; until that guidance issues, set out for yourself: the sources and collection methods for monitoring data (deployer feedback, logs, complaints, incidents, sampled review); monitoring metrics and thresholds, consistent with item 4; the analysis cadence and who owns it; the trigger and response path when performance degrades or a new risk appears; how findings feed back into the Art. 9 risk management system; and the criteria that escalate a finding into a serious-incident report under Art. 73. Also state how the Art. 12 logging arrangements support monitoring: retention period, who may access the logs, and the split of responsibilities between deployer and provider.

    Evidence to attach

    • · The post-market monitoring plan (sources, metrics, thresholds, cadence, owners)
    • · Technical description of how monitoring data is collected, plus the log-retention configuration
    • · The last several monitoring reports and the trend analysis
    • · Records of findings feeding back into risk management and the change register
    • · Serious-incident determination and escalation criteria, tied to Art. 73
    • · The data-sharing and feedback clauses agreed with deployers

    Common pitfalls

    • · A monitoring plan that has never produced a single monitoring report;
    • · Monitoring metrics that differ from those in Annex IV item 4, so trends cannot be compared to the pre-market baseline;
    • · Log retention shorter than the monitoring cycle, making after-the-fact review impossible;
    • · No feedback arrangement with deployers, so the provider receives no operational data at all;
    • · Findings that never feed back into Art. 9 risk management or the item 6 change register, breaking the loop.

11. 11. 10. Retention, language and access arrangements

    The technical file is not a write-once deliverable; it must be producible on demand. Record: who holds it and where (what the provider holds, what the EU authorised representative holds), the retention period and when it starts, version and access controls, and the process and turnaround for responding when a market surveillance authority exercises its Art. 74(12) right of full access to the documentation and to the training, validation and testing datasets, where appropriate through APIs or other remote technical means. Note also the Art. 74(13) conditions for source-code access: only where access to source code is necessary to assess conformity and the testing or auditing procedures based on the data and documentation have been exhausted or proved insufficient, and then only on a reasoned request. On language, state the language the file is maintained in, which language version is supplied to which Member State authority, and which text governs if a translation and the original diverge. Third-country providers must also record the arrangement under which the EU authorised representative (Art. 22) keeps a copy.

    Evidence to attach

    • · Storage and version-control description (system, permissions, backups)
    • · Authorised representative mandate and the agreed scope of documents it holds
    • · Authority-request response process (contact, turnaround, access methods available)
    • · Inventory of language versions and translation-accuracy checks
    • · Technical description of remote (API) access capability and its access logs

    Common pitfalls

    • · A file scattered across several teams’ private spaces, impossible to assemble within a reasonable time on request;
    • · An authorised representative with a signed mandate but no copy of any document;
    • · A Chinese-only file translated ad hoc for a Member State authority, with inconsistent terminology;
    • · No pre-designed controlled-access route to the training, validation and testing datasets, leaving the company reactive to an Art. 74(12) request.