What is a model card?
A model card is a short standardized document that accompanies a released AI model and states what the model is, what it was built from, how it performs, and where it should not be used. The format was proposed by researchers as a nutrition label for models and is now the common form of documentation on model repositories. A typical card covers the model’s architecture and parameter count, the training data in general or specific terms, the training procedure, evaluation results on named benchmarks, known limitations and biases, intended and out-of-scope uses, safety testing, and the license.
Cards vary enormously in depth. Some run to many pages with detailed data descriptions; others are a paragraph and a benchmark table. The gaps are informative. A card that says the training data was “a mix of publicly available and licensed sources” is telling the reader that the provider will not disclose it.
Why model cards matter
For a business adopting a model, the card is the primary due diligence document. Compliance staff use it to check the license and the stated acceptable uses. Risk teams read the limitations and evaluation sections to decide whether the model suits a given task and what testing must follow. Under the EU AI Act, providers of general-purpose AI models must supply technical documentation to the companies that build on them, and the model card is the usual vehicle. Companies that fine-tune a model or build an application on it should write their own card describing the changes, the in-house evaluation, and the approved uses, and store it in the AI inventory alongside the vendor’s.
Model cards in practice
A credit union’s model risk committee reviews an open-weight model proposed for summarizing member correspondence. The card shows that the license permits commercial use, lists benchmark results that have little to do with the task, and notes weaker performance in languages other than English. The committee approves the model for English correspondence only, requires an in-house evaluation on a sample of real messages, and records both the vendor card and the internal card in the model inventory.
What to watch for
- Treat benchmark scores as a rough screen, because the card cannot say how the model handles a company’s own documents.
- Note what the card omits, especially training data sources and safety testing, and ask the provider directly.
- Check the card version against the weights being deployed, because cards are not always updated with new releases.
- Write an internal card for every fine-tuned or deployed variant.