Handvantage

EU AI Act Annex IV: what your technical documentation actually has to show.

The regulation lists nine elements. Six of them require contemporaneous evidence, not a static document. Most platforms can produce the document. Few can produce the evidence.

Feature image for "EU AI Act Annex IV: what your technical documentation actually has to show."

When a CISO says "we're working on EU AI Act compliance," the next question to ask is which document they're working on. The regulation refers to several. The one that matters for any system in the high-risk classification — and the one most teams underestimate — is the Annex IV technical documentation. Article 11 makes it the basis of conformity assessment. Article 47 makes it the basis of the declaration of conformity. Article 71 makes it the basis of the EU database registration. If the Annex IV dossier is incomplete or unverifiable, the system cannot legally be placed on the market in the EU. Everything else in the high-risk regime is downstream of this document.

The interesting thing about Annex IV is that most teams reading it for the first time treat it as a paper exercise. The text reads like a procurement template: "a general description," "a detailed description," "a list of harmonised standards." An organization can plausibly produce all of that in a week of focused work, ship it to a Notified Body, and receive a conformity assessment. That read of the document misses what an auditor actually does with it. The dossier is not the assessment. The dossier is the index that the assessment uses to walk through the system's behavior during the audit window. Six of the nine elements require contemporaneous, machine-verifiable evidence — not narrative — to survive that walk.

Annex IV has nine numbered sections. Sections 1, 6, 7, and 8 are largely descriptive. Section 1 is a general description: intended purpose, identification of the provider, version of the system, hardware on which it runs, photographs or illustrations of the user interface, instructions for use. Section 6 is a description of relevant changes made through the system's lifecycle. Section 7 is the list of harmonised standards applied (ISO/IEC 42001, ISO/IEC 23894, and so on, where relevant). Section 8 is a copy of the EU declaration of conformity. These four sections are documents. They can be drafted, reviewed, and signed by a competent author in a focused effort. They are the parts most teams have under control.

Sections 2, 3, 4, 5, and 9 are different. They are descriptions of system behavior over time, and an auditor reads them with the audit log open. Section 2 — the detailed description of the system's elements and the development process — references the data sets used, the data labeling and curation practices, the methodology for training and validation, the system's architecture, the design specifications, and the rationale for design choices. Section 3 — monitoring, functioning, and control — describes how the system is monitored in operation and what mechanisms exist to detect malfunction. Section 4 — performance metrics — describes the appropriateness and validation of the metrics used. Section 5 — risk management — describes the system that implements Article 9's continuous risk management requirements, with the residual risks accepted by the provider. Section 9 — post-market monitoring — describes the system in place to evaluate AI performance after deployment, with the plan for collecting feedback and reporting incidents.

Each of these five sections has a paper component (the description) and an evidence component (the proof that what's described is actually happening). The paper component is straightforward. The evidence component is where most platforms break. An auditor reading Section 3 doesn't only want to know "what monitoring exists"; they want to see the monitoring records for the audit window — the events the monitor produced, in sequence, with timestamps that survive third-party verification. An auditor reading Section 5 doesn't only want the risk register; they want to see, for each control declared in the risk register, the specific events in the audit log that demonstrate the control was operating during the window. An auditor reading Section 9 doesn't only want the post-market monitoring plan; they want the monitoring outputs for the period since deployment.

The audit window is the interval during which the system is placed on the market or put into service. The useful operating principle is simple: evidence begins with the workflow, not with a later compliance project. The Annex IV dossier should therefore be supported by the operational history available for the system and deployment in scope.

This is why retrofitted monitoring is structurally weaker. A control added after a workflow has been operating cannot recreate evidence for the earlier period. Sections 3, 5, and 9 each depend on records produced while the described controls and monitoring processes were in use.

A stronger operating pattern is to create evidence while the workflow runs. The record should identify the actor, action, policy or approval, relevant model route, outcome, and assessment window. Integrity controls and external logging should be evaluated against the proposed configuration rather than inferred from a generic architecture. Vantage Workspace can demonstrate append-only event records for bounded workflows; resistance to alteration requires separate proof.

Even with a platform that produces complete Annex IV evidence, the deployer still owns specific responsibilities. The declaration of conformity (Section 8) is signed by the deployer, not the provider. The intended-purpose description (Section 1) reflects the deployer's chosen use case, which the provider does not know in advance. The post-market monitoring plan (Section 9) needs to reflect the deployer's actual deployment context — the user population, the data inputs, the operational environment. The harmonised-standards list (Section 7) reflects the deployer's compliance choices. A platform's evidence record provides the substrate; the deployer's compliance team is what assembles the dossier from the substrate.

Three questions to ask any AI vendor. First: show the operating record for one representative workflow in the evaluation deployment. Second: map each record to the Annex IV documentation question it supports and state what remains the deployer’s responsibility. Third: show how the customer can export and independently review the evidence available in the proposed configuration. A prepared dashboard alone is not enough.

The Annex IV dossier is not a substitute for operating evidence. A buyer can test the distinction during procurement: run one representative workflow, retrieve its decision and approval record, and ask another reviewer to reproduce the evidence without relying on a prepared dashboard.



CONTINUE THE CONVERSATION

If something here is what you're working on, talk to us.

Articles like this one come out of conversations with practitioners, security leaders, and engineering teams in regulated industries. If the writing reflects your situation, the next conversation is probably worth having.

Continue the conversation →

Or write to hello@handvantage.com directly.