Model Card

A model card is a standardized document describing an AI model's intended use, performance, limitations, and known risks. It is a spec sheet for a system whose behavior you can't read off the source code. It tells anyone evaluating the model what it was built for, where it works, and where it's known to fail.

In Depth

Software you can inspect. A model you mostly have to describe. A model card fills that gap with the facts a downstream user needs to deploy responsibly: what the model is meant to do, the populations and conditions it was tested on, how well it performed, what it should not be used for, and the failure modes its builders already know about. The format traces back to a 2018 proposal for "model cards for model reporting," and it has since become a common convention across the industry.

The most important section is often the one teams skip: limitations and out-of-scope uses. A card that only lists impressive accuracy numbers is marketing. A useful card says where the model degrades, on which inputs, which populations, and which edge cases, because that's what a careful deployer needs to know before putting it in front of users. An honest limitations section is also a small liability shield. It documents that you disclosed a known boundary rather than letting a buyer assume it didn't exist.

Cards are now spreading from convention into expectation. Enterprise procurement teams increasingly ask for one as part of security review, and emerging AI regulation pushes toward documentation duties that a model card helps satisfy. The EU AI Act, for instance, attaches technical documentation and transparency obligations to higher-risk systems.

What It Looks Like

A vendor's intake agent runs on a fine-tuned model. Its card states the intended use (triaging routine patient questions), the data and populations it was evaluated on, measured accuracy, and a plain limitations section: not validated for pediatric cases, degrades on non-English input, must not be used for diagnosis. When a hospital's review team reads it, they don't have to guess at the boundaries. And if the agent is later misused for diagnosis, the card is evidence the vendor drew the line clearly.

Why It Matters For AI Vendors

A model card is one of the cheapest pieces of governance evidence to produce and one of the most frequently requested. It speeds enterprise review by answering questions before they're asked, it documents the disclosures that matter if a claim ever turns on "did the vendor warn us," and it forces the team to write down limitations they might otherwise leave fuzzy. For a model the vendor didn't train, the card is also where they record what they verified about a third-party system before building on it.

Common Questions

They're cousins. A model card focuses on a model, a system card describes a fuller deployed system including the application around the model, and a datasheet documents a dataset. They overlap and are often used together, but a model card is the most common artifact buyers ask for.
Yes, and arguably more so. If you build an agent on a third-party model, your card documents your intended use, your testing, and your limitations for your deployment, which is what your buyer cares about. Pointing at the base model's card alone doesn't cover how you actually use it.
← PreviousMITRE ATLAS Next →Model Drift

See where your AI agents stand.

Get an Agent Trust Score, map your liability exposure, and find out what it takes to make your AI agents insurable.