EU AI Act Annex III: a practical compliance checklist
What Annex III transparency obligations actually require, mapped to specific manifest fields — not a law summary, an implementation list.
The EU AI Act does not care that your model is accurate. It cares that you can show your work. Here is what to hand an examiner, field by field.
Annex III of the EU AI Act imposes transparency obligations on a class of AI systems: logging, traceability, and the ability to explain how an output was produced. Most compliance writing about it summarizes the law. This post does not. It maps each obligation to a concrete field in a per-output audit manifest — the artifact we are building — so a compliance officer can see exactly what to hand an examiner and where it lives.
A caveat up front, because it matters: this is binding law in the EU (not supervisory guidance like SR 11-7), and the manifest attests provenance and reproducibility, not truth. Nothing below certifies that an output is correct; it certifies that the computation is reconstructable. Your auditor knows the difference; the Act does too.
The fields an examiner will ask for
- Model identity + version — which model, which release, which weights. Manifest field: model_version, hash-pinned.
- Input snapshot — the exact NodeVersions the query read. Manifest field: input_nodeversions (L1–L4 refs, hash-chained).
- Prompt + parameters — what was asked and how. Manifest field: prompt_template_id + generation_config.
- Agent run record — which of the 23 A2A agents participated, in what order. Manifest field: agent_trace (CRDT-merged).
- Output + timestamp — what came back, signed and sealed. Manifest field: output_bytes + ts + chain_link.
- Replay anchor — a hash that lets a third party reproduce the computation bit-for-bit. Manifest field: replay_hash.
Logging that survives an audit window
Annex III logging has to outlive the system that produced it — examiner windows are long, and the log has to mean the same thing months later. The manifest is append-only and hash-chained (BR-842), so a log entry cannot be retroactively edited without breaking the chain. That is the property the Act is reaching for when it asks for "automated logging": not a text file, an unforgeable record.
The Act asks for "automated logging." What it needs is an unforgeable record. A text file is not that; a hash-chained manifest is.
Traceability across model swaps
A common compliance failure: the log records "model v2 produced output X," then the team swaps to model v3, and v2 is gone — so the log is now uncheckable. The manifest pins the model by hash, not by name, and the provenance record is provider-agnostic. Swap the live model; the chain still verifies against the historical one. Bring your own keys, own your history.
Reproducibility is the deliverable Annex III is pointing at, even where it only says "logging." A log you cannot replay is not a log an examiner can use.
— compliance design note
What this does not get you
A complete manifest is not a complete compliance posture. It gets you through the transparency obligations; it does not get you through a risk assessment, a fundamental-rights impact assessment, or human-oversight design. Those are separate work. But of the pieces an examiner asks for first — "show me how this decision was made" — the manifest is the artifact that answers, and the checklist above is the field map. We are pre-revenue, building the POC; the manifest fields exist, and calibration of the underlying forecasts is gated (Gate 1b) before any accuracy is claimed.