| Myth | Reality |
|---|---|
| A model card is just a marketing one-pager describing what the model does. | A model card is a structured evidence document with nine required sections, including quantitative performance broken out by subgroup, that auditors treat as a compliance artifact, not a brochure. |
| System cards are just a longer version of a model card. | System cards describe an entire deployed product, including safeguards, red-teaming results, and how multiple models and guardrails interact. They answer a different question than a model card does. |
| Writing the documentation once at launch is enough to satisfy regulators. | Both the EU AI Act and NIST AI RMF expect documentation to be kept current across the system’s lifecycle, with version history and updates tied to retraining or monitoring findings. |
| Model cards are a purely voluntary best practice with no legal weight. | For high-risk systems under the EU AI Act, documentation meeting Article 11 and Annex IV requirements is a legal precondition for placing the system on the market, retained for ten years. |
The Origin of Model Cards: From a Research Paper to a Compliance Artifact
Model cards did not start as a regulatory requirement. They began as a proposal from a small group of researchers trying to solve a specific, narrower problem: trained machine learning models were shipping into law enforcement, medicine, education, and hiring pipelines with almost no accompanying documentation about how they were built, what they were tested on, or where they were known to fail.
Margaret Mitchell and coauthors published “Model Cards for Model Reporting” at the ACM Conference on Fairness, Accountability, and Transparency in January 2019. The paper proposed a short, standardized document to accompany every trained model, modeled loosely on the datasheets and nutrition labels used in other industries to communicate safety-relevant information in a consistent format. The authors specified nine sections: model details, intended use, factors, metrics, evaluation data, training data, quantitative analyses, ethical considerations, and caveats and recommendations.
What made the proposal durable was not novelty of format but the discipline it imposed. A model card forces a team to write down, in one place, the answers to questions that are otherwise scattered across Slack threads, internal wikis, and the memory of whichever engineer trained the model. When that engineer leaves the company, the model card is what remains. Seven years later, that same property is exactly what makes model cards useful to an external auditor who has never met anyone on the team.
Since 2019, the format has been adopted well beyond its research origins. Hugging Face made model cards a required field for every model uploaded to its hub. Google, Anthropic, and OpenAI publish model cards or their own variants for major releases. And, critically, regulators borrowed the concept almost wholesale: the documentation fields required under the EU AI Act’s Annex IV and the evidence categories described in the NIST AI Risk Management Framework map closely onto the nine original sections, even though neither document cites Mitchell et al. by name.
What a Model Card Actually Contains
A model card that would satisfy an auditor is longer and more specific than the lightweight cards popularized on model-sharing platforms. At minimum, it needs to answer the following, with evidence rather than assertions.
| Section | What goes in it | Why an auditor checks it |
|---|---|---|
| Model details | Architecture, version, training date, developer, license, and contact for questions | Establishes accountability and lets an auditor tie the artifact to a specific, reproducible version |
| Intended use | In-scope use cases, out-of-scope uses, and the target user population | Out-of-scope use is where most real-world harm originates, so auditors look for explicit exclusions |
| Training data | Data sources, collection method, preprocessing, known gaps or skew | Under the EU AI Act, data governance obligations attach directly to how training data was sourced and curated |
| Evaluation results | Performance metrics broken out by relevant subgroup, not just an aggregate score | An aggregate accuracy figure can hide large disparities across demographic or use-case subgroups |
| Limitations | Known failure modes, edge cases, and conditions under which performance degrades | Regulators treat an honest limitations section as evidence the provider actually tested the system |
| Ethical considerations | Foreseeable risks of misuse, fairness tradeoffs made during development, mitigations applied | Maps directly to the risk management documentation required by both the EU AI Act and ISO 42001 |
The most commonly skipped section, in practice, is evaluation results broken out by subgroup. It is easy to report a single accuracy or F1 number for the whole test set. It takes considerably more work to slice that same evaluation by age band, language, geography, or whatever protected or high-stakes category is relevant to the deployment context, and to report the disparities honestly even when they are unflattering. Auditors have learned to ask for the subgroup breakdown specifically because its absence is the single most reliable signal that a team evaluated the model superficially.
How System Cards Differ From Model Cards
A model card describes one artifact: a specific set of weights, trained on a specific dataset, evaluated against a specific benchmark suite. A system card describes something larger and messier: the product a user actually experiences, which is frequently composed of multiple models, a safety filter layered on top, retrieval or tool-calling infrastructure, rate limits, monitoring, and human escalation paths, all working together.
Frontier labs adopted the system card format specifically because a single model card could not capture this composition. When OpenAI, Anthropic, or Google DeepMind release a flagship model, the accompanying system card covers red-teaming results across categories like cyber-offense uplift, biological and chemical risk, persuasion and manipulation, and autonomous replication attempts; the mitigations applied at the product layer rather than the model layer; and the governance process that decided the system was safe enough to ship. None of that fits inside the nine sections of a classic model card, because none of it belongs to a single model.
| Dimension | Model card | System card |
|---|---|---|
| Scope | One trained model or model version | An entire deployed product, often multiple models plus guardrails |
| Primary audience | Downstream developers reusing the model | Regulators, auditors, the public, and internal safety governance boards |
| Typical content | Architecture, training data, evaluation metrics, limitations | Red-teaming outcomes, deployment safeguards, capability thresholds, incident history |
| Update cadence | Tied to model retraining or fine-tuning | Tied to product changes, new safeguards, or newly discovered risks |
| Who typically publishes one | Any team releasing a trained model | Primarily frontier labs and providers of high-risk systems under regulation |
Documentation layers in a deployed AI product
A system card sits above one or more model cards, adding product-level safeguards, red-teaming outcomes, and governance sign-off that no single model card can capture on its own.
This layering matters for anyone assembling documentation for a real product. If your system routes a query through a classifier, then a retrieval step, then a generation model, then a moderation filter, a single model card for the generation model tells an auditor almost nothing about whether the overall product is safe. You need a system card that explains how the pieces interact, what happens when one component fails, and what testing was done on the assembled pipeline rather than on each component in isolation.
What Auditors and Regulators Actually Expect to See
The EU AI Act’s technical documentation requirements, set out in Article 11 and detailed in Annex IV, apply to providers of high-risk AI systems and must be prepared before the system is placed on the market. Annex IV specifies roughly nine categories of required content: a general description of the system, details of its development and design, the monitoring and control measures in place, performance metrics, the risk management process, a log of lifecycle changes, the standards applied, the EU declaration of conformity, and the post-market monitoring plan. That documentation must be kept up to date and retained for ten years from the date the system is placed on the market. Small and medium enterprises are permitted to submit a simplified version using a template the European Commission is expected to establish, but the substance of what must be covered does not change, only the level of detail.
The NIST AI Risk Management Framework takes a different regulatory posture, since it is voluntary in the United States rather than a hard legal mandate, but its expectations converge with the EU AI Act on the substance. NIST’s Map, Measure, Manage, and Govern functions all assume an organization can produce documentation showing what risks were identified, how they were measured, and what governance decisions followed. In April 2026, NIST released a concept note for an AI RMF profile focused on trustworthy AI in critical infrastructure, signaling that the documentation bar for high-consequence deployments is still rising rather than settling.
| Framework | Legal status | Core documentation ask |
|---|---|---|
| EU AI Act Article 11 / Annex IV | Mandatory for high-risk systems from August 2026 | Nine-category technical file retained for ten years, including risk management and post-market monitoring |
| NIST AI RMF | Voluntary in the US, referenced by many procurement contracts | Documented evidence across Map, Measure, Manage, Govern functions |
| ISO/IEC 42001 | Voluntary, certifiable management system standard | AI management system documentation, similar in spirit to ISO 27001 for security |
Where teams most often go wrong is treating model cards as a one-time deliverable produced at launch and then forgotten. Both regimes described above expect documentation to move with the system. If the model is retrained, if new evaluation data becomes available, or if a monitoring system flags a performance drift, the documentation of record has to reflect that. An auditor who finds a model card dated two years before the system’s most recent retraining event will reasonably conclude that the organization’s compliance posture is stale, regardless of how good the original document was.
Building a Documentation Pipeline That Survives an Audit
The organizations that handle audits smoothly tend to share one practice: they stopped treating model cards and system cards as documents written by hand at the end of a project, and started generating them as a byproduct of the ML pipeline itself. Evaluation results get pulled automatically from the test harness. Training data provenance gets logged at ingestion time rather than reconstructed later from memory. Version history is tied to the model registry rather than a separate changelog someone forgets to update.
This shift matters because manually assembled documentation degrades in exactly the way you would expect: it is accurate at the moment it is written and increasingly wrong afterward. Automated generation does not eliminate the need for human judgment, especially in the ethical considerations and limitations sections, which require someone to actually think about foreseeable misuse rather than fill in a template. But it does mean the factual sections, architecture, training data statistics, evaluation metrics, stay synchronized with the actual deployed system, which is precisely what an auditor is checking for.
- Wire evaluation metric extraction directly into the CI pipeline that runs before a model is promoted to production.
- Store training data lineage as structured metadata at ingestion, not as a narrative written after the fact.
- Version the model card alongside the model artifact in the same registry, so the two can never silently drift apart.
- Assign a named, accountable owner for the ethical considerations and limitations sections, since those cannot be automated.
- Schedule a mandatory documentation review at every retraining event, not just at initial launch.
Common mistake
Treating the model card as a finished artifact once it clears legal review at launch. Auditors specifically look for a mismatch between the documented training data cutoff or evaluation date and the model’s actual deployment history; a card that has not been touched since the original release is one of the fastest ways to trigger deeper scrutiny during an audit, even when nothing else is wrong.
What worked
Teams that pass audits with the least friction generally maintain a single living system card referencing individual model cards by version, rather than duplicating evaluation details across documents. When a model is retrained, only its model card and the reference in the system card need updating, which keeps the documentation internally consistent and dramatically reduces the reviewer’s cross-checking burden.
- Subgroup evaluationReporting accuracy or error rates broken out by demographic or use-case subgroup, not just an aggregate figure, which is the detail auditors ask for most and teams skip most often.
- Out-of-scope useExplicitly documenting what the model was not designed or tested for, since undocumented misuse outside intended scope is where much real-world harm originates.
- Document versioningTying the model card version to the exact model artifact version in the registry, so an auditor can confirm the documentation describes the system actually in production.
- Post-market monitoring linkConnecting the model card to live monitoring data so documented limitations can be checked against observed real-world performance over time.
- Named accountable ownerAssigning a specific person, not a team alias, as responsible for keeping the ethical considerations section current as the deployment context changes.
Glossary
- Model card
- A standardized document describing a single trained model’s intended use, training data, evaluation results, and limitations, originally proposed by Mitchell et al. in 2019.
- System card
- A document describing an entire deployed AI product, including how multiple models, safeguards, and monitoring interact, used primarily by frontier labs for major releases.
- Annex IV
- The section of the EU AI Act that specifies the nine mandatory categories of technical documentation required for high-risk AI systems.
- NIST AI RMF
- The National Institute of Standards and Technology’s voluntary AI Risk Management Framework, organized around the Map, Measure, Manage, and Govern functions.
- Post-market monitoring
- The ongoing collection of real-world performance data after a system is deployed, required under the EU AI Act to detect drift or emerging risks.
- Subgroup evaluation
- Performance metrics reported separately for distinct demographic or use-case populations, rather than as a single aggregate score.
Key Takeaways
- Model cards originated with Mitchell et al.’s 2019 paper and specify nine sections: model details, intended use, factors, metrics, evaluation data, training data, quantitative analyses, ethical considerations, and caveats and recommendations.
- A model card documents one trained model; a system card documents an entire deployed product, including how multiple models and safeguards interact.
- Frontier labs use system cards for major releases to cover red-teaming results, capability thresholds, and deployment safeguards that no single model card can capture.
- The EU AI Act’s Article 11 and Annex IV require a nine-category technical file for high-risk systems, retained for ten years and kept up to date.
- The NIST AI RMF is voluntary in the US but converges with EU expectations on the substance of what documentation must show.
- The most commonly skipped element is subgroup-level evaluation data, which auditors specifically ask for because its absence signals superficial testing.
- Documentation that is generated automatically from the ML pipeline stays synchronized with the deployed system; manually assembled documentation reliably goes stale.
FAQs
What is the difference between a model card and a system card?
A model card documents a single trained model, its architecture, training data, evaluation results, and limitations. A system card documents an entire deployed product, which may include several models plus safety filters, monitoring, and escalation paths, and explains how those pieces work together as a whole.
Who created the model card format?
Margaret Mitchell and coauthors introduced model cards in the paper “Model Cards for Model Reporting,” presented at the ACM Conference on Fairness, Accountability, and Transparency in January 2019, proposing nine standardized sections for documenting trained models.
Are model cards legally required?
For high-risk AI systems under the EU AI Act, documentation covering equivalent content is legally required under Article 11 and Annex IV. Outside that regulatory scope, model cards remain a voluntary but widely adopted best practice recommended by frameworks like NIST AI RMF and ISO 42001.
What does the EU AI Act require in technical documentation?
Annex IV specifies roughly nine categories: a general system description, development and design details, monitoring and control measures, performance metrics, risk management process, lifecycle change logs, applied standards, the declaration of conformity, and a post-market monitoring plan, retained for ten years.
Why do frontier labs publish system cards instead of just model cards?
Frontier deployments typically combine multiple models with safety filters, tool access, and monitoring infrastructure. A model card describing just the base model would miss red-teaming results, deployment safeguards, and governance decisions that apply to the product as a whole, so labs publish a system card to cover that broader scope.
What is the most commonly missing section in model cards submitted for audit?
Evaluation results broken out by demographic or use-case subgroup are the most commonly missing detail. Teams frequently report a single aggregate accuracy figure, which can conceal significant performance disparities that auditors specifically look for.
How often should a model card be updated?
A model card should be updated whenever the underlying model is retrained, fine-tuned, or re-evaluated, and reviewed at minimum whenever post-market monitoring surfaces new limitations or performance drift, so the documentation never falls out of sync with the deployed system.
Does NIST AI RMF require a specific document format like the EU AI Act does?
No. NIST AI RMF is organized around functions, Map, Measure, Manage, and Govern, rather than a fixed document template, and is voluntary in the United States. Many organizations satisfy it using the same evidence they compile for a model or system card, mapped to the relevant function.
References
- Mitchell, M., et al. “Model Cards for Model Reporting.” Proceedings of the ACM Conference on Fairness, Accountability, and Transparency (FAT* 2019).
- European Union. “Article 11: Technical Documentation.” EU Artificial Intelligence Act, artificialintelligenceact.eu.
- European Union. “Annex IV: Technical Documentation.” EU Artificial Intelligence Act.
- National Institute of Standards and Technology. “AI Risk Management Framework (AI RMF 1.0).”
- National Institute of Standards and Technology. Concept note for an AI RMF Profile on Trustworthy AI in Critical Infrastructure, April 2026.
- International Organization for Standardization. “ISO/IEC 42001: Artificial Intelligence Management System.”
For related coverage on this site, see how documentation obligations connect to broader compliance work in EU AI Act compliance, how internal oversight bodies decide what gets documented in building an AI governance committee, and how model cards feed into AI risk management frameworks compared. Evaluation results referenced in a model card are typically produced using the same processes covered in LLM evaluation frameworks, and frontier-lab system cards draw heavily on the methods described in frontier model safety evaluations explained for non-research audiences. Documentation also plays directly into the disclosure practices covered in AI transparency reporting.
