How to Read an AI Model Card: A Plain-English Guide

By Rowan Ashby · October 20, 2026

When a company releases a new AI model, the launch post tells you what the company most wants you to know. The model card usually tells you more: what the model is for, what it was trained on, how it was tested and where it is known to fail. Few people read them because they look technical, but most of what matters to an ordinary user sits in a handful of sections you can check in about ten minutes.

Where model cards come from

The idea comes from a 2018 research paper, "Model Cards for Model Reporting," by Margaret Mitchell, Timnit Gebru and seven co-authors, presented at the FAT* conference in January 2019. It describes model cards as "short documents accompanying trained machine learning models that provide benchmarked evaluation," and argues that released models should come with documentation of how they perform and where they should not be used. The paper proposed nine sections, from "Model Details" and "Intended Use" to "Ethical Considerations" and "Caveats and Recommendations."

The format has since taken a few forms:

• On Hugging Face, a widely used hub for downloadable models, the model card is the README.md file in each model's repository: readable text plus structured metadata at the top, such as the license, training datasets and the model it was built from.
• Large AI labs publish longer documents for their flagship models. Google DeepMind describes its model cards as "Simple, structured overviews of how an advanced AI model was designed and evaluated." Anthropic calls its version system cards, which "document the capabilities, safety evaluations, and responsible deployment decisions for Claude models."
• Regulation now asks for related information. Article 53 of the EU AI Act, as published on the European Commission's AI Act Service Desk, requires providers of general-purpose AI models to publish "a sufficiently detailed summary about the content used for training." It also requires technical documentation and information for companies building on a model, although free and open-source models without systemic risk are exempt from those two duties. The Commission published a template for the training summary on July 24, 2025.

A model card is the developer's own description for readers; the legal documentation is a separate obligation. They can cover similar ground, but one is not a substitute for the other.

The five sections that matter most

1. Model details: is this the model you are using?

Look for the developer, version, date and license. Models are updated and renamed often, so check that the card matches the product in front of you. On Hugging Face, the base_model field shows whether a model is a fine-tune, adapter, quantized (compressed) copy or merge of another model. If it is, the original model's card and license matter too.

2. Intended use and out-of-scope use

This section says what the model was built for and, just as usefully, what it was not. Hugging Face's annotated model card template asks authors to describe likely misuse, including cases where the model is "used in a way it will not work for," and what users "ought not do with the model." If your task is on the out-of-scope list, take that seriously, whatever the marketing says.

3. Training data and knowledge cutoff

Big-lab cards tend to describe training data broadly. Google's model card for Gemini 4 Argon, for example, lists categories such as public web documents, code, images, audio and video, plus licensed data and data from users of Google products, rather than naming specific datasets. The same card gives a date that matters to everyday users: "The knowledge cutoff for Gemini 4 is March 2026, but in some domains the model’s knowledge may be less up to date." A cutoff tells you when to stop trusting the model's memory of events and start checking current sources.

4. Evaluation: who ran the tests, and on what?

Benchmark tables are the part of a card most likely to reach headlines and most worth reading slowly. Ask three questions:

• Who ran the tests? Often, the developer did. Hugging Face's metadata lets authors record a source for each result, so check whether a score comes from the developer or an independent leaderboard.
• Which comparisons were chosen? The developer decides which rival models and benchmarks appear in its own table.
• Is anything broken down? Hugging Face's guidance says results should ideally be "disaggregated," split out by things like subject area and the groups of people affected, but notes that the section "is most commonly used to report aggregate evaluation performance on different task benchmarks." An average can hide weak spots in the language or topic you care about.

5. Bias, risks, limitations and safety

Hugging Face's template distinguishes three ideas. Bias means the model performs unevenly across groups. A risk, in the template's words, is "a socially-relevant issue that the model might cause." A limitation is a predictable way the model fails. Lab cards often add safety testing: Gemini 4 Argon's card names hallucinations among its known limitations and reports Google's assessment against risk thresholds it calls CCLs, which are defined in Google's Frontier Safety Framework. A card that names concrete failure modes is more useful than one that lists only strengths.

A ten-minute checklist

1. Date and version. Does the card match your model, and when was it last updated?
2. License. Open the license itself, not just the tag. (Our guide to open-weight and open-source AI explains what to look for.)
3. Out-of-scope uses. Is your task on the list?
4. Knowledge cutoff. How old is the model's information?
5. Benchmarks. Self-reported or independent? Averaged or broken down?
6. Known limitations. Are specific failure modes named?
7. Contact. Hugging Face's template includes a "Model Card Contact" section for questions and corrections.

What a model card cannot tell you

Analysis: A model card is the developer describing its own product. It is not an audit, and nothing in the card itself shows that an independent party has checked the numbers. It also describes the model, not the app around it: whether your chats are stored or used for training depends on the service's privacy policy and settings. And cards change; Google's index shows an "updated" date for each one. Treat a model card as the best available starting point and, where the stakes are high, look for independent testing.

Sources

All accessed October 20, 2026.

1. Mitchell, M., et al., "Model Cards for Model Reporting," arXiv:1810.03993 (FAT* 2019): https://arxiv.org/abs/1810.03993
2. Hugging Face, "Model Cards": https://huggingface.co/docs/hub/model-cards
3. Hugging Face, "Annotated Model Card Template": https://huggingface.co/docs/hub/model-card-annotated
4. Google DeepMind, model cards index: https://deepmind.google/models/model-cards/
5. Google DeepMind, Gemini 4 Argon model card (October 13, 2026): https://deepmind.google/models/model-cards/gemini-4-argon/
6. Anthropic, model system cards index: https://www.anthropic.com/system-cards
7. European Commission, AI Act Service Desk, Article 53: https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-53
8. European Commission, "Explanatory Notice and Template for the Public Summary of Training Content for general-purpose AI models" (July 24, 2025): https://digital-strategy.ec.europa.eu/en/library/explanatory-notice-and-template-public-summary-training-content-general-purpose-ai-models