Updated 2026-09-08
from the news desk
What Is an AI System Card? How It Differs From a Model Card
UK Ministry of Defence guidance defines a system card as documentation for an AI model in deployment, while the 2019 model card paper describes documentation that accompanies a trained model. The practical difference is where the focus…
A system card is a structured document about an AI model in a deployed environment, covering its performance and the context of use, the UK Ministry of Defence guidance says. A model card, by contrast, is a document that accompanies a trained machine learning model and reports its evaluations, intended uses and limitations, as described by Andrew Zaldivar and co-authors; the main difference is that the system card focuses on deployment in a system, while the model card focuses on the model itself.
What an AI system card is
The UK Ministry of Defence guidance defines the term directly: “System cards are structured documents that document the key attributes of an AI model in a deployed environment, its performance and the context of its use.”
The same guidance says system cards help teams describe how AI models have been deployed and the environment they have been deployed in. The document adds that this gives risk owners, technical developers and other stakeholders a way to understand the details of a deployed AI model, and it says system cards can serve as a central tool for assuring deployed AI systems.
The MOD guidance also says system cards are mainly designed for people developing AI applications. It adds that people with sufficient technical knowledge, including risk owners and senior decision makers, can also use them to understand more about how an AI system works.
To explain the distinction between a model and a system, the MOD text cites NIST SP 800-218A for the idea of an AI model and ISO/IEC/IEEE 15288 for the idea of a system. In the MOD explanation, a model is a component that uses AI techniques to produce outputs from inputs, while a system is a combination of interacting elements organised for a stated purpose. That is why the same guidance treats a system card as documentation for AI in use, not just AI in isolation. Readers who want background on the vocabulary can use our AI glossary.
How a system card differs from a model card
The starting point for model cards in these sources is the 2019 paper by Andrew Zaldivar and co-authors. The paper says it proposed model cards as a framework for transparent model reporting, and it defines them this way: “Model cards are short documents accompanying trained machine learning models that provide benchmarked evaluation in a variety of conditions, such as across different cultural, demographic, or phenotypic subgroups”
Zaldivar and co-authors add that model cards disclose intended context of use, evaluation procedures and other relevant information. The paper says the aim is to provide context around machine learning models and increase transparency into how well those models work.
Department for Science, Innovation and Technology guidance on responsible AI in recruitment gives a more procurement-focused summary. DSIT describes model cards as follows: “A standardised reporting tool for capturing key facts about AI models, including details on:”
The same DSIT guide says model cards should cover model goals and intended use, limitations, training data, model performance and identified risks. It also states that model cards should be produced by the developer of an AI system and made available to the purchasing organisation.
The MOD guidance draws the line on the system side with a shorter definition: “A system card describes the use of one or more AI models deployed into a system.”
On a straightforward reading of those texts, the difference is scope. The Google paper and the DSIT guide describe a document about the trained model itself: what it is for, how it was tested and what its known limits are. The MOD guidance describes a document about one or more models as they are actually used inside a wider system.
There is, however, a second reading. The case for treating system cards and model cards as related layers rather than sharply separate categories rests on the overlap in the sources. Zaldivar and co-authors say model cards cover intended use, evaluation and other relevant information. DSIT says model cards capture goals, limitations, training data, performance and risks. The MOD guidance says system cards cover performance and context of use. On that reading, both documents are transparency tools, but they answer slightly different questions.
Why deployment context changes the picture
DSIT places much of the practical weight on deployment, meaning use in the buyer's real setting rather than only in supplier testing. In its recruitment guide, DSIT says organisations should ask suppliers for evidence behind claims about performance, fairness and capabilities, including documentation such as impact assessments, risk assessments, model cards and, where relevant, a data protection impact assessment.
The same guide also tells buyers to ask what the intended purpose and scope of use of the model are, and how the organisation will ensure the system aligns with its intended goals. That framing matters because DSIT says a model can shift when the setting changes: “This is because AI models can perform differently depending on the environment in which they are deployed .”
That is the strongest source-based argument for system cards as a distinct document. DSIT says pilots can show discrepancies between supplier data and an organisation's own data, and the MOD guidance says system cards capture the environment in which a model has been deployed. Put together, those points suggest that a good model card may still leave unanswered questions about the actual system a team is using.
The counter-case is also strong. If the question is what a trained model was built to do, what data it was trained on, how its developer evaluated it, or what limitations the developer already identified, the Google paper and DSIT's procurement guidance both point to the model card first. On that reading, a system card does not replace a model card. It builds on one.
One practical way to state the difference is this. A model card helps a buyer or reviewer inspect the model before or during procurement, which is the stage where an organisation is deciding what to buy. A system card helps a team inspect the deployment after the model has been placed into a working system. For readers comparing public documentation released by labs, our page on what each lab publishes, model by model tracks the kinds of documents that appear in practice.
Who uses these documents and what they are for
The MOD guidance says system cards are meant mainly for people developing AI applications, but it also says technically informed risk owners and senior decision makers can use them. The same document argues that a standardised format makes it easier to share information, compare AI systems and avoid leaving out essential details.
DSIT assigns a clearer procurement role to model cards. Its guide says purchasers can use them to test supplier claims about intended use, performance, limitations and risks. In the recruitment setting DSIT describes, that is part of a broader effort to judge whether a system is trustworthy enough for an organisation's use.
DSIT uses the term AI assurance for that broader effort. The department says assurance involves tools, processes and metrics used to evaluate performance, manage risks and support compliance with legal and regulatory requirements in context. It adds that assurance matters at the principles level as well: “AI assurance will play a critical role in the implementation and operationalisation of these principles.”
DSIT also warns against over-reading any one document, whether that document is a model card or something else. The guide states: “There is no one size fits all approach to AI assurance, and no single assurance mechanism is enough to deem an AI system ‘assured’.”
The MOD guidance makes a similar point from the direction of system design. Citing JSP 936, it says AI-enabled systems and their outputs must be appropriately understood by relevant individuals, and it says mechanisms enabling that understanding should be built into the design of the system. In that frame, a card is one mechanism among several, not a full verdict on its own.
So the short answer to the search query is stable across the sources. A model card is documentation for the model. A system card is documentation for the model or models as deployed in a wider system. The harder question is whether the distinction matters. The sources support two steelmanned answers: it matters because deployment can change performance and risk, as DSIT says, and it matters less because the two documents overlap in purpose and often belong in the same assurance workflow.
Frequently asked questions
Is a system card only about one model?
No. The UK Ministry of Defence guidance says a system card can describe the use of one or more AI models deployed into a system.
Who should produce a model card?
DSIT's recruitment guidance says model cards should be produced by the developer of an AI system and made available to the purchasing organisation.
Can a model card replace a system card?
The sources do not say that it can. One reading of the MOD guidance and DSIT guidance is that the documents do different jobs: DSIT says model performance can change with deployment environment, while the MOD guidance says system cards describe models in a deployed system.
Are these cards enough to show that an AI system is assured?
DSIT says no single assurance mechanism is enough on its own to deem an AI system assured. Its guide presents model cards as one tool within a wider assurance process.
Caveats: The direct definition and audience for system cards in this article come from one source, the UK Ministry of Defence guidance published on 27 February 2026. DSIT's guide discusses model cards and deployment-stage assurance in detail, but it does not separately define system cards.