Skip to main content
Bureau of AI
Category: Content Transparency & Labelling

System Card

Also known as: AI Transparency Card, AI Model Card
Simply put

A system card is a documentation artifact that describes an entire AI system, including what it can do and how it has been tested for safety, rather than covering only a single model within that system. Providers of AI models, such as OpenAI and Anthropic, publish these documents to make information about a system's capabilities and safety evaluations more transparent. The term is sometimes used interchangeably with 'AI Model Card' or 'AI Transparency Card,' though some practitioners distinguish a system card (whole system) from a model card (individual model).

Formal definition

As commonly used by AI model providers, a system card is a standardized documentation artifact describing an entire AI system, including its capabilities and a range of safety evaluations, as distinct from documentation scoped to individual constituent models. In practice, published examples (for instance, the OpenAI o1 System Card and Claude Opus 4.6 System Card) present capability assessments alongside safety and evaluation results. Terminology is not fully settled: the evidence indicates the label is sometimes applied as a synonym for 'AI Model Card' or 'AI Transparency Card,' but at least one source draws a functional distinction between a system card (entire system) and a model card (individual model). A common point of error is conflating 'system card' with the unrelated smart-card 'Card Operating System (COS)'; these share no conceptual relationship. This entry does not assert any binding regulatory requirement to produce system cards, and the format, scope, and contents are provider-defined rather than governed by a single authoritative standard in the evidence provided.

Why it matters

System cards have become a primary vehicle through which AI model providers communicate what a system can do and how it has been evaluated for safety. As AI systems are deployed into higher-stakes settings, the ability to review a provider's own account of capabilities and safety evaluations before adoption is increasingly important to compliance officers, risk managers, and procurement teams. A system card scoped to an entire system, rather than to a single constituent model, can offer a more complete picture of behavior in deployment, since real-world systems often combine models with tooling, guardrails, and other components.

The transparency value of a system card, however, depends on understanding its limits. Based on the evidence available here, there is no single authoritative standard that governs the format, scope, or required contents of a system card; these are provider-defined. Published examples such as the OpenAI o1 System Card and the Claude Opus 4.6 System Card demonstrate the practice but also illustrate that contents and structure vary by provider. Readers should therefore treat a system card as provider-authored disclosure rather than as an independently audited or standardized certification, and should not assume that its existence satisfies any particular regulatory obligation.

Terminology adds a further reason for care. The label 'system card' is sometimes used interchangeably with 'AI Model Card' or 'AI Transparency Card,' yet at least one source draws a functional distinction between a system card (the whole system) and a model card (an individual model). Professionals relying on these documents for governance decisions should confirm the intended scope in each case rather than assuming the terms are equivalent.

Who it's relevant to

Model Risk Managers and Validators
System cards offer provider-authored information about system capabilities and safety evaluations that can inform independent validation work. Because these documents are not independently audited and their scope is provider-defined, they should be treated as one input rather than a substitute for independent testing, and the scope (whole system versus individual model) should be confirmed.
Compliance and Governance Officers
For those overseeing AI adoption, system cards can support transparency and due-diligence processes by documenting what a system does and how it has been evaluated. This entry does not assert any binding regulatory requirement to produce or rely on system cards, so their presence should not be assumed to satisfy a specific legal obligation.
Procurement and Vendor Assessment Teams
When evaluating third-party AI systems, teams can use published system cards, such as those released by OpenAI and Anthropic, to review stated capabilities and safety evaluations. Reviewers should note that format and contents vary by provider and are not governed by a single authoritative standard in the evidence available.
Data Scientists and AI Engineers
For technical practitioners, a system card describing an entire AI system can clarify how a model behaves within a broader deployment context, including tooling and safeguards, rather than in isolation. Practitioners should confirm whether a given document is scoped to the full system or to an individual model, as terminology is not fully settled.

Inside System Card

System-level scope
A system card typically documents an AI system as a whole—including one or more models, their surrounding components, and the deployment context—rather than a single model in isolation, distinguishing it from a narrower model card.
Intended use and out-of-scope uses
A description of the purposes the system is designed for and, as commonly recommended, the uses that are unsupported, discouraged, or explicitly out of scope.
Capabilities and limitations
A summary of what the system can and cannot reliably do, including known constraints and conditions under which performance may vary or degrade.
Evaluation and testing summary
An account of the assessments performed on the system, which may cover performance, safety, and other testing; the specific evaluations included vary by publisher and are not standardized across all contexts.
Risk and safety considerations
A discussion of identified risks and the mitigations or safeguards applied, typically framed as measures that reduce or manage—rather than eliminate—those risks.
Data and provenance context
Where disclosed, information about the data or inputs relevant to the system's behavior, though the depth of such disclosure differs substantially across published system cards.
Deployment and operational context
Notes on the environment, integrations, and human oversight arrangements in which the system operates, reflecting that risks depend heavily on how and where the system is used.

Common questions

Answers to the questions practitioners most commonly ask about System Card.

Is a system card the same thing as a model card?
Not exactly, and professionals frequently blur the two. A model card typically documents a single model's characteristics, intended use, performance, and limitations, whereas a system card is generally scoped to a broader deployed system that may combine one or more models with surrounding components, guardrails, and usage context. In practice, the terms are used inconsistently across organizations, and some publishers use 'system card' to describe what others would call a model card. Confirm the intended scope of any given artifact rather than assuming a fixed definition.
Does publishing a system card mean the system is compliant or its risks have been eliminated?
No. A system card is a documentation and transparency artifact; it describes a system and, in many cases, the mitigations applied. It does not by itself demonstrate compliance with any particular regulatory framework, nor does it eliminate risk. At most, documentation of this kind can support risk management and governance processes by making a system's characteristics and limitations more visible. Whether it satisfies a specific legal or supervisory expectation depends on the applicable jurisdiction and framework, which vary.
What information is typically included in a system card?
Contents vary by publisher and are not standardized, but system cards commonly describe the system's intended use and out-of-scope uses, its general architecture or components, known limitations, evaluation or testing results, and any mitigations or safeguards applied. Because there is no single authoritative template, the level of detail and the categories covered differ substantially between organizations.
Who is typically responsible for producing and maintaining a system card?
Responsibility is not fixed by any universal standard and depends on how an organization structures its roles. In many settings, teams that build or deploy the system draft the card, while governance, risk, or compliance functions may review it. Where organizations use a lines-of-defense model, the developer or deployer often sits in the first line and independent review may sit in a second or third line, but assigning these responsibilities is an organizational choice rather than a requirement imposed by the artifact itself.
How does a system card relate to model validation or model risk management documentation?
A system card serves a transparency and communication purpose and is generally distinct from validation or model risk management documentation, which is typically more detailed, internal, and oriented toward independent assessment of risk. A system card may reference or summarize evaluation results, but it does not usually substitute for the fuller documentation that validation processes produce. Where an organization operates under model risk management guidance, it should treat the system card as a complement to, not a replacement for, its risk documentation.
How often should a system card be updated?
There is no universally mandated update cadence. As commonly practiced, a system card is revised when material changes occur to the system, such as changes to its components, intended use, evaluation results, or known limitations. Because a system can change over time and its documented characteristics can become outdated, organizations typically tie updates to their change-management and monitoring processes rather than to a fixed schedule.

Common misconceptions

A system card and a model card are the same thing.
As commonly used, a model card documents an individual model, whereas a system card typically covers a broader AI system that may include multiple models and surrounding components in a deployment context. The terms are related but are not interchangeable.
Publishing a system card is a legally mandated, standardized disclosure with a fixed format.
System cards are largely a voluntary transparency and documentation practice whose content and structure vary by publisher. There is no single authoritative template that applies universally, and their contents should not be assumed to satisfy any specific legal or regulatory requirement without independent verification.
A system card demonstrates that a system's risks have been eliminated.
A system card describes identified risks and the mitigations applied, which are measures intended to reduce or manage risk. Documentation of safeguards does not establish that residual risk has been removed.

Best practices

Clearly distinguish system-level documentation from model-level documentation, and state explicitly whether the card covers a single model or a broader system so readers understand the scope.
Specify both intended uses and out-of-scope or discouraged uses, since risk assessments depend on deployment context rather than the model alone.
Describe evaluations and their limitations honestly, avoiding language that implies risks have been eliminated; frame safeguards as measures that reduce or manage residual risk.
Use qualified language when describing capabilities and testing, noting the conditions under which performance was measured and where results may not generalize.
Treat the system card as a living document, updating it when the system, its components, or its deployment context materially change.
Do not represent a system card as satisfying any particular legal or regulatory obligation unless that alignment has been independently verified for the relevant jurisdiction.