Your Model Card Is Not Annex IV Technical Documentation
Correct as of August 2026. A model card — the informal, largely voluntary practice of documenting a model's intended use, training data, and known limitations — has existed as a community norm for years. The EU AI Act's Annex IV takes the same idea and makes a version of it a legal filing requirement for high-risk AI systems, and the two documents are not the same size.
What Annex IV actually asks for
Annex IV requires a general description of the system and its purpose, how it interacts with other systems, the hardware it runs on, and a detailed account of its design specifications — considerably more structural detail than a typical model card's paragraph on intended use. Content was rephrased for compliance with licensing restrictions. It goes on to require documentation of the data used to train, validate, and test the system; the risk-management measures applied; and the human-oversight mechanisms built in. One practical summary of the requirement describes model cards as a useful starting point for satisfying part of what Article 13 and Annex IV require — a useful starting point, not a finish line. Content was rephrased for compliance with licensing restrictions.
The gap between "starting point" and "compliant filing" is where most teams' existing documentation falls short. A model card that names the training corpus at a high level is not the same as documenting the corpus's provenance, licensing, known biases, and the specific quality-filtering steps applied to it — which is closer to what dataset documentation as a discipline is built to produce, and closer to what Annex IV is actually asking for.
Why this is a bigger lift than it sounds
Three parts of Annex IV are routinely underestimated. Risk management requires documenting not just that risks were considered but the specific measures taken and their residual effectiveness — a narrative most model cards skip entirely in favor of a bulleted "limitations" section. Human oversight requires describing the actual mechanism by which a human can intervene or override the system, which most teams have never formally specified because it lived as tacit process knowledge rather than a written control. Post-market monitoring requires an ongoing commitment to update the documentation as the system's real-world behavior is observed, which turns technical documentation from a one-time artifact into a maintained one — closer in spirit to the lineage tracking that data governance already treats as a first-class problem than to a document written once at launch and left alone.
What to do before the deadline you're closest to
Audit your existing model cards against the Annex IV table of contents directly, section by section, rather than assuming coverage. The gaps are almost always in the same three places: risk-management narrative, the human-oversight mechanism, and training-data provenance detailed enough to support an actual compliance review rather than a marketing-friendly summary.
If your system falls under a high-risk classification, treat technical documentation as a living artifact owned by whoever owns the model in production, not a one-time deliverable owned by whoever wrote the original launch model card. The organizations finding this hardest are the ones discovering, mid-audit, that the person who could answer the provenance questions left the company two years ago and nothing was written down.