Model Cards › Summary

Model cards are structured documents that communicate what a model can do, who it is designed for, where it fails, and what risks it poses. They emerged in 2018 to address asymmetric information between model developers and downstream deployers, and have since become an industry norm and regulatory requirement in many contexts.

The essential sections of a model card are:

• Model details: Identifying information, version, and license
• Intended use: Specific tasks, user populations, and explicit out-of-scope applications
• Training data: Sources, size, time period, and known limitations
• Evaluation results: Benchmark performance, including disaggregated results by subgroup
• Quantitative analyses: Confidence intervals, threshold curves, and intersectional breakdowns
• Ethical considerations: Known biases, privacy risks, and dual-use potential
• Limitations and recommendations: Actionable guidance derived from known failure modes

The most impactful sections are also the most often neglected: disaggregated evaluation results and honest limitation documentation. Aggregate performance numbers look good but hide subgroup disparities; limitation sections that acknowledge known failures are more useful and more credible than cards that present only successes.

Writing effective model cards requires specificity over breadth in intended use statements, evidence-backed claims in evaluation results, and translation of performance metrics into deployment implications. For foundation models with broad capabilities, documenting intended use requires capability taxonomies rather than specific task lists, and layered documentation that distinguishes pre-trained model properties from fine-tuned deployment properties. The regulatory context makes documentation quality increasingly consequential: frameworks like the EU AI Act treat model documentation as a compliance requirement, and documentation gaps create legal as well as operational risk.

Keeping cards current as models evolve requires automated evaluation infrastructure and organizational processes that treat documentation updates as part of the release cycle rather than an afterthought. Community feedback integration, where post-deployment observations from users and external auditors update official documentation, produces substantially more complete limitation coverage than developer-only cards. Model cards are not a complete solution to deployment risks, but they are an essential tool for making those risks visible before deployment rather than after.