A model card is a short, structured document that describes what a model is, what it was built to do, how it was evaluated and where it should not be used. For large language models (LLMs), a useful card covers intended use, training data provenance, evaluation results, known limitations and safety testing. It documents the model. It does not document the conversational agent your company builds on top of that model, and that gap is where most compliance risk sits.
This guide explains what belongs in a model card for an LLM, how to read published examples, what the EU AI Act adds, and what to use when a card is not enough.
TL;DR
- A model card describes a model’s intended use, data, evaluation and limits. The format was proposed in the 2019 paper “Model Cards for Model Reporting” by Mitchell et al.
- For general-purpose AI models sold in the EU, the AI Act turns model documentation from good practice into a legal obligation for the provider.
- A card describes one model in controlled tests. It does not show how a deployed agent behaves with real customers, which includes escalation, disclosure and security.
- Treat model documentation as a living, version-controlled record, and pair it with independent evidence from real conversations.
Table of Contents
- What a model card is, and who reads it
- What a model card for an LLM should contain
- How to read model card examples
- What the EU AI Act changes
- Why a model card is not enough for an AI agent
- From model cards to audit cards
- Explainable conversational AI: cards versus dialogue
- Our perspective
- A practical checklist for your governance file
- Where Lexic fits
- FAQ
- Sources
What a model card is, and who reads it
Model cards were proposed as a way to report a model’s performance across conditions and groups, and to state its intended context of use. The idea is borrowed from nutrition labels: a standard format so readers can compare and decide.
The readers differ, and that is the first design problem:
- Engineers need architecture, context length, training approach, benchmark results and license terms.
- Compliance and legal teams need data provenance, risk classification, safety testing and evidence the document is current.
- Business leaders need a plain-language answer to one question: is this model appropriate for this use?
Research from the Aspen Institute argues that engineer-centric model cards are too complex for policy and business audiences, and that policy-specific cards should distill technical metadata into plain language. If your executives cannot read the card your team relies on, the card is not doing its governance job.
What a model card for an LLM should contain
The original template was written with classifiers in mind. LLMs need more, because they are general-purpose and open-ended. A card worth relying on covers the following.
Identity and intended use
Model name, version, developer, release date and license. Then the intended uses and the out-of-scope uses. “Customer support” is not a precise scope. “Drafting replies reviewed by a human agent” is.
Training data and provenance
What categories of data were used, how they were collected, how they were filtered, and what is known about gaps. Many published cards are thin here, which limits what a downstream user can verify.
Architecture and training method
Model family, parameter count where disclosed, context window, fine-tuning and alignment methods. These details matter when you compare vendors or explain a model to a regulator.
Evaluation results
Benchmarks, the conditions under which they were run, and the subgroups or languages tested. A single headline score tells you little. Look for results split by task, language and risk category.
Safety testing and known limitations
Red-teaming results, refusal behavior, known failure modes such as fabricated facts, and the residual risks. A card that lists no limitations is a warning sign.
Operational facts
Hardware used, energy consumption, update cadence and a contact for reporting problems. Under the EU rules covered below, some of these are mandatory for certain providers.
How to read model card examples
People searching for model card examples usually want a template to copy or a published card to study. Both exist, and they serve different purposes.
Published cards from model developers. Major developers release cards or system documents with each model. Read several side by side and compare what each discloses: training data detail, evaluation breadth, safety testing and stated limits. The differences in depth are informative in themselves.
Open templates for internal use. The NIST AI RMF Cookbook on GitHub includes a model cards directory with more than 130 cards across major providers, and the Zenodo release describes YAML schemas for model cards, data cards, risk assessments and control mappings. The release is labeled alpha, and it is a community project, not an official NIST publication, so treat it as a starting structure to adapt, not as an authority.
When you review any example, ask five questions:
- Does it state what the model should not be used for?
- Can you tell what data categories the model learned from?
- Are evaluation conditions described well enough to repeat them?
- Are limitations specific, or generic?
- Is there a version and a date, so you know whether the card still matches the model?
Templates that standardize documentation also help governance teams, and structured frameworks for making technical documentation usable for non-technical decision-makers can support the translation step between engineering and the business.
What the EU AI Act changes
For companies selling or deploying in Europe, model documentation is no longer optional for a large class of models. Providers of general-purpose AI (GPAI) models must keep technical documentation covering architecture, training methods, data provenance, energy consumption and evaluation results, as summarized by the COMPEL Framework. The same source notes that models classified as posing systemic risk face additional requirements, including adversarial testing. It adds that the familiar model card format is a useful starting point but must be extended to cover everything the Act’s annex requires.
A law firm’s overview of the obligations on GPAI providers describes how the Act defines these models by their generality and their ability to be integrated into many downstream systems. For a plain-language walkthrough of who must comply, see this overview of what the EU AI Act requires.
Two practical points for US companies entering Europe:
- The model provider carries the model-level duty. You may still carry the deployment-level one. If you build a customer-facing agent on a third-party LLM, the vendor’s documentation does not discharge your own obligations, such as telling people they are talking to an AI. Confirm your role with counsel.
- “Up to date” is part of the requirement. The COMPEL guidance recommends treating documentation as a living, version-controlled artifact and capturing metadata such as hyperparameters and energy use automatically from training pipelines, instead of writing it by hand after the fact.
This article is general information, not legal advice. Classification of a model or system under the Act depends on the facts, so ask qualified EU counsel before you rely on any reading.
Why a model card is not enough for an AI agent
A customer service agent is not a model. It is a model plus a system prompt, retrieval sources, tools, guardrails, escalation rules, channel integrations and a human handoff process. The model card describes only one of those parts.
Researchers working on documentation for complex systems make the same point. A paper on dynamic documentation for AI systems argues that static documentation does not capture the feedback-laden, changing nature of machine learning systems. Practitioners report that, for modular agents combining several models, a single card does not explain how the components interact to produce systemic behavior or failure.
Three gaps follow.
1. Lab results are not field results. A card reports performance on benchmarks. It cannot tell you whether your agent, with your prompts and your knowledge base, hands a distressed customer to a person. In audits run by Lexic, 85% of the AI agents audited failed to escalate issues properly to human representatives. No model card would have predicted that, because the failure sits in the deployment, not the model.
2. Cards are written by the party being described. Most evaluation reports and model cards omit context such as auditor background, conflicts of interest and the level of model access, according to the Audit Cards research. Without it, a regulator or compliance team cannot judge how far to trust the result.
3. Cards go stale. A model updated silently, a changed prompt or a new retrieval source can alter behavior while the card stays the same.
Generated documentation adds its own risk. A dataset study on automated model card generation found that LLM-based generators can hallucinate details such as training infrastructure, based on how often something appears in text instead of the model’s actual provenance. If you automate card drafting, verify every factual field against a primary record.
From model cards to audit cards
The same authors who note these omissions propose a complement: the audit card. It reports on the audit itself, including who the auditor was, what the scope was, which methods were used and what review mechanisms applied. The idea is that an evaluation result means little unless the reader can interpret it in context.
In practice, a governance file for a conversational AI agent can hold three layers:
| Layer | Document | Answers | Typical owner |
|---|---|---|---|
| Model | Model card | What is the underlying model and how was it tested by its developer? | Model provider |
| System | System documentation | How is the agent configured, what data does it access, where does it escalate? | Your engineering team |
| Behavior | Audit report with audit card | What does the agent actually do in real conversations, and who checked? | Independent auditor |
The third layer is the one most organizations lack. It is also the one that can be defended in front of a regulator, because it does not depend on data supplied by the vendor. For a different regulated context, a note on what auditors need beyond system logs shows how audit-trail expectations work in practice: evidence must be attributable, complete and reviewable, which is the standard an AI audit file should meet too.
Explainable conversational AI: cards versus dialogue
People also ask how explainability applies to conversational AI. There are two separate questions.
The first is explaining a model to the people who govern it. Here, interaction can beat static documents. In evaluations of TalkToModel, a dialogue-based system for explaining machine learning models, 85% of machine learning professionals found the conversational interface easier to use than static explanations for understanding model behavior. Users could ask why a prediction was made or how the outcome would change if inputs changed.
The second is explaining what an agent did in a specific customer conversation. That needs the transcript, the decision points and the escalation path, linked to a record. Explainability in this sense is evidence from conversations, not a property of the model.
Our perspective
We audit conversational AI agents from any vendor, and we do not build or operate agents ourselves. That independence shapes how we see model cards.
A model card is a necessary input and a poor conclusion. It tells you what a developer says about a model under test conditions. It cannot tell you whether your deployed agent discloses that it is an AI, whether it leaks information under adversarial prompting, or whether it routes a complaint to a person. Those are behaviors, and they show up only in real conversations.
We recommend three habits. Keep the model card, the system documentation and the audit evidence together and version them together. Review conversations at full coverage, not a sample, because the failures that matter are often rare. And have the evidence produced by someone with no stake in the agent’s success, so it holds up when a regulator, a customer or a board member asks how you know.
— Sergio Llorens
A practical checklist for your governance file
Use this list when you document an LLM-based agent.
- Record the model. Link the provider’s card, note the exact version, and set a reminder to re-check it when the provider updates the model.
- Translate it. Write a one-page plain-language summary for executives: intended use, main limits, risk level.
- Document the system. Prompts, data sources, tools, guardrails, escalation rules and human handoff.
- Capture metadata automatically. Version history and configuration changes should come from your pipeline, not memory.
- Test in production conditions. Review real conversations for escalation, disclosure, security and accuracy.
- Add independent context. Attach the audit scope, method and auditor identity to each evaluation.
- Review on a schedule. Any model, prompt or knowledge change triggers a documentation review.
Where Lexic fits
Lexic provides independent audits of conversational AI agents from any vendor, checking real-world behavior against regulatory, security, escalation and disclosure criteria. Lexic Compass is the audit and governance product. Engagement options, including Flash Preview, Audit Sprint and Enterprise Continuous Trust, are described on the audit engagement page. For analysis of all customer conversations across calls, chats, emails and tickets, see Lexic Pulse.
FAQ
What is a model card for an LLM?
It is a structured document from a model’s developer that describes intended use, training data, evaluation results, safety testing and known limits. It lets buyers and regulators judge whether a model suits a given purpose. It describes the model only, not the agents or products built on it.
Are model cards required by law?
Not as a named format in general. Under the EU AI Act, providers of general-purpose AI models must maintain technical documentation covering architecture, training, data provenance and evaluation, and a model card is a common starting point for it. US requirements vary by state and sector, so check with counsel for your situation.
Where can I find model card examples?
Model developers publish cards or system documents with their releases, and open repositories such as the NIST AI RMF Cookbook project collect templates and schemas. Compare several for how much they disclose about data, evaluation and limitations, and adapt a template to your own internal use.
Does a model card prove an AI agent is compliant?
No. It documents one component under test conditions. Compliance for a customer-facing agent depends on how the whole system behaves, including disclosure, escalation and security, which requires evidence from real conversations.
Can an LLM write its own model card?
It can draft one, but research on automated generation shows these tools may invent details such as training hardware. Use generated text only as a draft and verify each fact against primary records.
Sources
- Aspen Institute: AI Model Cards for a Policy Audience
- vintagedon/nist-ai-rmf-cookbook on GitHub
- NIST AI RMF Cookbook release on Zenodo
- COMPEL Framework: GPAI Model Obligations and Systemic Risk
- Taylor Wessing: Obligations on providers of GPAI models
- Dynamic Documentation for AI Systems
- Audit Cards: Contextualizing AI Evaluations
- Unlocking Model Insights: A Dataset for Automated Model Card Generation
- Explaining machine learning models with TalkToModel, Nature Machine Intelligence