In plain terms
Medicines come with a leaflet: what the product is for, the dose, the side effects, who should not take it. A model card is the leaflet for an AI model. It tells whoever is about to use the model what it was built to do, what it should be kept away from, how well it did in testing, and in which situations it is known to be weak.
Why it matters
It is the first document to ask for when choosing a model, and the quality of the answer says something about the supplier. A good card lets a buyer check two things before any testing: whether the intended use covers their case, and whether the reported results include conditions like theirs, such as their language. A card has clear limits as evidence. It is written by the developer, it describes the model and leaves out the application built around it, and its test results are no substitute for an evaluation on the buyer's own data.
Example
A bank compares two models for sorting customer emails. The first card reports 94% accuracy overall and, broken down by language, 91% for Turkish. The second reports 96% overall, tested on English only, and lists “languages other than English” under limitations. The bank's emails are in Turkish. It shortlists the first model, runs both on 500 of its own emails anyway, and finds 90% and 82%.
Most often confused with
Model Card vs. System card
The original model card covers a single model. Developers of large general-purpose models now often publish longer documents, called system cards or model cards, that report safety evaluations, red-teaming results and the safeguards placed around the model. A datasheet, a third relative, documents a dataset. In each case the first question is who wrote the document and what it leaves out.
Origin: Proposed by Margaret Mitchell and colleagues at Google in the paper “Model Cards for Model Reporting”, published in 2019.
Under the hood
Typical sections: model details (developer, version, date, type, licence); intended use and out-of-scope uses; training data, described at least in outline; evaluation data, metrics and results, ideally broken down by relevant groups or conditions, since an average can hide a weak subgroup; limitations and known failure modes; ethical considerations; and usage recommendations. On model repositories such as Hugging Face, the card is the README file of the model, with structured metadata. For frontier models, cards run to many pages and include capability benchmarks, safety and alignment evaluations and the results of external testing. Regulation is turning the practice into a duty: the EU AI Act requires providers of general-purpose AI models to draw up technical documentation and to give downstream providers the information they need, and a standard documentation form accompanies its code of practice. Reading advice: check the date and the version, look for results on conditions like one's own, and treat missing sections as information.