Introduction
Model cards became a standard practice for good reason: they force teams to write down what a model is for, what data trained it, what its known limitations are, and how it was evaluated. That discipline is valuable. It is also, on its own, unverifiable. A model card is a document written by the same organization being asked to account for the model - and like any self-reported document, it can be incomplete, outdated, or simply wrong, with no independent way for a reader to know which.
What a Model Card Actually Establishes
At its best, a model card is a well-organized claim: here is what we believe about this model's training data, intended use, and limitations, as of the date this document was written. It is not a receipt. It does not prove the training data described is the training data actually used, that the data hasn't changed since, or that the evaluation results reported reflect the model version currently in production rather than an earlier one the card was never updated to reflect. Under increasing regulatory scrutiny - the EU AI Act's Article 10 and Article 11 documentation requirements chief among them - the gap between a well-written claim and a provable one is exactly where enforcement risk concentrates.
The three gaps regulators are learning to ask about
First, currency: was this model card updated when the model was retrained or fine-tuned, or does it describe an earlier version? Second, source verification: is there any way to confirm the described training data actually is what was used, independent of the document's own assertion? Third, change detection: if the underlying training data were altered after the model card was written, would anyone - including the team that wrote it - necessarily know?
Provenance is a separate layer, not a better model card
Closing these gaps does not mean writing more detailed model cards. It means adding a layer beneath the documentation that can independently verify what the documentation claims: cryptographic anchoring of the actual training dataset at the point it is used, so that the data's origin and any subsequent change are provable rather than described. A model card paired with this kind of verifiable record stops being a claim an auditor has to trust, and becomes a claim an auditor can check.
- Model cards document intent and design decisions - they are not designed to prove anything independently
- A model card's usefulness as evidence degrades the moment a model is retrained without an update to match
- Cryptographic anchoring of training data closes the gap between what a model card claims and what can actually be verified
- Regulators increasingly distinguish between documentation and proof - enterprises should plan for that distinction now, not after an audit exposes it
Documentation describes what a model should be. Only verifiable provenance can prove what it actually is. See how ROOTKey anchors AI training data so documentation claims can be independently verified.
Get cyber-resilience insights in your inbox
Practical, audit-ready guidance on data integrity, compliance and continuity - delivered as we publish.