What Is an Annex IV Technical File? EU AI Act Technical Documentation for Engineers

What Article 11 Requires and Why It Matters

Art. 11Article 11 is the legal basis; Annex IV is the technical specification it references. The Article sets out the obligation — providers must draw up technical documentation before placing a high-risk AI system on the market or putting it into service. Annex IV enumerates exactly what that documentation must contain.

Two timing points are frequently misunderstood. First, the technical file must be drawn up before market placement — it is a precondition for CE marking, not a post-launch deliverable. CE marking without a completed Annex IV file is unlawful. Second, under Art. 18, the file must be retained for 10 years after the system is placed on the market, not just maintained until launch.

The obligation falls on providers only. Deployers are not required to produce a technical file, though they have separate obligations under Article 26. For guidance on which role applies to your organisation, see provider obligations under the EU AI Act. Note also that a deployer who substantially modifies a third-party system or deploys it outside its intended purpose may be reclassified as a provider — see Article 25 reclassification scenarios.

The 9 Sections of an Annex IV Technical File

Annex IV specifies nine mandatory sections. Every high-risk AI system's technical file must address all nine — there is no optional set. The sections below are the exact categories defined in the regulation, mapped to the concrete engineering artefacts each one requires.

1. General description: intended purpose, version history, deployment context
2. Development process: architecture, data, training, validation, cybersecurity
3. Monitoring and control: accuracy metrics by subgroup, human oversight
4. Performance metric justification: why chosen metrics fit the use case
5. Risk management system: hazards, mitigations, residual risk sign-off
6. Lifecycle changes: pre-determined changes, substantial modification log
7. Applied standards: harmonised standards used or alternative common specs
8. EU Declaration of Conformity per Annex V
9. Post-market monitoring plan: drift, incidents, escalation runbook

How to Build Your Technical File from an ML Pipeline

The most efficient path is integrating documentation generation into your MLOps pipeline from project inception, not reconstructing it retroactively before a deadline. Industry estimates put retroactive documentation at 2–3× the effort of concurrent documentation.

1. 1

   Start at project kick-off, not before launch

   Create a documentation repo alongside your model repo on day one. Recommended: a docs/compliance/ directory version-controlled in Git alongside your src/.

2. 2

   Write your system card (Section 1)

   Document intended purpose, deployment context, known limitations, and target populations. Commit to a system-card.md. This doubles as your model card for external communication.

3. 3

   Generate dataset datasheets (Section 2d)

   One datasheet per dataset (training, validation, test). Cover provenance, collection method, known biases, preprocessing steps, and class distribution. Reference: Google's Datasheets for Datasets format, adapted for Art. 10 compliance.

4. 4

   Capture architecture and design decisions (Section 2a–c)

   Document model architecture, hyperparameter choices, training infrastructure, and software dependencies (SBOM). Suggested tools: MLflow, DVC for data lineage; Architecture Decision Records (ADRs) for design rationale.

5. 5

   Run and record validation testing (Section 2f–g)

   Disaggregated benchmark results by protected attribute groups. Document acceptance criteria before running tests — Art. 9(8) requirement. Tools: Fairlearn, AI Fairness 360, Weights & Biases eval tables.

6. 6

   Build and version your risk register (Section 5)

   Enumerate failure modes using FMEA-ML or a structured hazard analysis. Score probability × severity. Map each risk to a design control or deployer safeguard. Track mitigation evidence.

7. 7

   Configure your logging pipeline (Section 2g / Art. 12)

   Per-inference structured logging to an append-only store. Capture: input hash, prediction, confidence, model version, timestamp, latency. Minimum 6-month retention.

8. 8

   Define your post-market monitoring spec (Section 9)

   Specify drift detection thresholds, subgroup metric monitoring schedule, incident escalation path, and serious incident reporting triggers per Art. 73.

9. 9

   Assemble and sign the Declaration of Conformity

   Reference all applicable Annex III use cases and harmonised standards used. Must be signed by an authorised representative.

10. 10

    Set up a document control process

    Version control the entire file. Log every substantial modification. Set calendar reminders for periodic review — recommended every 12 months or on any model retrain.

Risk Management Documentation That Satisfies Article 9 Art. 9

A compliant Article 9 risk management system requires maintaining a version-controlled risk register that maps each identified hazard to probability × severity scores, tested against pre-defined probabilistic thresholds (e.g., FPR ≤ 0.01 for safety-critical classifications), with mandatory re-evaluation whenever post-market monitoring surfaces new failure modes or data drift. Engineering teams must produce three concrete artefacts at each lifecycle stage: a risk analysis matrix covering health, safety, fundamental rights, and discrimination categories; a mitigation traceability record linking each risk to its design-level control or deployer-facing safeguard; and signed, dated test reports demonstrating residual risk acceptability — including subgroup-disaggregated results for persons under 18 and other vulnerable populations per Art. 9(9). The process must be iterative and documented as a living system, not a one-time pre-launch gate review.

For fundamental rights risk categories, providers should produce a Fundamental Rights Impact Assessment (FRIA) alongside the Article 9 risk register. These are related but distinct obligations.

Data Governance Evidence a Notified Body Expects Art. 10

Article 10 requires producing dataset datasheets documenting provenance, collection purpose, labelling procedures, and cleaning methods for every training, validation, and test split. Bias analysis must go beyond aggregate accuracy: you need disaggregated fairness metrics (e.g., equalized odds, demographic parity) across all protected attributes relevant to your deployment population, with explicit documentation of feedback-loop amplification risk per Art. 10(2)(f). For a notified body review, the minimum evidentiary bar is a representativeness report comparing your training distribution against the intended deployment population's demographics, a quantified data error rate from systematic validation sampling, and a documented gap analysis with remediation plan — the "to the best extent possible" qualifier in Art. 10(3) means demonstrated process rigour, not zero defects.

Logging, Audit Trails, and the 6-Month Retention Rule Art. 12

Article 12 requires high-risk AI systems to implement automatic event logging covering three regulatory purposes: risk detection (Art. 79), post-market monitoring (Art. 72), and deployer oversight (Art. 26(5)), with a minimum 6-month retention per log entry under Art. 19(1) and Art. 26(6), and 10-year retention for the broader technical file under Art. 18. In practice, build an append-only structured log pipeline — immutable event store or write-ahead log with hash chains — capturing per-inference records (input hashes, output predictions, confidence scores, model version, feature values, latency) plus system-level events like model deployments, config changes, and human overrides. The forthcoming ISO/IEC DIS 24970 and CEN-CENELEC EN 18229-1 standards will define the normative logging framework.

Post-Market Monitoring Beyond SRE Dashboards Art. 72

Article 72 post-market monitoring demands an active data collection pipeline that goes well beyond SRE dashboards: you must systematically track compliance-relevant signals across all Chapter III requirements — including data drift detection against the original Art. 10 training distribution baseline, subgroup-disaggregated fairness metric monitoring, human override rates, and interaction effects with other AI systems in the deployment stack. When monitoring detects a serious incident — defined as death, serious health harm, critical infrastructure disruption, fundamental rights infringement, or serious environmental damage under Art. 3(49) — this triggers tiered reporting obligations under Art. 73 with deadlines of 2–15 days depending on severity, creating a direct engineering requirement for automated anomaly detection with low-latency alerting to your compliance function.

Harmonised Standards Are Not Ready — What to Use Instead

The following standards are in active development under CEN/CENELEC JTC 21:

Already published — use now:

• ✓ISO/IEC 5259 Parts 1–4 (data quality for ML) — published 2024
• ✓ISO/IEC 23894:2023 (AI risk management guidance) — operational
• ✓ISO/IEC 22989 (AI terminology), ISO/IEC 23053 (ML framework) — foundational
• ✓NIST AI RMF — complementary risk management methodology
• ✓ISO/IEC 42001:2023 (AI management system) — useful operational framework, not being harmonised

The Digital Omnibus proposal may delay Annex III obligations to December 2027, but trilogue has not begun as of late March 2026. Build as if August 2, 2026 is still the deadline. Track live standard development at ai-act-standards.com.

For GPAI and foundation model obligations under Annex XI/XII (separate from Annex IV), see GPAI and foundation model obligations.

Annex IV Technical File Checklist

Use this checklist to track coverage against all 9 Annex IV sections. Every item is a required artefact or process for high-risk AI system providers.

Compliance Deadlines and What Triggers a File Update

What triggers a mandatory technical file update:

• ▸Model retrain with new or modified training data
• ▸Architectural changes to the model
• ▸Changes to deployment context or intended purpose
• ▸Post-market monitoring discovers systematic performance degradation
• ▸Serious incident reported under Art. 73
• ▸New failure modes discovered not in the original risk register
• ▸Any change classified as a "substantial modification" under Art. 83(5)

What does NOT require a new conformity assessment:

• ✓Pre-determined changes documented in the original technical file
• ✓Bug fixes that do not affect AI system performance
• ✓UI changes that don't affect model inputs or outputs

Frequently Asked Questions About Annex IV