What Is a Model Card? The Document Every Deployed Model Needs

A model in production without documentation is a liability: nobody can say what it was tested on, where it should not be used, or what changed since launch. Model cards solve that with a standard structure describing intended use, data, evaluation, limitations, and ownership. They began in research and are now expected by auditors, regulators, and enterprise buyers, and they apply to LLM applications as system cards. This explainer covers what a model card contains and how to write one, drawing on FISTA Solutions' AI enablement practice. The documentation set is in the ai documentation checklist and the review that reads it in what is an ai audit.

What is a model card?

A model card is a structured, versioned document accompanying a trained model or LLM configuration that states its purpose, the data behind it, how it was evaluated and with what results across segments, its known limitations and risks, recommended and prohibited uses, and who owns it. It is written for people who did not build the model and need to decide whether and how to use it.

What sections does a model card contain?

Section	Content
Model details	Name, version, type, date, owner, contact, license
Intended use	Primary use cases, intended users, decisions it informs
Out-of-scope uses	Uses it was not designed or tested for
Data	Training or grounding data, sources, permissions, preprocessing, known gaps
Evaluation	Datasets, metrics, results overall and by relevant segments
Limitations	Known failure modes, conditions where performance degrades
Safety and ethics	Fairness findings, misuse risks, mitigations
Recommendations	Required controls, monitoring, human oversight
Change history	Versions and what changed

Evaluation practice behind the card is in what is an eval in ai and data documentation in what is data lineage in ai.

How do model cards apply to LLM applications?

The base model provider publishes its own card, but your application is a configuration: a model version, system prompt, retrieval sources, tools, guardrails, and autonomy levels. A system card documents that configuration, with evaluation results on your golden dataset, safety test results, and the controls in place. It changes whenever any component changes. Configuration elements are in what is a system prompt and autonomy in what is an autonomy level in ai.

Why is evaluation by segment the most important section?

Aggregate accuracy hides failures on specific groups, document types, languages, or conditions. A card that reports results disaggregated by the segments that matter to the use case lets readers judge fit for their population and lets auditors verify fairness claims. It is also the section most often missing, because it requires labeled data by segment. Golden dataset design is in what is a golden dataset.

Who requires model cards?

Regulators for high-risk systems in several jurisdictions, standards for AI management systems, enterprise procurement and vendor due diligence, internal governance policies above a risk tier, and auditors. Even where not required, a card shortens every review. Regulatory framing is in ai regulation in the united states and vendor expectations in the AI vendor due diligence whitepaper.

How do you write and maintain a model card?

Draft it from the specification before evaluation, so the card defines what evaluation must cover; fill evaluation and limitations from real results, including weaknesses; state out-of-scope uses explicitly; link every claim to evidence; version the card with the model in the registry; and assign an owner who updates it on every change. Registry integration is in how to build a model registry.

What are common mistakes?

Cards written once and never updated; evaluation reported only in aggregate; limitations omitted to make the model look better; intended use stated so broadly it excludes nothing; and cards that describe the base model rather than the deployed configuration. Each mistake surfaces in audits or incidents. Governance context is in what is ai governance.

What does a model card look like in practice?

A system card for a customer support agent records the base model version, the system prompt version, the knowledge sources and their refresh cadence, the tools and their permissions, autonomy levels per action, evaluation results by intent category and language, adversarial test results, known weaknesses on billing disputes, required human review for refunds, the owner, and a change log with evaluation deltas per release. It is regenerated by the release pipeline. Agent construction is in how to build an ai customer service agent.

How FISTA Solutions produces model cards

FISTA Solutions generates a system card for every model and agent it delivers, drafted from the specification, populated from evaluation and safety results by segment, versioned in the registry, and handed over with a named owner and update process. The AI enablement practice delivers documentation and governance platforms, AI agents ship with system cards, and forward deployed engineers embed with client governance teams. The record behind the approach is 150+ projects with 99.9% uptime.

To document your models to the standard auditors and buyers expect, message FISTA on WhatsApp, or read the ai documentation checklist for the full record set.