Intermediate
Model Cards
A model card is a short document that accompanies a trained machine learning model and provides essential transparency information about it. Introduced by Mitchell et al. at Google (2019), model cards are now a standard practice for any AI system released publicly or deployed in a high-stakes context. They serve multiple audiences simultaneously: developers who want to know if a model is fit for their use case, affected individuals who want to understand what decisions the model informs, and regulators who need evidence of responsible deployment.
Standard Model Card Structure
| Section | Content |
|---|---|
| Model details | Name, version, type, training date, organisation, licence, contact, links to related resources |
| Intended use | Primary intended uses; primary intended users; out-of-scope uses; explicitly prohibited uses |
| Factors | Relevant factors that affect model performance — demographic groups, environmental conditions, instrumentation, data formats |
| Metrics | Performance metrics used; thresholds for acceptable performance; decision thresholds if applicable |
| Evaluation data | Dataset(s) used for evaluation; why they were chosen; preprocessing applied; any known limitations of the eval set |
| Training data | Training data description (can be high-level for proprietary systems); notable characteristics or known issues |
| Quantitative analyses | Disaggregated performance metrics by relevant subgroups (race, gender, age, geography) |
| Ethical considerations | Known risks; potential for harm; sensitive use cases; mitigation measures taken |
| Caveats and recommendations | What the model should not be used for; recommendations for monitoring; open questions |
Performance Disaggregation by Subgroup
The most valuable section of a model card — and the one most frequently omitted — is disaggregated performance. Reporting a single aggregate accuracy hides differential performance across demographic or contextual subgroups.
What good disaggregation looks like
- Report the same primary metric (accuracy, F1, recall) per subgroup
- Identify which subgroups are relevant to the deployment context
- Include confidence intervals — small subgroups have high variance
- Flag gaps that exceed a defined threshold (e.g., >5 percentage points)
- Document what was done if gaps were found (mitigation, accepted residual risk)
Common omissions that weaken model cards
- Aggregated metrics only — no per-subgroup breakdown
- Vague ethical considerations section with no specific risks named
- Intended use stated so broadly that it does not exclude any use case
- Training data described as "large-scale web data" with no further characterisation
- No update date — cards become stale after model updates
Model Cards for LLMs
Large language models require adaptations to the model card format. Key differences:
- Intended use is harder to bound: LLMs are general-purpose. Model cards must describe what use cases the model was optimised for and which high-risk use cases are explicitly out of scope (medical diagnosis, legal advice, crisis counselling).
- Performance metrics are multi-dimensional: Reporting a single accuracy metric is not meaningful. LLM cards report: benchmark results (MMLU, HumanEval, etc.), safety evaluations (refusal rates, toxicity scores), and alignment evaluation results.
- Known failure modes: Hallucination rates, calibration on factual questions, performance degradation for non-English languages, and susceptibility to known prompt injection patterns should be documented.
- Alignment and safety section: RLHF or RLAIF alignment methods used, red team testing performed, safety classifiers applied as guardrails.
- Usage restrictions: Terms of service restrictions that apply — which sectors or use cases require explicit permission or are prohibited (e.g., weapons development, surveillance, political disinformation).
Regulatory Requirements for Model Documentation
| Framework | Documentation requirement | Who must comply |
|---|---|---|
| EU AI Act (high-risk) | Technical documentation including model performance, training data, testing methodology, intended purpose, known limitations | Providers of high-risk AI systems (Annex III uses) |
| EU AI Act (GPAI) | Model cards or equivalent transparency document required for all general-purpose AI models released publicly | GPAI model providers above capability threshold |
| NIST AI RMF | AI Transparency documentation as part of GOVERN function; model documentation as part of MAP outputs | Voluntary — referenced in US federal procurement |
| ISO 42001 (Clause 8.7) | Information for AI systems: intended use, limitations, performance characteristics, user guidance | Organisations seeking ISO 42001 certification |
| FDA (AI/ML SaMD) | Software documentation requirements including algorithm description, performance on intended population, known limitations | AI-based medical device software in the US |
Keeping Model Cards Current
A model card created at initial deployment and never updated is a compliance liability. Model cards must be treated as living documents:
- Trigger updates: Model retrained or fine-tuned; new evaluation data available; new failure mode discovered in production; deployment context expands; regulatory requirements change
- Version the card: Each model version should have a corresponding model card version with changelog. Do not silently overwrite previous versions.
- Link to model registry: Model card should be accessible from the model registry entry — when a model is looked up, the card should be one click away
- Assign an owner: Designate a person responsible for keeping the card current — typically the model owner or AI product manager
Checklist: Do You Understand This?
- Name the nine standard sections of a model card and what each covers.
- Why is disaggregated performance the most important section of a model card?
- How does a model card for an LLM differ from one for a traditional classification model?
- Under the EU AI Act, which types of AI systems require model documentation? What must the documentation include?
- What triggers a model card update and who should own that responsibility?