Skip to main content
Bureau of AI
Category: Content Transparency & Labelling

Model Cards

Also known as: Model Card, Model Card Report
Simply put

A model card is a short document that accompanies a trained machine learning model and provides key information about how the model was designed, evaluated, and intended to be used. Its purpose is to increase transparency by communicating this information in a structured, accessible format. Model cards are commonly associated with responsible AI practices, though their exact content and format can vary.

Formal definition

A model card is a short, structured document accompanying a trained machine learning model that summarizes benchmarked evaluation results across a variety of conditions, along with the intended context of use for the model. As commonly described, model cards function as a transparency artifact, capturing information about how a model was designed and evaluated to support informed deployment decisions. Note that model cards are a documentation practice rather than a binding regulatory requirement, and specific templates, required fields, and level of detail differ across organizations and frameworks; the evidence here does not establish a single authoritative standard for their content.

Why it matters

Model cards address a persistent gap in AI deployment: the people who decide whether and how to use a model often lack structured information about how it was designed, evaluated, and intended to be used. By packaging benchmarked evaluation results and intended-use context alongside the model itself, a model card supports more informed deployment decisions and helps downstream users understand a model's limitations before applying it in contexts for which it may not be suited. In this sense, model cards are commonly positioned as a transparency artifact within responsible AI practices.

For governance and model risk functions, model cards can serve as supporting documentation that feeds into broader oversight and control processes, but they should not be mistaken for those processes themselves. A model card summarizes information about a model; it does not by itself constitute independent validation, ongoing monitoring, or a completed risk assessment. Treating a model card as evidence that a model has been adequately reviewed, rather than as one input among several, is a common pitfall for professionals who conflate documentation with control.

It is important to note that model cards are a documentation practice rather than a binding regulatory requirement, and the evidence here does not establish a single authoritative standard for their content, required fields, or level of detail. Organizations and frameworks vary in how they define and populate model cards, so their usefulness for compliance or audit purposes depends heavily on the rigor and completeness that a given organization applies.

Who it's relevant to

Model Risk Managers and Validators
Model cards can serve as an input to model risk management processes by summarizing how a model was designed and evaluated and its intended use context. They should be treated as supporting documentation rather than a substitute for independent validation, ongoing monitoring, or a completed risk assessment. Validators should assess the completeness and rigor of a model card rather than assume it reflects a standardized or authoritative format.
Data Scientists and ML Engineers
Practitioners who build and evaluate models may author model cards to communicate benchmarked evaluation results and intended-use context to downstream users. Because there is no single authoritative standard established here, teams typically decide which fields and level of detail are appropriate for their organization and use case.
AI Governance and Compliance Professionals
Model cards are commonly associated with responsible AI and transparency practices and can support governance objectives by documenting model design, evaluation, and intended use. They are a documentation practice rather than a binding regulatory requirement, so their value for oversight depends on the rigor an organization applies and on how they integrate with broader accountability structures.
Auditors and Reviewers
For those reviewing AI systems, a model card can provide a structured starting point for understanding how a model was designed, evaluated, and intended to be deployed. Reviewers should verify what a specific model card actually documents, recognizing that content and format vary across organizations and that a model card alone does not evidence that adequate review or controls were performed.

Inside Model Cards

Model Details
Basic descriptive information about the model, typically including its name, version, developer or responsible party, date, model type or architecture at a high level, and intended release status. This section establishes provenance and accountability but does not itself constitute a governance control.
Intended Use and Out-of-Scope Use
A statement of the use cases the model was designed for, the intended users, and, importantly, uses the developer considers inappropriate or unsupported. Clarifying out-of-scope use is often emphasized because misapplication is a common source of downstream harm.
Training Data and Evaluation Data
Descriptions of the datasets used to develop and to assess the model, including, where disclosed, their sources, composition, and known limitations. The level of detail varies widely and is frequently constrained by confidentiality or proprietary considerations.
Performance Metrics and Evaluation Results
Reported measures of how the model performs, ideally disaggregated across relevant subgroups or conditions rather than only in aggregate. These reflect performance at the time of evaluation and should not be read as guarantees of behavior in deployment.
Ethical Considerations, Limitations, and Risks
A narrative of known limitations, potential harms, fairness or bias concerns identified during development, and caveats about generalization. This section documents awareness of risk; it does not by itself measure, monitor, or control that risk.
Caveats and Recommendations
Additional guidance for users, including conditions under which results may be unreliable and suggestions for responsible deployment or further testing. The specific structure of a model card is not standardized across all frameworks and can be adapted.

Common questions

Answers to the questions practitioners most commonly ask about Model Cards.

Are model cards a regulatory requirement that satisfies compliance obligations?
No. Model cards are a documentation practice, not a legal requirement in themselves. While some frameworks and internal governance policies may reference or encourage structured model documentation, a model card is not universally mandated, and producing one does not by itself demonstrate compliance with any specific regulation. Whether a model card contributes to meeting an obligation depends on the applicable framework, jurisdiction, and how the documentation is used within broader governance processes.
Does completing a model card mean a model has been validated or that its risks have been managed?
No. A model card documents information about a model, such as its intended use, characteristics, and reported performance, but documentation is distinct from validation and from risk management. Validation typically involves independent assessment of whether a model is sound and fit for purpose, while a model card is a descriptive artifact. A model card may support these activities by recording relevant information, but it does not substitute for them and does not on its own reduce or control model risk.
Who is typically responsible for creating and maintaining a model card?
Responsibility varies by organization, but model card authorship commonly involves the development team that builds or documents the model, with input or review from other functions depending on the governance structure in place. In organizations that apply a lines-of-defense model, development activity is often associated with the first line, while review or challenge may involve other functions. Maintenance responsibility should be assigned explicitly, since a model card can become inaccurate as a model or its use changes.
What information is commonly included in a model card?
As commonly described, a model card may cover items such as the model's intended and out-of-scope uses, its inputs and outputs, reported performance across relevant conditions or subgroups, known limitations, and considerations relevant to its deployment context. The specific fields are not standardized across all organizations, so the exact contents typically depend on internal templates, the model's purpose, and any applicable framework the organization chooses to follow.
How should a model card be kept current over a model's lifecycle?
Because a model card describes a model at a point in time, organizations typically tie updates to defined triggers, such as retraining, changes in intended use, or observed changes in behavior. Establishing an owner, a review cadence, and version control helps prevent the card from diverging from the deployed model. Note that keeping a model card current is a documentation practice and is separate from ongoing monitoring for performance degradation, which is a distinct activity.
How does a model card relate to other governance and risk documentation?
A model card is generally one component within a broader documentation set that may include validation reports, risk assessments, and monitoring records. It is often used as a concise reference describing the model itself, whereas other documents may address independent assessment, control effectiveness, or oversight. Treating the model card as a summary artifact rather than a complete record helps avoid the pitfall of assuming a single document captures all governance and risk management information.

Common misconceptions

A model card is a form of model validation or a substitute for independent review.
A model card is primarily a documentation and transparency artifact, typically produced by or for the model's developers. It is distinct from validation, which involves independent assessment of whether a model is conceptually sound and fit for purpose. A model card may support validation and governance processes but does not replace them.
A completed model card demonstrates that a model is fair, unbiased, or compliant with a given regulation.
A model card documents what was tested and known at a point in time, including disclosed limitations and fairness considerations. It does not certify fairness or eliminate bias, and it does not by itself establish compliance with any specific legal or regulatory instrument. Disclosure of a limitation is not the same as remediation of it.
Model cards follow a single mandatory, standardized format.
The concept originates as a proposed documentation practice, and the structure, depth, and content commonly vary by organization, sector, and framework. There is no universal template that applies across all contexts, and the information disclosed is often shaped by proprietary or confidentiality constraints.

Best practices

Clearly document both intended use and out-of-scope use, since misapplication of a model to unsupported use cases is a frequent source of harm.
Report performance metrics disaggregated across relevant subgroups or conditions where feasible, rather than relying solely on aggregate results.
Treat evaluation results as point-in-time findings and pair the model card with ongoing monitoring processes to detect performance degradation after deployment.
State known limitations, data constraints, and residual risks explicitly, and avoid implying that documenting a limitation resolves it.
Version the model card alongside the model so that changes in the model, data, or evaluation are traceable over time.
Use the model card to support, not substitute for, independent validation and broader governance and model risk management processes.