Public reference

The Annex IV Mapping

Annex IV is the EU AI Act's technical-documentation requirement — what the regulator wants to see when a high-risk AI system is placed on the market. We translate each requirement into the engineering source where the evidence usually already exists in a disciplined ML platform, plus the gap pattern we see most often and a default severity. The Diagnostic surveys these rows; the Sprint analyses them per system; the Programme operationalises the technical file so it stays current as your models change.

Annex IV §1 — system description

The first paragraph of Annex IV asks for a general description of the system: what it is, how it ships, what it talks to. Most rows have low default severity because the artefacts are typically already documented somewhere in your engineering wiki or release process — the gap is shape, not substance.

  • Annex IV §1(a)

    Intended purpose; persons developing the system; date and version

    Where it lives in your stack
    Model registry entry; Git tag; release-gate metadata
    Common gap
    Often complete in MLflow or W&B; sometimes missing the 'intended purpose' prose statement
    Low

  • Annex IV §1(b)

    Provider details (name, address, etc.)

    Where it lives in your stack
    Company registration data
    Common gap
    Boilerplate; almost never a gap
    Low

  • Annex IV §1(c)

    How the system interacts with hardware and software not part of the AI system

    Where it lives in your stack
    Service architecture diagrams; interface contracts; SDK docs
    Common gap
    Usually exists in the engineering wiki, never in Annex IV shape
    Medium

  • Annex IV §1(d)

    Versions of relevant software / firmware

    Where it lives in your stack
    Container manifests; lock files; CI artefacts
    Common gap
    Usually exists; sometimes only in CI logs and not in a written artefact
    Low

  • Annex IV §1(e)

    Forms in which the system is placed on the market — boxed product, online API, embedded SDK, etc.

    Where it lives in your stack
    Product / release docs
    Common gap
    Usually clear from the product surface; needs a one-line written statement
    Low

  • Annex IV §1(f)

    Description of the hardware on which the system runs

    Where it lives in your stack
    Infra-as-code (Terraform, Pulumi, etc.); deployment manifests
    Common gap
    Often complete in IaC; needs a prose summary
    Low

  • Annex IV §1(g)

    Validation and testing logs, signed and dated

    Where it lives in your stack
    MLflow / W&B run history; CI logs
    Common gap
    Almost always exists; signing-and-dating discipline missing
    Medium

  • Annex IV §1(h)

    User-interface description (where applicable)

    Where it lives in your stack
    UX docs; user-facing screenshots
    Common gap
    Usually exists for B2C; thinner for API-only products
    Low

  • Annex IV §1(i)

    Instructions for use to deployers (where applicable)

    Where it lives in your stack
    API docs; SDK guides; deployer-facing manuals
    Common gap
    Often exists; not in regulator format
    Low

Annex IV §2 — detailed technical description

The second paragraph is where the heavy lifting sits: design choices, data sheets, validation, predetermined changes, cybersecurity. Most rows are medium-to-high severity because the artefacts often exist informally (model cards, design discussions in Slack, evaluation notebooks) but not in a regulator-readable form.

  • Annex IV §2(a)

    General logic / methodology used to develop the system

    Where it lives in your stack
    Model card; design doc; ADR-style notes
    Common gap
    Most common gap — model cards rarely written with the discipline Annex IV requires
    High

  • Annex IV §2(b)

    Design choices, key assumptions, rationale

    Where it lives in your stack
    Same as §2(a) plus commit history and design discussions
    Common gap
    Same gap pattern as §2(a) — assumptions live in tribal memory, not in writing
    High

  • Annex IV §2(c)

    System architecture description

    Where it lives in your stack
    Architecture diagrams; service docs
    Common gap
    Usually exists; needs an Annex IV–shape document
    Medium

  • Annex IV §2(d)

    Data sheets — sources, training / validation / test data, lineage, biases

    Where it lives in your stack
    Data documentation; ETL configs; data lineage tools
    Common gap
    Common gap — most teams have lineage but not datasheets
    High

  • Annex IV §2(e)

    Human oversight description (Article 14 alignment)

    Where it lives in your stack
    Product UX showing human-review affordances; reviewer training materials
    Common gap
    Often informal; needs a written human-oversight design
    Medium

  • Annex IV §2(f)

    Predetermined changes / continuous-learning behaviour

    Where it lives in your stack
    Change-control log; feature-flag config; retraining cadence doc
    Common gap
    Often exists in process; not in writing
    Medium

  • Annex IV §2(g)

    Validation and testing procedures, including metrics

    Where it lives in your stack
    W&B reports; evaluation code; test pipelines
    Common gap
    Usually exists; not signed and dated
    Medium

  • Annex IV §2(h)

    Cybersecurity measures

    Where it lives in your stack
    SOC 2 / ISO 27001 documentation; threat model; incident-response runbook
    Common gap
    Often exists for SOC 2 mature teams; needs Annex IV–shape mapping
    Medium

  • Annex IV §2(i)

    Algorithms used (where disclosable)

    Where it lives in your stack
    Model cards; published architecture
    Common gap
    Usually disclosable in summary form
    Low

Annex IV §3–§9 — operational and governance layers

The remaining paragraphs cover monitoring, performance metrics, the risk-management system, lifecycle changes, harmonised standards, the declaration of conformity, and post-market monitoring. The largest single gap on most engagements is §9 — the post-market monitoring plan rarely exists in writing when we walk in.

  • Annex IV §3

    Detailed information on monitoring, functioning and control of the system

    Where it lives in your stack
    Monitoring dashboards; SLO docs; on-call runbook
    Common gap
    Often exists in SRE docs; needs Annex IV–shape
    Medium

  • Annex IV §4

    Performance metrics including by demographic subgroup (links to Article 15)

    Where it lives in your stack
    Slice-level metrics in training pipeline (fairlearn, Aequitas)
    Common gap
    Common gap — computed at training time but not exported per shipped system
    High

  • Annex IV §5

    Article 9 risk-management system description

    Where it lives in your stack
    Written RMS document
    Common gap
    Rarely exists in writing; sometimes informal in incident-review processes
    High

  • Annex IV §6

    Description of relevant changes throughout the system's lifecycle

    Where it lives in your stack
    Change-control log; CHANGELOG.md
    Common gap
    Often complete in Git; needs a prose summary
    Low

  • Annex IV §7

    Harmonised standards applied (where any)

    Where it lives in your stack
    ISO 42001 / harmonised standards mapping
    Common gap
    Rarely applicable in 2026; flag if relevant
    Low

  • Annex IV §8

    Copy of the EU declaration of conformity (Article 47)

    Where it lives in your stack
    Declaration template, signed
    Common gap
    Drafted as part of the Programme tier
    Medium

  • Annex IV §9

    Post-market monitoring plan (Article 72 link)

    Where it lives in your stack
    PMM plan document
    Common gap
    Largest single gap — PMM plan rarely exists in writing on engagement entry
    Critical

Operating articles bundled into the Mapping

Five Articles whose evidence trails are commonly included in the technical file even though they sit outside Annex IV proper. Article 12 (logging), Article 13 (transparency to deployers), Article 14 (human oversight), Article 15 (accuracy, robustness and cybersecurity), and Article 73 (incident reporting on the 15 / 10 / 2-day clocks).

  • Art. 12

    Automatic logging of events relevant to traceability

    Where it lives in your stack
    Inference-layer structured logs; trace IDs
    Common gap
    Usually exists; needs traceability proof and retention policy
    Medium

  • Art. 13

    Transparency / instructions to deployers

    Where it lives in your stack
    Deployer-facing docs
    Common gap
    Usually exists for SaaS; thin for embedded
    Medium

  • Art. 14

    Human oversight design

    Where it lives in your stack
    UX patterns plus on-call runbook
    Common gap
    Same as §2(e); merged in practice
    Medium

  • Art. 15

    Accuracy, robustness, cybersecurity assessment

    Where it lives in your stack
    Eval reports plus adversarial-test reports
    Common gap
    Robustness and cybersecurity tests often missing
    High

  • Art. 73

    Serious incident reporting workflow (15 / 10 / 2-day clocks)

    Where it lives in your stack
    On-call rota plus incident process; classification SLA
    Common gap
    Detection exists; reporting SLA almost never
    High

How the Mapping is applied per engagement

Defaults are typical for a Series B/C ML team. Per-engagement, severity is overridden based on procurement materiality, engineering effort to close, and penalty exposure — Article 5 and Article 9 ties bump rows to Critical.

  • Diagnostic

    Qualitative scan of all 30 rows for up to 3 systems. Material gaps flagged.

    → One-page gap snapshot.

  • Readiness Sprint

    Full 30-row analysis per system. Every row gets a status, severity and evidence note.

    → Annex IV gap analysis document.

  • Programme

    The Mapping becomes operational. New deployments populate the right rows automatically.

    → Maintained Annex IV technical file v1.0 plus the workflow that keeps it current.

See the Mapping applied to your stack

The Diagnostic produces a one-page gap snapshot in 3 to 5 days. — we confirm classification and the highest-leverage gaps in the call, free.

Speak with us

Tell us a little about your situation. We reply within one working day; no sales pitch, just a short read of your AI Act exposure and where to start.