A model card is a structured document published alongside a machine learning model that describes what the model is for, how it was built and evaluated, where it performs well or poorly and what risks its use carries. In AI safety, model cards are a basic transparency and accountability tool: they let developers, deployers, auditors and affected users judge whether a model fits a given purpose before it is used.
The format was proposed by researchers in 2018 as a counterpart to nutrition labels for AI. Since then it has become a de facto industry practice for open model repositories and major model releases, and it informs the documentation duties that regulations such as the EU AI Act place on providers of AI systems and general-purpose models.
What a model card contains
A model card follows a standard set of sections so that readers can compare models and find critical information quickly. The original proposal defined nine sections, and most current templates keep their substance even when the headings differ.
| Section | What it documents | Why it matters |
|---|---|---|
| Model details | Developer, version, date, architecture, license | Identifies exactly which model is described |
| Intended use | Primary uses, intended users, out-of-scope uses | Defines the boundaries of safe deployment |
| Factors | Groups, environments and conditions relevant to performance | Shows where results may differ |
| Metrics | Evaluation measures, thresholds, uncertainty | Explains how performance was judged |
| Evaluation data | Datasets used for testing and why | Lets readers assess representativeness |
| Training data | Sources, size, preprocessing, known gaps | Reveals possible biases and coverage limits |
| Quantitative analyses | Results overall and disaggregated by factor | Exposes uneven performance |
| Ethical considerations | Risks, sensitive data, potential harms | Supports risk assessment |
| Caveats and recommendations | Known limitations and usage advice | Guides responsible deployment |
The most valuable part is usually the disaggregated evaluation: reporting results separately for relevant groups, languages or conditions rather than as a single average. A single headline number can hide large performance gaps that only appear in subgroups.
Model cards for large language models
For large language models and other general-purpose systems, model cards have grown into longer system cards or technical reports. They add sections that the original format did not need, because the range of possible uses is open-ended and risks emerge from capabilities rather than from a single task.
- Capability evaluations on standard benchmarks for reasoning, coding and knowledge.
- Dangerous capability testing, for example in cybersecurity or biological knowledge.
- Red teaming results describing how adversarial testers tried to provoke harmful output.
- Safety mitigations such as refusal training, filters and usage policies.
- Alignment and behavior evaluations covering honesty, sycophancy and instruction hierarchy.
- Known limitations including hallucination rates on specific tasks and context-length effects.
These documents connect directly to neighboring AI safety practices. AI red teaming supplies findings, AI bias analyses supply disaggregated results, and explainable AI methods can support the description of how the model reaches its outputs.
Model cards compared with other documentation
A model card documents one model. It sits within a wider set of documentation artifacts that each cover a different layer of an AI system.
| Document | What it describes | Typical author |
|---|---|---|
| Model card | A trained model, its use and performance | Model developer |
| Datasheet for datasets | A dataset’s motivation, collection and composition | Dataset creator |
| System card | A deployed system including model, safeguards and interfaces | Product or safety team |
| AI impact assessment | Effects of a specific deployment on people and rights | Deploying organization |
| Technical documentation (regulatory) | Information required by law for conformity assessment | Provider of the AI system |
A model card is not a compliance document by itself. Regulatory technical documentation is usually more detailed and partly confidential, while a model card is written for a broad audience. Many organizations, however, use the model card as the public summary of deeper internal records.
Writing a useful model card
A useful model card is specific, honest about limitations and maintained over time. Generic statements such as the claim that a model may produce errors add little; concrete descriptions of where and how it fails are what readers need.
| Aspect | Weak practice | Strong practice |
|---|---|---|
| Intended use | Broad claims of general usefulness | Named use cases and explicit out-of-scope uses |
| Performance | One aggregate metric | Disaggregated results with uncertainty ranges |
| Training data | Vague mention of public sources | Sources, time range, languages and known gaps |
| Limitations | Boilerplate disclaimers | Observed failure modes with examples |
| Versioning | Card written once at release | Card updated with each model version |
The card should be written for several audiences at once: engineers who integrate the model, managers who approve deployment, auditors who check claims and members of the public who may be affected. A short summary at the top and precise detail below serve all of them.
Limitations of model cards
Model cards depend on voluntary disclosure and self-reporting, so their quality varies widely. Studies of public model repositories have found that many cards leave sections empty, especially those on limitations, biases and evaluation.
Other limits are structural. A card describes a model at release time, but risks change when the model is fine-tuned, combined with tools or used in new contexts. Developers may also select favorable benchmarks, and readers rarely have the means to verify claims independently. For these reasons, model cards work best as one element of a broader governance process that includes independent evaluation, monitoring and incident reporting.
Put simply
A model card is like the label and instruction leaflet for an AI model. Medicine comes with a leaflet that explains what it treats, who should not take it and what side effects to expect. A model card does the same for a piece of AI.
It tells you what the model was built to do, how well it works for different people and situations, and where it is likely to make mistakes. Anyone deciding whether to use the model can read it first and avoid using the tool for a job it was never meant to handle.
In practice
A hospital network considers adopting an open speech recognition model to transcribe doctor-patient conversations. Before any testing, its AI governance group reads the model card.
The card lists medical transcription as out of scope, reports word error rates disaggregated by accent and recording conditions and notes that the model sometimes inserts plausible words during long silences. The training data section states that clinical vocabulary was underrepresented.
Based on these disclosures, the group decides against direct deployment. It commissions an internal evaluation on 50 hours of anonymized clinical audio, which confirms higher error rates for medication names. The hospital fine-tunes the model, adds mandatory clinician review of every transcript and publishes its own updated model card describing the adapted version, its new evaluation results and the remaining limitations.