A model card is a structured document that discloses what an AI model does, how it was built and tested, and where it should not be used. AI model documentation standards exist because regulators, auditors, and customers can no longer take a vendor's word for a model's behavior. They expect a record they can inspect, independent of the people who built the system.

The concept originated in a 2019 research paper, "Model Cards for Model Reporting," and has since moved from an academic proposal into standard industry practice. What started as a template for disclosing a model's intended use and limitations is now referenced, directly or indirectly, in procurement questionnaires, internal audit checklists, and emerging AI regulation. Understanding what belongs in one, and why regulators increasingly expect it, is now a baseline competency for anyone responsible for AI governance.

What Is a Model Card?

A model card is a short, structured document attached to a specific machine learning model that discloses its intended use, training data, performance characteristics, limitations, and ethical considerations. It is written for a mixed audience: the engineers who built the model, the teams deploying it, and increasingly the regulators or auditors reviewing it after the fact.

The defining feature of a model card is that it documents one specific model, at one point in time, rather than describing AI practices in general terms. A model card for a resume-screening model and a model card for a fraud-detection model will share a common structure but contain entirely different content, because the risks, data, and appropriate use cases differ.

This specificity is what separates a model card from a general AI policy. A policy states what an organization intends to do across all its AI systems. A model card states what is actually true of one system: what it was trained on, how it performed against defined metrics, and what happens when it is used outside its intended scope.

Why Do Regulators Increasingly Expect Model Documentation?

Regulators expect model documentation because a model's behavior cannot be verified from the outside without a record of what went into it and how it was tested. Without that record, a regulator, auditor, or affected individual has no way to assess whether a model was fit for its purpose before it caused harm.

This shift shows up across several regulatory tracks at once, not just one jurisdiction. The EU AI Act requires providers of high-risk AI systems to maintain technical documentation under Article 11, covering the system's design, development process, and performance data, before the system can be placed on the market. The NIST AI Risk Management Framework treats documentation as a core output of its "map" and "measure" functions, on the reasoning that risk cannot be managed if it is not first recorded. ISO/IEC 42001 requires organizations to maintain documented information demonstrating that AI-specific controls, including those covering data quality and system transparency, actually operate as designed.

None of these frameworks were written around the term "model card" specifically. But the underlying expectation is the same across all three: a named, retrievable, model-specific record of what the system does and how it was evaluated, created at the time the work happened rather than reconstructed afterward. A model card is the practical artifact that satisfies that expectation at the level of an individual model.

There is also a liability dimension driving adoption. When a model produces a harmful or discriminatory outcome, the organization's first line of defense is showing the risk was foreseeable, tested for, and disclosed, or that it was not reasonably foreseeable given the evidence available at the time. A model card, maintained honestly and updated as the model changes, is the primary evidence for either claim.

What Sections Should a Model Card Contain?

A complete model card should let a reader who has never seen the model understand what it does, how confident to be in its outputs, and where its use should stop. At minimum, that document should include:

  • Model overview: name, version, type of model, developer or vendor, release date, and a plain-language description of what the model does.
  • Intended use: the specific tasks and contexts the model is designed for, and explicitly, the use cases it is not designed or approved for.
  • Training data summary: source and general composition of the training data, known gaps or skews in that data, and any sensitive data categories involved, without necessarily disclosing proprietary datasets in full.
  • Performance metrics: quantitative results against defined benchmarks, broken out by relevant subgroup where the model's output affects individuals, not just an aggregate accuracy figure.
  • Evaluation methodology: how the model was tested, including the test data used and whether that data was independent of the training set.
  • Limitations and known failure modes: circumstances under which the model is known to underperform or behave unpredictably, stated as specifically as the evaluation evidence allows.
  • Ethical considerations: foreseeable risks of harm, bias, or misuse, and what mitigations, if any, were applied.
  • Fairness and bias assessment: results of testing across protected classes or affected groups, where the model informs decisions about individuals.
  • Recommended and out-of-scope uses: a direct statement distinguishing appropriate deployment contexts from ones the developer explicitly warns against.
  • Maintenance and update history: version changes, retraining events, and the date the card was last reviewed.

A card missing a section entirely is a documentation gap. A card where every section is populated with generic, boilerplate language that would apply equally to any model is a different, more common gap, and one that is harder to catch without close reading.

How Does a Model Card Differ From Broader AI Governance Documentation?

A model card documents a single model. It sits inside a larger documentation structure that also includes organization-level policy, risk assessments, and audit records, and it should not be expected to carry weight those other documents are responsible for.

An AI governance framework sets the rules an organization applies across every model it builds or buys: how risk is tiered, who approves deployment, what monitoring is required. A model card is where those rules get applied to one specific system. The framework says bias testing is required for models affecting individual outcomes. The model card is where the results of that specific test, for that specific model, get recorded.

This layering matters because organizations sometimes treat a well-written governance policy as a substitute for model-level evidence, or treat a set of thorough model cards as sufficient without any organization-wide framework connecting them. Both are incomplete. A regulator or auditor reviewing an AI system typically wants to see both layers: the policy explaining why a control exists, and the model card showing the control was actually applied to the system in question.

Who Should Be Responsible for Writing and Maintaining Model Cards?

Model cards are most reliable when the person closest to the model's technical development drafts the initial content, and someone independent of that development reviews it before it is finalized. A model card written and approved by the same individual with no separation of duties tends to understate limitations, not out of dishonesty, but because the person who built a system is rarely its most objective reviewer.

A workable structure typically assigns:

  • The model developer or data science lead, who drafts the technical sections: training data, methodology, and performance metrics.
  • A governance or risk reviewer, independent of development, who checks the card against the organization's risk-tiering criteria and challenges vague or missing limitation statements.
  • A business owner, who confirms the intended use section accurately reflects how the model will actually be deployed, not just how it was originally conceived.
  • A named individual accountable for keeping the card current, since a model card frozen at initial release becomes actively misleading once the model is retrained or its use case expands.

Smaller organizations without headcount to separate these roles fully should state that constraint openly rather than implying an independence that does not exist. An honest note about limited separation of duties reads far better under review than a document that quietly assumes no one will ask.

How Should Model Cards Handle Third-Party and Foundation Models?

When a model is licensed from a vendor rather than built internally, the vendor's own model card is a reference document, not a substitute for the deploying organization's own record. The vendor's card describes the base model in general terms. It cannot describe how that model performs inside a specific organization's prompts, retrieval pipeline, fine-tuning, or guardrails.

An organization deploying a third-party or foundation model should maintain its own supplementary record covering:

  • The vendor's disclosed model card, retained as a baseline reference, including any stated limitations or restricted uses.
  • The organization's own evaluation of the deployed configuration, including any prompt engineering, retrieval-augmented generation components, or fine-tuning applied on top of the base model.
  • A defined process for re-evaluating the deployment when the vendor updates the underlying model, since a silent version change can shift behavior without any visible change on the deploying organization's side.
  • Contractual terms addressing the vendor's obligation to disclose material model changes or retraining events.

Treating a vendor's published model card as sufficient documentation for the deployed system is one of the more common gaps found in AI-specific reviews, precisely because it leaves the organization's actual configuration unverified and undocumented.

What Makes a Model Card Credible Rather Than Just Present?

A credible model card is specific, current, and honest about limitations. A model card that exists but fails those three tests provides false comfort rather than genuine assurance, and a careful reviewer will notice the difference quickly.

Practical checks worth running before a model card goes into a governance file or a regulatory submission:

  • Specificity test: could this card, unedited, apply to a different model built by a different team? If yes, it is not documenting this model.
  • Currency test: does the card's last-updated date match the model's actual current version, not an earlier release?
  • Limitation test: does the card name concrete failure modes and unsuitable use cases, rather than a generic disclaimer that all models have limitations?
  • Independence test: did anyone other than the model's builder review the card before it was finalized?

A model card that passes these four checks functions as evidence. One that does not is closer to marketing copy with a technical-sounding structure, and reviewers who handle AI documentation regularly can usually tell within a few paragraphs.

Key Takeaways

  • A model card documents one specific model at one point in time: intended use, training data, performance, limitations, and ethical considerations, not general AI practices.
  • Regulators including under the EU AI Act, and frameworks including NIST AI RMF and ISO/IEC 42001, converge on the same underlying expectation: a retrievable, model-specific record created as work happens, not reconstructed afterward.
  • A complete model card includes overview, intended use, training data summary, performance metrics, evaluation methodology, limitations, ethical considerations, fairness testing, and maintenance history.
  • Third-party and foundation models require the deploying organization's own supplementary record. A vendor's model card is a reference, not evidence of the deployed configuration's actual performance.
  • Test your own model cards for specificity, currency, named limitations, and independent review before a regulator, auditor, or customer does.

Building the governance framework that makes disclosures like this consistent, defensible, and audit-ready across an organization's full AI inventory, alongside global regulation such as the EU AI Act, NIST AI RMF, and ISO/IEC 42001, is core ground covered in AICA's Certified Chief AI Governance Officer (CCAIGO) certification.