Model Card
A model card is a short accompanying document for an AI system that discloses what it was built for, how well it performs, and where its limitations lie. It works like a package insert: it aims to prevent a program from being deployed in situations it was never tested for.
When a company releases a finished computer program that has learned from examples, it often provides a short accompanying document. This document is called a Model Card. It states what the program is intended for, what data it was trained on, and how well it performed in tests. Just as important is the second part: where the program is known to perform poorly and what it should not be used for. You can think of it like the package insert of a medication. That, too, states not only the effect, but also the dosage, the side effects, and the cases in which the medicine must not be taken.
Why software needed a package insert
A trained program looks from the outside like a neutral calculating machine. That is deceptive. It has only ever seen a certain slice of the world, namely its training data. Outside that slice, its answers are often unreliable, without this being noticeable.
The problem became known through facial recognition. Several systems recognized light-skinned men very reliably, but made significantly more errors with dark-skinned women. The reason was not malicious intent, but unbalanced collections of training images. Without a Model Card, no one learns that this gap exists. It was precisely this experience that led to the proposal made at Google in 2018 to publish standardized model cards.
Meanwhile, there is also a legal reason. The European Union’s AI Act requires technical documentation for high-risk applications. A good Model Card is one building block of that. It also helps companies that purchase a third-party system, and it does not need to reveal any trade secrets.
What information a model card contains
A Model Card is not program code, but plain text, usually one to five pages long. At the beginning come the basic facts: name, version, release date, developer, and terms of use. Then follows the intended purpose, stated as concretely as possible. One example: “Recognizes traffic signs in daylight images from Central Europe.”
The most important part is the measured values. This states how often the system was correct and on which test data. It is crucial that these values be broken down, for example by language, age group, or image quality. An average value of 95 percent can conceal the fact that one group only reaches 70 percent. This breakdown is what distinguishes a seriously intended Model Card from mere advertising.
After that come the limitations and risks. Here the developers note which errors they themselves have found. Related to this is the datasheet: it does not describe the program, but the collection of data from which it learned. A common misconception is that a Model Card makes the system safe. It only describes what is already there. Filling it out carelessly improves nothing.
Where you can look up model cards yourself
They are most easily found on Hugging Face, a large platform where developers offer their trained programs for download. Almost every entry there begins with such a card. The makers of large language programs, too, now publish extensive versions, some of them over a hundred pages long. These are then often called System Cards, because they describe not just the model but the entire product built around it.
In the news, Model Cards tend to come up in two situations. First, at the launch of a new system, when journalists compare the stated test values. Second, after a failure, when it turns out that a risk was stated in the document and was ignored anyway. Critics point out that many cards remain incomplete, especially regarding training data. Anyone wanting to assess a system therefore does not only read what is stated in it, but also pays attention to which question remains unanswered.