TL;DR: A model card is the spec sheet for an AI model: what it was built to do, how it was evaluated, where it fails, and how to use it responsibly. Reading one is the cheapest risk assessment you will ever do - and writing one is how you extend that courtesy to whoever builds on your model next.
How it works
Suppose you are about to wire a speech-recognition model into a customer service line. Its model card tells you it was evaluated mostly on clearly-recorded English and that error rates climb for accented speakers and noisy audio - which is exactly the failure your call center will hit on day one. That is the job of a model card: surface the limits before deployment does. The idea was formalized in a 2019 research paper, "Model Cards for Model Reporting," which argued that models should ship with standardized documentation the way appliances ship with safety labels, and it has since become the default convention for publishing models.
A good card covers a predictable set of sections: the intended use and, just as important, the out-of-scope uses the builders never designed for; a summary of the training data and its known gaps; evaluation results, ideally broken down by subgroup and condition rather than a single average - the same numbers covered under model benchmarks; known limitations and biases; and the safety mitigations applied. Related formats extend the idea outward: datasheets document datasets the same way, and system cards describe an entire deployed product - model, filters, policies, and all - rather than the model alone.
Builders use cards in three ways. When choosing a model, the card is the first filter: an out-of-scope note that matches your use case is a red flag no benchmark score offsets. In governance, cards are the documentation backbone - the risk-based obligations in AI regulation lean heavily on exactly this kind of record. And when you customize a model through fine-tuning, the base card stops being accurate - your training changed the behavior, so honest practice is to write a card for your variant, recording what you changed and what you retested. A card is a snapshot, not a guarantee; it describes the model as tested, and it is only as trustworthy as the evaluations behind it.
Where it sits in the AI stack
The model card sits between a model's evaluation and everyone downstream who has to decide whether to trust it:
Key formats and implementations
-
Hub model cards
The templated README-style cards attached to every model on public model repositories.
-
System cards
Provider reports that document a whole deployment - model, safeguards, and policies together.
-
Datasheets for datasets
The companion format documenting how a dataset was collected and what it fails to represent.
-
Internal model registries
Company catalogs that require a card before any model, built or bought, reaches production.
Related entries
- Responsible AI The organizational practice of building AI systems that are fair, transparent, and accountable.
- AI regulation Laws and frameworks that govern how AI systems can be built and deployed, usually scaled to the risk they pose.
- Choosing a model A framework for weighing capability, latency, cost, privacy, and openness when picking a model for a task.
- Evals (AI evaluations) Structured tests that score an AI system's outputs so teams can measure quality and catch regressions.