Two different documents, two different questions
A model card describes a model. A system card describes the thing that gets deployed. The distinction sounds academic until you notice that almost every buying decision is about the second one, and almost every document you are handed is the first one. A model card can tell you how a classifier scored on a held-out set. It cannot tell you what happens when that classifier sits behind a retrieval layer, a prompt template, a confidence threshold set by someone in product, and a queue of humans who are supposed to review the low-confidence cases and mostly do not.
The model card comes out of research practice. "Model Cards for Model Reporting," posted by Margaret Mitchell and colleagues in October 2018 and revised in January 2019, proposed a short structured document that travels with a trained model: what it is, what it was trained on, what it was evaluated on, how it performs across different groups, and where it should not be used. Its central recommendation was that released models carry benchmarked evaluation in a variety of conditions rather than a single headline number. A companion proposal, "Datasheets for Datasets" by Timnit Gebru and colleagues, first posted in March 2018 and published in Communications of the ACM in December 2021, does the same job for a dataset: motivation, composition, collection process, recommended uses.
System cards are a later, industry-driven practice with no founding paper and no standard. They appeared when models stopped being downloadable artifacts and became hosted products wrapped in retrieval, tool access, content filters, rate limits, and usage policy. A system card describes that assembly. Because there is no agreed format, the quality range is enormous: some are serious engineering documents with measured mitigation effects, and some are the model card with two paragraphs about safety appended.
So the first move when a document lands on your desk is to identify which artifact you actually have. Look for one signal: does the document describe anything outside the model weights? If it never mentions thresholds, fallback behavior, logging, human review, or what the system is permitted to do rather than say, you are holding a model card, and you are missing most of what determines whether the deployment works.
| Artifact | What it covers | The buyer question it answers | What it cannot tell you |
|---|---|---|---|
| Model card | Architecture, training data at a summary level, evaluation results, intended and out-of-scope use | Is this model plausibly suited to my problem class? | How the deployed product behaves, what mitigations exist, how failures are caught |
| Datasheet | A dataset's motivation, composition, collection process, recommended uses | Where did the data come from and may I rely on it? | Anything about the model trained on it |
| System card | Model plus scaffolding: filters, tools, thresholds, human oversight, abuse testing | What does the fielded system do, and what stops it doing the wrong thing? | Whether any of it holds on your data, in your workflow |
| Evaluation report | A specific test: dataset, method, metrics, operating point, results | What was actually measured, by whom, on what? | Whether the test resembles your population |
| Third-party assessment | An outside party's review against a named framework or control set | Has anyone with no stake in the sale looked at this? | Whether the scope of the review included your use case |
Card sections by decision weight — our review order
Relative weight we give each section when deciding whether a card supports an acceptance decision — an editorial ranking of our own reading order, not a measured statistic. The headline accuracy number sits last on purpose: it is the section most often true and least often decision-relevant.
Read the out-of-scope list first
The intended-use section is the closest thing a card has to a warranty boundary, and the out-of-scope list inside it is the single most informative paragraph in the document. A vendor who has written a specific out-of-scope list has thought hard about how the system fails and has accepted the commercial cost of saying so in writing. A vendor whose out-of-scope list reads "not for use in illegal activities" has written nothing.
The practical exercise takes ten minutes. Write down your top three intended uses in one sentence each. Then check each against the card and sort it into one of three buckets: named in scope, named out of scope, or unaddressed. Unaddressed is the usual answer and it is the one that matters, because an unaddressed use is a use the vendor will disclaim later at no cost. Resolve those three in the contract, not in the card. A statement of work that names the use case, the input distribution, and the acceptance threshold converts a paragraph of marketing into an obligation.
For federal buyers this is not just prudence. OMB Memorandum M-25-21, issued April 3, 2025, directs agencies acquiring AI toward "documenting known capabilities and limitations of the AI and any guidelines on how the system is intended to be used." The memo rescinded and replaced M-24-10 and is the operative federal AI management guidance. The word doing the work in that sentence is "limitations." A card with no limitations section is not responsive to it.
Where evaluation sections fail
Most cards have an evaluation section. Most evaluation sections do not support a decision, for four repeatable reasons.
One number, no operating point. A classifier does not have an accuracy. It has a curve, and you pick a point on it. "94% accurate" without a threshold, a precision figure, and a recall figure is not a result you can plan around. Ask which point on the curve the number describes, and ask what happens at the point you would actually run, which is usually the one where false positives are cheap and false negatives are not, or the reverse. If the vendor cannot say, no one has run the system at your risk posture.
Aggregate only. The original model card proposal was largely about this: performance disaggregated across the groups and conditions that matter, including intersections, rather than a single pooled figure. A pooled number hides the segment where the system does not work. For a document-processing system, that segment is scanned pages, or a form revision from 2011, or the eight percent of records with a missing field. Ask for the breakdown by whatever your operational segments actually are.
No denominator and no interval. A number with no sample size is a rumor. A number from 80 examples and a number from 80,000 examples print identically. Ask for n and for a confidence interval, and treat a difference between two systems that sits inside overlapping intervals as no difference at all.
No provenance for the test set. This is the one that ends deals. If the evaluation data came from the same pool as the training data, the number is a memory test. M-25-21 tells agencies to assess "for overfitting to known test data, ensuring that AI developers or vendors are not directly relying on the test data to train their AI systems." That sentence is the most useful thing a buyer can quote in a vendor call, and the answer you want is a description of how the split was made and held. For deeper mechanics, see how to verify an AI vendor's benchmark claim.
Data provenance is a legal question wearing technical clothes
The training-data section of a card is usually the shortest and the most consequential. Four questions get you most of the way.
Where did it come from, and under what licence? Scraped, licensed, purchased, user-contributed, and synthetic data carry different downstream obligations. A card that says "a large corpus of publicly available text" has told you the collection method and nothing about the rights.
What is the time window? A model trained on data through a certain date cannot know what happened after it. If your workflow depends on current rules, rates, or codes, the cutoff is a functional specification, not trivia.
Does it include personal or regulated data? The answer changes your privacy analysis, and in some sectors your ability to deploy at all. If the vendor cannot answer, the answer is that they do not know.
Does my data become their data? Whether your inputs are retained, used for training, or used for evaluation is a contract term. A good card states the product default; the contract states your term. Do not accept the card as the answer.
M-25-21 also points agencies toward "documenting provenance of data used to train, fine-tune, or operate the AI." The phrase "or operate" is worth reading twice. It reaches the retrieval corpus, the reference tables, and the prompt context — the data the system consults at run time, which is frequently where the actual risk lives and which almost no model card describes.
Is your use "high-impact"?
M-25-21 defines high-impact AI as AI whose output serves as a principal basis for decisions or actions with a legal, material, binding, or significant effect on: civil rights, civil liberties, or privacy; access to education, housing, insurance, credit, employment, and other programs; access to critical government resources or services; human health and safety; critical infrastructure or public safety; or strategic assets and resources, including high-value property and information marked as sensitive or classified. If your use lands in one of those six, a set of minimum risk management practices attaches, and vendor documentation has to feed them.
What a system card adds that a model card cannot
Five things, and their absence is the fastest way to tell a real system card from a relabelled model card.
Mitigations with measured effect. Not "we added safety filtering" but what the filter blocks, what it misses, and what it costs in false refusals on legitimate inputs. A mitigation with no measurement is an intention.
Refusal and abstention behavior. How often does the system decline, return low confidence, or hand off, and is that surfaced to the operator or silently converted into an answer? Abstention is a feature in regulated work and almost nobody reports its rate. We wrote separately on the refusal rate metric nobody reports.
The action surface. What the system can do, not only what it can say. Which tools, which APIs, which write permissions, which outbound calls. For anything agentic, this section is the security review.
Logging and traceability. What is recorded per decision, how long it is kept, and whether a specific past output can be reconstructed with its inputs and version. If you will ever have to explain a decision to an auditor, an inspector general, or a claimant, this is the section that determines whether you can.
Adversarial testing, in shared vocabulary. NIST published AI 100-2 E2025, "Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations," in March 2025, covering attack classes including data poisoning, evasion, and abuse of large language models. A system card that names which of those classes were tested, and how, is reviewable. One that says "we red-teamed the model" is not.
Map the card to the requirement you actually carry
A card is not an end in itself. It is an input to an obligation you already hold. For federal high-impact uses, M-25-21 sets minimum risk management practices, and each one implies a specific thing the vendor documentation either supports or does not. This table is the version we work from.
| Minimum practice (M-25-21, high-impact AI) | What in the card supports it | What to request when it is missing |
|---|---|---|
| Pre-deployment testing | Evaluation section with test-set description, operating point, and disaggregated results | A run on your own held-out data, executed by you or by the vendor on data you supply |
| AI impact assessment | Intended purpose, data quality and fitness summary, stated limitations and potential impacts | A written data summary keyed to your population, plus the vendor's known failure modes in writing |
| Ongoing monitoring | Drift and monitoring plan, retraining cadence, version history with dates | Telemetry access, an agreed monitoring metric, and contractual notice before a version change |
| Human oversight and fail-safe | Confidence thresholds, escalation design, fallback behavior when the model abstains | A documented fail-safe path and the abstention rate at your operating point |
| Remedies or appeals | Per-decision logging, explanation features, record retention period | Retrievable per-decision records with inputs, output, model version, and timestamp |
| Operator training and assessment | Guidance on interpreting outputs, documented limits of the interface | Role-specific operator material, and a written statement of what the operator must not infer |
The memo also states that where an agency lacks access to the underlying source code, models, or data, it must use alternative test methods — querying the AI service and observing outputs, or providing evaluation data to the vendor and obtaining results. Read plainly, that removes the most common excuse in a vendor conversation. "You cannot test it, it is proprietary" is not a stopping point. It is a routing instruction: you either test the interface or you hand over a sealed evaluation set and take back the numbers.
The version problem
A card describes a version. You are usually buying a service. Those two facts drift apart quietly, and the drift is what turns a passed acceptance test into an unexplained incident nine months later.
Four questions close the gap. Which exact version does this card describe, by identifier and date? What is the notice period before a version changes under me? Can I pin a version, and for how long? What triggers a new card — any change, or only changes the vendor judges material? The last one matters most, because a vendor-judged materiality standard means the changes you find out about are the ones the vendor already decided were safe to disclose.
For a hosted model, add a cheap operational habit: run your acceptance set on a schedule, not once. Weekly is enough for most workflows. The point is not the score. The point is the day the score moves without an announcement, which tells you something changed upstream and your documentation is now describing a system you no longer have.
Three tests you can run without the weights
The held-out slice. Two hundred to five hundred of your own labeled records, never sent to the vendor before, scored at the operating point you would deploy. This single artifact is worth more than every card you will read this quarter, because it is the only measurement taken on your distribution. Budget the labeling honestly; it is usually the real cost and it is usually worth it.
The perturbation pass. Take the same records and degrade them the way reality does: scanner noise, name variants and transliterations, missing fields, dates outside the training window, a form revision the vendor has never seen. Report the delta from the clean run rather than the absolute number. A system that loses two points is fielded differently from one that loses thirty, and no card will tell you which you have.
The abstention audit. Count how often the system declines, flags low confidence, or produces an answer it should not have. Then check what your workflow does with each of those. Most pilots that fail in production fail here: the model behaved correctly, flagged uncertainty, and the surrounding process discarded the flag. A written evaluation harness makes all three of these repeatable instead of anecdotal.
Where the rules stand right now
There is no single mandated model card format in United States federal practice, and buyers should stop waiting for one. What exists is a stack of instruments that each imply documentation without prescribing a template.
OMB M-25-21 (April 3, 2025) is the operative federal AI management memo, rescinding and replacing M-24-10. It defines high-impact AI, sets minimum risk management practices for it, and pushes documentation expectations into procurement practice. The NIST AI Risk Management Framework 1.0, released January 26, 2023, organizes work under four functions — Govern, Map, Measure, Manage — and is voluntary, which does not stop agencies from citing it in requirements. NIST added the Generative AI Profile, AI 600-1, on July 26, 2024, and released a concept note for a critical-infrastructure profile on April 7, 2026, which tells you the direction of travel. ISO/IEC 42001:2023 is a certifiable AI management system standard; a vendor certificate is a real signal about process discipline and tells you nothing about any particular model's numbers, which is a distinction worth holding in a sales conversation.
The EU AI Act is the one instrument that prescribes content. Article 53 requires providers of general-purpose AI models to draw up and keep technical documentation per Annex XI, to give downstream providers the capability and limitation information listed in Annex XII, to put a copyright policy in place, and to publish a summary of training content on a template supplied by the AI Office. Those obligations became applicable on 2 August 2025. Open-source models released under a free licence with public parameters are exempted from parts of the documentation duty, except where the model is classified as carrying systemic risk. If a vendor sells into the European market, that Annex XII package exists, and asking for it is a fair question even for a United States buyer.
What is genuinely unsettled: whether any of this converges on a common format, and how much of the European implementation detail lands through codes of practice and harmonized standards rather than the text itself. Agency practice in the United States varies by component, and two program offices in the same department will ask for different artifacts. Plan for that instead of hoping it resolves. Keep one internal canonical documentation set and map it outward, which is also the advice we give firms on the selling side in federal AI model documentation requirements.
A twelve-point read
What we run through when a card lands, in order. Each item is either present and specific, present and generic, or absent. Two absences in the first six is a stop.
- Version identifier and date, matching the version being sold
- Out-of-scope uses, specific enough to exclude something real
- Your three intended uses, each named in scope or out
- Evaluation method, operating point, and threshold stated
- Results disaggregated by the segments you operate on
- Sample size and interval for every headline number
- Test-set provenance and how the split was held
- Training and retrieval data sources, licence, and time window
- Whether your inputs are retained or used for training
- Mitigations with measured effect, including false-refusal cost
- Logging: what is kept per decision, and for how long
- Change policy: notice period, pinning, and what triggers a new card
Bottom line
Model cards and system cards are useful, and they are not proof. Their value to a buyer is diagnostic: the sections a vendor filled in specifically tell you what that vendor has actually measured, and the sections they filled in generically tell you what they have not. Read the out-of-scope list before the accuracy number. Ask which point on the curve the number describes. Ask where the test set came from. Then spend the money on the only measurement that is about you, which is a few hundred of your own records scored at your operating point. A card that survives that comparison is worth trusting. A card that was never checked against anything is a design artifact, and design artifacts do not carry risk.
Frequently asked questions
A model card documents a trained model: architecture, training data summary, evaluation results, intended and out-of-scope use. A system card documents the deployed assembly around that model — filters, tools, thresholds, human oversight, logging, and abuse testing. Buying decisions are almost always about the system, so a model card alone leaves the decision-relevant part undocumented.
No United States law mandates a model card format. Federal agencies operate under OMB M-25-21, which sets minimum risk management practices for high-impact AI and pushes documentation expectations into procurement without prescribing a template. In the European Union, Article 53 of the AI Act does prescribe documentation content for general-purpose AI model providers, applicable since 2 August 2025.
No. M-25-21 tells agencies that where they lack access to the underlying source code, models, or data, they must use alternative test methods — querying the service and observing outputs, or supplying evaluation data to the vendor and obtaining the results. Both are available to commercial buyers as contract terms. Proprietary weights are a reason to test through the interface, not a reason to skip testing.
"Where did the evaluation data come from, and how do you know it was not used in training?" A vendor with a real answer describes the split, who held it, and when it was last refreshed. A vendor without one changes the subject to the headline number.
On every version that changes performance characteristics, training or retrieval data, or intended use — and on a fixed calendar regardless, so that a year never passes without a review. Tie the refresh to a contractual notice period, because for a hosted service the version can change without you doing anything.
The federal instruments are the clearest published statement of what a careful buyer checks, which makes them a free checklist for commercial buyers. The high-impact categories in M-25-21 — health and safety, credit, employment, access to services, critical infrastructure — map onto commercial risk almost exactly.