Template preview (excerpt)
Scroll to see all columns
Section 2: Intended Use
2.1 Primary Use Cases
| Use Case | Description | User Type |
|---|---|---|
| [Primary use case 1] | [Detailed description] | [Who uses it] |
2.3 Out-of-Scope Uses
| Use Case | Reason Not Supported |
|---|---|
| [Prohibited use case 1] | [Why inappropriate: data limitations, ethical concerns, etc.] |
Section 7: Limitations
7.2 Known Failure Modes
| Failure Mode | Trigger Conditions | Detection | Response |
|---|---|---|---|
| [Failure mode 1] | [What causes this failure] | [How to detect] | [What to do] |
View the worked example
Out-of-Scope Uses:
| Use Case | Reason Not Supported |
|---|---|
| Sole decision-making for credit | Model designed as decision support only; requires human review |
| Use on populations not in training data | Performance not validated; may produce unreliable results |
| Real-time safety-critical applications | Latency requirements not validated for this use case |
Before you begin
For compliance, risk, product, and ML ops teams shipping agentic Processes into regulated environments.
Model cards are standardized documentation for AI models. Originally proposed by researchers at Google in 2019, they have become an industry best practice for communicating what a model does, how it performs, and what its limitations are.
For organizations subject to the EU AI Act, model cards help satisfy transparency requirements under Article 13 and contribute to the technical documentation required by Annex IV.
When to use this resource
- You are deploying ML models and need standardized documentation for technical reviewers.
- You need to satisfy EU AI Act transparency requirements (Article 13) or contribute to Annex IV documentation.
- You want to communicate model capabilities, limitations, and ethical considerations to deployers and users.
Information to gather
- Model architecture, version, and training provenance details.
- Intended use cases and explicit out-of-scope uses.
- Training and evaluation data documentation with known issues.
- Performance metrics (overall + disaggregated) with confidence intervals.
- Fairness analysis results and ethical considerations.
- Known limitations, failure modes, and boundary conditions.
Review checklist
Use these checks in the review with your system owner. Confirm the applicable requirements and attach evidence for the decisions your team makes.
- Model identification includes version, architecture, lineage, and development provenance.
- Intended use defines primary use cases, intended users, and explicitly states out-of-scope uses.
- Training data is documented with sources, characteristics, preprocessing, and known quality issues.
- Performance metrics include overall and disaggregated results with confidence intervals.
- Ethical considerations cover fairness metrics, bias testing, and protected characteristics.
- Limitations are comprehensively documented including failure modes and boundary conditions.
- Recommendations provide actionable deployment, monitoring, and maintenance guidance.
Operating controls and evidence
- Govern
Version-controlled model cards linked to model registry and deployment pipelines.
Approval gates that verify model card completeness before production deployment.
- Assure
Automated capture of performance metrics, drift signals, and fairness indicators.
Disaggregated performance monitoring across protected groups and edge conditions.
- Prove
Model cards linked to evaluation artifacts, training data lineage, and approval records.
Evidence bundles that tie documentation claims to runtime performance data.
Questions about this resource
What is the difference between a model card and a system card?
A model card documents a single ML model. A system card documents a complete AI system that may include multiple models, integrations, and Processes. Model cards are building blocks for system cards.
Are model cards required by the EU AI Act?
The EU AI Act does not explicitly mandate model cards, but the information they contain is required in various forms throughout the compliance framework, particularly for Article 13 transparency and Annex IV technical documentation.
How often should model cards be updated?
Update when the model is retrained, performance characteristics change materially, new limitations are discovered, or intended use cases change.
What should I include in disaggregated performance?
Report performance across relevant subgroups to reveal disparities. Subgroups should include protected characteristics where applicable, as well as conditions that affect model behavior.
How do I handle limitations I discover after deployment?
Document newly discovered limitations immediately, update the model card, and communicate to deployers. Connect limitations to your monitoring and incident response processes.
What do reviewers look for in model cards?
Comprehensive limitations (not just favorable metrics), disaggregated performance, clear intended vs out-of-scope uses, and traceability to evaluation artifacts and training data.
Download file language: English