A model card is a short, structured document that accompanies an AI model and describes what it is, what it was trained on, how it performs, and — critically — where it is known to fail. The format was popularized by researchers at Google in 2019 and is now close to a norm on model hubs like Hugging Face, though quality varies enormously from one card to the next.
What changed in 2026
- Regulatory pressure pushed more disclosure into model cards, particularly around training data provenance and known bias, in jurisdictions with AI transparency requirements.
- Automated model card generation tools spread, pulling evaluation results and dataset metadata directly from training runs — useful for keeping cards current, but they still need a human to write the limitations section honestly.
- Model cards increasingly link to a versioning history rather than describing a single static model, reflecting how often production models get updated. See our model versioning guide for how teams track that.
What a model card actually contains
At minimum, a useful model card covers: what the model does and its intended use, explicit out-of-scope uses, the training data source and any known limitations in it, evaluation results (ideally against a named benchmark, not just a vague accuracy number), known failure modes and biases, and contact or maintenance information.
Model card sections compared
| Section |
What it should tell you |
Common gap |
| Intended use |
Tasks the model was evaluated for |
Left vague, invites out-of-scope deployment |
| Out-of-scope use |
Explicit tasks the model should not be used for |
Often missing entirely |
| Training data |
Sources, size, known biases, licensing |
Summarized too briefly to assess |
| Evaluation |
Benchmark results, methodology |
Cherry-picked benchmarks, no methodology |
| Limitations |
Known failure modes, edge cases |
The section most often skipped or thin |
| Ethical considerations |
Risks, fairness concerns, mitigations |
Boilerplate rather than model-specific |
Why model cards matter beyond compliance
A good model card saves you from finding a model's failure modes in production. If the card discloses that a model was evaluated primarily on English text, or that it underperforms on a specific demographic slice, that is information you need before deployment, not after an incident. Model cards also matter for data labeling teams and downstream fine-tuners, who need to know what a base model already knows and does not know before building on top of it.
Reading a model card critically
Treat the intended-use and limitations sections as the most important parts, and treat impressive benchmark numbers with some skepticism if the methodology is not disclosed. A card with polished capability claims and a one-line limitations section is telling you something by omission. When a model card is missing entirely, or clearly generated without human review, run your own evaluation against your specific use case before trusting the model in production.
FAQ
Are model cards required by law?
It depends on jurisdiction and use case; some regions now require disclosure documentation for certain AI systems. Requirements change, so verify current regulation for your jurisdiction rather than relying on general guidance.
Who writes model cards?
Typically the team that trained or fine-tuned the model. For open models on hubs like Hugging Face, cards are often community-contributed or generated by the uploading organization, so quality varies.
Do model cards cover fine-tuned models too?
They should. A fine-tune changes behavior and sometimes introduces new failure modes, so a responsible fine-tuning process updates the model card rather than relying on the base model's card.
What is the single most useful field to check first?
Out-of-scope use. It tells you directly whether your intended application is even a fit, before you invest time evaluating performance.
Where to go next