A model card is a standardised document describing an AI model's purpose, training, evaluation, limitations, intended use and known risks. The concept was introduced by Margaret Mitchell and colleagues at Google in 2018, and by 2026 model cards have become a foundational governance artifact — required by the EU AI Act for general-purpose AI providers, recommended by the NIST AI Risk Management Framework, and standard practice for any responsibly released model.
A typical model card covers:
- Model details — architecture, parameter count, training compute, intended use cases, owners, contact, version history.
- Intended uses — what the model is and is not designed for; downstream applications expected and discouraged.
- Training data — sources, time period, language coverage, demographic representation, known biases or gaps.
- Evaluation results — performance on standard benchmarks, plus disaggregated results across demographic and contextual subgroups.
- Limitations — known failure modes, edge cases, hallucination rates, safety boundaries.
- Ethical considerations — risk categories, mitigation measures, recommendations for downstream developers.
- Environmental impact — training compute, energy use, carbon footprint where measurable.
- Citations and licensing — how to credit, what licence applies, responsible use guidelines.
The 2026 ecosystem:
- Hugging Face Model Cards — required for all public models on the Hub; standardised template; widely used.
- OpenAI System Cards — published for GPT-5, image generation models and other major releases.
- Anthropic Model Cards — published for Claude Sonnet 4 and family; among the most detailed in the industry.
- Google Model Cards — published for Gemini family and Gemma open-weight models.
- Meta Model Cards — published for Llama family; expanded substantially through 2025–2026.
- Stability AI, Mistral, DeepSeek — publishing model cards as community and regulatory expectations have grown.
What model cards have actually changed:
- Procurement scrutiny — enterprise and government buyers now request model cards as part of due diligence.
- Compliance documentation — model cards are part of the technical documentation EU AI Act requires for GPAI providers.
- Downstream developer awareness — teams building on top of a model can read its limitations before discovering them in production.
- Public discourse — journalists and researchers cite model cards when analysing capability and risk.
The honest limitations:
- Quality varies wildly — some are genuinely informative; others are marketing thin-cover.
- Self-reported — model card claims about evaluation results are not independently audited unless the provider also publishes test sets.
- Static — models are updated continuously in production; model cards age unless explicitly versioned.
- Coverage gaps — model cards rarely include specific dangerous-capability evaluations or full detail on safety training.
For a US team building AI products in 2026, model cards matter on both sides. Read them for any model you depend on — knowing the model's stated limitations is part of designing safely around them. Write them for any model you fine-tune or release, even internal-only ones — it forces clarity about what the model is for and what it is not, and creates documentation that survives team changes. The discipline of writing the model card before final deployment is one of the cheapest, highest-leverage governance practices an AI team can adopt.
