What is Model Card?
Also called model documentation.
A model card is a structured document that describes a model's intended uses, training approach, evaluation results, limitations, and known risks. It accompanies a released model so that adopters can judge fitness for their purpose without reverse-engineering behavior. The format was proposed to make responsible disclosure a routine part of model release.
A typical card covers basic details such as architecture family, size class, modalities, and release date; intended and out-of-scope uses; training data at whatever level of detail the developer discloses; evaluation results including disaggregated performance across relevant groups; known limitations and failure modes; and safety, licensing, and contact information.
The purpose is to shift responsibility for disclosure onto the developer, who knows the most, rather than leaving each adopter to discover limitations through production incidents. Disaggregated evaluation matters especially, because a single average score can hide substantially worse performance for particular languages, dialects, domains, or demographic groups.
Practice varies widely. Some cards are detailed and specific about data sources and measured weaknesses; others are brief marketing-adjacent summaries that omit training data entirely, often citing competitive or legal concerns. Because there is no enforced standard for depth, the presence of a card says less about transparency than its actual contents do.
Regulatory pressure is increasing the baseline. Emerging AI governance frameworks require documentation of capability, limitation, and risk for systems above certain thresholds, and internal governance programs increasingly require a card for models developed in-house as well. Related artifacts such as system cards and data statements extend the same idea to deployed systems and datasets.
Key points
- Documents intended use, training, evaluation, and limitations
- Puts disclosure duty on the developer, not the adopter
- Disaggregated results reveal group-specific weaknesses
- Depth varies widely; presence alone means little
- Regulation is pushing documentation toward a required baseline
In practice
A team evaluating a speech transcription model reads its card and finds word error rates reported separately by accent group rather than as one average. The aggregate looks strong, but two of the groups relevant to their user base score noticeably worse. That disclosure changes the deployment plan: they add a human review step for those cases rather than discovering the gap through customer complaints months later.