Model Cards Explained: What They Are and Why They Matter

Every time you buy medicine, you get a leaflet: what it is, what it is for, the dosage, the side effects, when not to use it. Now imagine deploying a machine learning model that screens job applicants or approves loans — with no equivalent leaflet. For years, that was normal. Model cards are the industry’s attempt to fix it.

A model card is a short document that accompanies a machine learning model, describing what the model does, how it was built, how it performs, and where its limits are. The concept was proposed by Google researchers Timnit Gebru and colleagues in a 2018 paper, and it has since become one of the most widely adopted transparency practices in AI.

This guide explains what model cards contain, who writes them, and why they matter — for builders, buyers, and regulators alike. For the governance context they serve, see my overview of AI governance.

Table of Contents

• The Idea in One Paragraph
• What Goes Into a Model Card
• Who Writes Them and When
• A Walkthrough Example
• Model Cards vs Neighboring Documents
• Common Weaknesses
• How Buyers Use Them
• Model Cards in the Generative AI Era
• Frequently Asked Questions

The Idea in One Paragraph

Machine learning models are opaque by default: even their creators cannot always explain a specific decision. A model card does not solve that, but it documents everything around the model that can be known — its purpose, its training data, its test results broken down by group, its limitations, and its ethical considerations. The goal is that anyone considering using the model — a product team, a customer, an auditor — can make an informed decision without reverse-engineering it.

What Goes Into a Model Card

The original proposal suggests nine sections. In practice, good model cards cover:

Model details. Name, version, date, type (e.g., transformer classifier), where to find it, who built it, and contact information. Boring and essential.

Intended use. What the model is for — and just as importantly, what it is not for. “Intended for English-language customer support triage; not intended for medical or legal decisions.” Out-of-scope uses are where harm usually happens.

Factors. The variables that could affect performance: demographic groups, languages, input types, environmental conditions. This section forces the team to think about who might be underserved.

Metrics. How performance was measured and what the numbers are — broken down by the factors above, not just reported as a single overall score. A model that is 95% accurate overall but 70% accurate for one group has a story the headline number hides.

Evaluation data. What datasets were used for testing, and how they relate to the training data. Testing on training data is a classic error this section exposes.

Training data. What the model learned from: sources, size, preprocessing, known gaps. You do not need to publish the data itself, but you should describe it honestly.

Quantitative analyses. The actual results: performance by group, robustness tests, threshold analysis. Charts help.

Ethical considerations. Known risks, sensitive applications, potential misuses, and mitigations. This is where the team shows its work on the hard questions.

Caveats and recommendations. Practical guidance: when to trust the model, when to add human review, when not to deploy it at all.

Who Writes Them and When

Ideally, the team that built the model writes the card — they know the most. In practice:

• Model developers draft it during development, when the details are fresh.
• A reviewer (product manager, responsible-AI lead) checks it for honesty and completeness.
• It ships with the model — published in the model repository (Hugging Face popularized this; thousands of models there now carry cards).
• It gets updated with each significant model version. A card describing v1 while the team ships v4 is worse than useless — it is misleading.

For procured models, the vendor should provide the card. “We don’t have one” is useful information for a buyer — it tells you something about the vendor’s maturity.

A Walkthrough Example

Imagine a sentiment-analysis model for product reviews. A good card would say:

• Details: “review-sentiment-v2, transformer classifier, released March 2025, built by the NLP team.”
• Intended use: “Classifying English product reviews as positive/negative/neutral for dashboard analytics. Not for hiring, lending, or any consequential decision.”
• Factors: “Evaluated on reviews across product categories; performance measured separately for short vs. long reviews.”
• Metrics: “Overall F1 0.91; F1 0.84 on reviews under 10 words. Known degradation on sarcasm.”
• Training data: “2M reviews from 2022-2024, English only, deduplicated, PII scrubbed.”
• Ethical considerations: “Sarcasm and cultural idiom cause systematic errors; human review recommended before using outputs in customer-facing responses.”
• Caveats: “Do not use for languages other than English; retrain if review language distribution shifts.”

Notice what this gives a potential user: enough to decide whether the model fits, where it will struggle, and what precautions to take. That is the whole point.

Model Cards vs Neighboring Documents

The documentation ecosystem has several related artifacts — do not confuse them:

• Model card: about one specific model. What it is and how it behaves.
• Datasheet for datasets: about the training data. Where it came from, how it was collected, its limitations. (Proposed by the same research community.)
• System card: about the deployed system around the model — the UI, the safeguards, the monitoring. Meta publishes these for its AI systems.
• AI FactSheet / supplier declaration: vendor-facing summaries for procurement, often mapping to regulatory requirements.

A mature organization produces all of them for significant systems. The model card is the most common starting point.

Common Weaknesses

Model cards are only as good as their authors. Typical failures:

• Marketing copy. Cards that read like product brochures — all strengths, no limitations. A card with no limitations section is a red flag.
• Stale cards. Written once at launch, never updated. Version drift makes them misleading.
• Missing disaggregation. A single overall accuracy number with no breakdown by group. This defeats a core purpose.
• Vague training data. “Trained on publicly available data” tells the reader nothing.
• Nobody reads them. Cards buried in a repo with no link from the product documentation might as well not exist.

How Buyers Use Them

If you are evaluating an AI vendor, ask for the model card early. Then:

1. Check intended use against your use case. Mismatches are disqualifying.
2. Read the limitations first, not the metrics. Limitations tell you where you will need safeguards.
3. Look for disaggregated results. If the card only reports overall numbers, ask why.
4. Check the date and version. Make sure the card matches the model you would actually receive.
5. Treat absence as signal. No card, no transparency culture. Price that into your decision.

Understanding how AI models are trained helps you evaluate the training-data sections critically, and surveying AI tools on the market shows you which vendors publish cards and which do not.

Model Cards in the Generative AI Era

The original 2018 model card format assumed a classifier: fixed inputs, fixed outputs, measurable accuracy. Generative models broke those assumptions, and the documentation practice has had to stretch to keep up.

A large language model does not have “accuracy” in any single sense — it writes, codes, summarizes, reasons, and role-plays, each with different failure modes. So generative-era model cards report evaluation suites rather than single metrics: dozens of benchmark scores (reasoning, coding, factuality, multilingual ability) alongside qualitative evaluations of refusal behavior, jailbreak resistance, and sycophancy. The disaggregation principle from the original proposal survives here, but the groups are different: instead of demographic slices of a dataset, cards now often report performance by language, by task type, and by risk scenario.

Training data disclosure also got harder. A 2018-era card could name its dataset (“trained on dataset X, 1.2M images”). A frontier model trained on trillions of tokens cannot list its data that way, so modern cards describe data composition in aggregate: sources by type, filtering pipelines, deduplication methods, and known contamination risks. Critics argue this is weaker transparency, and they are right — but it is still meaningfully better than nothing, because it lets auditors ask follow-up questions the model developer has to answer.

The biggest structural change is that the unit of documentation shifted. With foundation models, the “model” and the “deployed system” are often built by different organizations — one trains the base model, another fine-tunes it, a third deploys it behind an API with guardrails. Each layer introduces new risks and changes behavior, which means a single model card is no longer sufficient. Best practice now is a chain of cards: the base model card, a fine-tuning addendum, and a system card for the deployed product. The model card explains what the foundation can do; the system card explains what the deployed product actually does, including its safeguards, monitoring, and human oversight.

If you are reading model cards in 2026, check three things the original format never needed: the evaluation suite (not just headline scores), the data contamination statement (was the model tested on data it trained on?), and the fine-tuning lineage (has this model been modified since the card was written?). Cards that answer all three are the ones worth trusting.

Frequently Asked Questions