What is the difference between a system card and a model card?

A system card describes the deployed LLM system, including safeguards, testing, limitations, and risk findings tied to real use. A model card focuses on the model itself, such as training context and model characteristics. For practitioners, the system card is more operational because it helps assess how the model will behave in an application, not just what the base model is.

Why System Cards and Model Cards Answer Different Practitioner Questions

The distinction matters because a model card describes the artifact you are evaluating, while a system card describes the service or application you are actually deploying. That difference changes what risk, governance, and operational context a reader can trust. A model can look acceptable in isolation, yet still behave differently once wrapped with retrieval, tools, filters, policies, or monitoring. For that reason, system cards are usually more decision-relevant for deployment review, incident preparedness, and user-facing assurance. When teams treat them as interchangeable, they often overread model-level documentation and miss the integration-specific constraints that shape real-world behaviour. In practice, many security and AI governance teams discover that the documentation gap only becomes visible after the model has already been embedded into a production workflow.

How the Two Documents Work Together in Practice

A model card is typically the starting point for understanding the model itself. It should describe training context, intended use, known limitations, evaluation scope, and any material caveats about the base model. A system card should extend that view to the deployed experience: what guardrails were added, how the model is configured, what external data it can reach, which human controls remain in place, and what testing has been done against the actual system behaviour. That is why the same base model can warrant different system cards across different products, because the surrounding controls, prompts, tools, and policy layers alter the risk profile.

Practitioners should read a system card as evidence about the operating environment, not just the model. If a deployment introduces retrieval, plugins, tool execution, or user-specific context, the system card becomes the more useful document for assessing misuse, leakage, and unsafe output pathways. If the documentation only states model-level characteristics, it may be sufficient for research comparison but not for operational assurance. The best reviews compare both documents together: the model card explains what was trained, and the system card explains what is now exposed, constrained, or monitored in production.

Use the model card to understand baseline characteristics and known model limits.
Use the system card to assess deployed safeguards, monitoring, and residual risk.
Check whether application-specific controls change behaviour in ways the model card cannot capture.
Verify that the testing evidence matches the actual deployment, not just a standalone model benchmark.

Authoritative guidance on model documentation is available in the NIST AI Risk Management Framework, which is useful for understanding how documentation supports governance, even though it does not replace deployment-specific review. Where systems include connected tools or automated actions, the operational documentation should also be read alongside the OWASP Non-Human Identity Top 10 because delegated access paths can materially alter the system’s real risk posture.

The guidance breaks down when organisations treat either document as a marketing artifact rather than evidence of actual controls and testing.

Where the Difference Gets Blurry, and Why That Still Matters

Tighter documentation often increases overhead, requiring organisations to balance assurance value against the cost of keeping the material current.

Some organisations blur the boundary by publishing a “system card” that is really just a repackaged model card, or by attaching operational claims that are not tied to the deployed environment. That is a governance problem, not just a terminology issue, because it creates false confidence about safeguards, thresholds, and monitoring. The distinction is also less clean when a vendor controls both the base model and the deployment layer, but even then the two perspectives remain useful: one tells you what the model is, the other tells you how it is being used. Industry practice is still evolving, so readers should treat naming conventions cautiously and focus on the evidence each document actually contains.

For regulated or high-impact use cases, the practical test is whether the document helps answer a deployment question that a model card alone cannot answer. If it does not address prompt injection exposure, tool permissions, escalation paths, logging, or human oversight in the live system, then it may not deserve the “system card” label in any meaningful operational sense. That is especially important when a product claims safety from the model’s design while the real risk emerges from how the application is assembled.

In practice, teams often inherit documentation that is accurate in principle but too abstract to support an approval decision, and that gap usually appears only when the system is already under review.

Risk and Threat Considerations

The main risk is documentation mismatch: teams may rely on model-level assurances while the deployed system introduces new exposure through tools, retrieval, policy layers, or external connections. That can leave reviewers blind to unsafe runtime behaviour, access scope, or failure modes that do not exist in the base model alone.

Failure mechanism: The gap emerges when operational controls, connected services, or delegated actions are not captured in the deployment documentation, so reviewers assume the model card reflects the real system. Adversarial or accidental misuse can then exploit the broader application surface rather than the model in isolation.

Impact: Organisations can approve a system without understanding its actual attack surface, data exposure paths, or escalation possibilities, which weakens assurance, incident readiness, and accountability.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 address the attack surface, NIST AI RMF, NIST CSF 2.0 and CIS Controls v8 set the technical controls, and ISO/IEC 42001:2023 define the regulatory obligations.

Framework	Control / Reference	Relevance
NIST AI RMF	GOVERN — Govern	AI documentation supports governance and accountability for model and system risk.
Recommendation — Use governance processes to ensure documentation reflects the deployed AI system, not only the base model.
ISO/IEC 42001:2023	8.1 — Operational planning and control	System cards support operational control over AI deployment and lifecycle changes.
Recommendation — Maintain deployment documentation that tracks controls, monitoring, and operational changes.
NIST CSF 2.0	GV.RM-01 — Risk management strategy established and agreed to	Comparing model and system cards is a governance and risk-communication activity.
Recommendation — Align documentation review to your organisation's AI risk management strategy.
CIS Controls v8	4 — Secure Configuration of Enterprise Assets and Software	System cards should reflect runtime configuration and control differences from the base model.
Recommendation — Document and verify the deployed configuration that shapes real system behaviour.
OWASP Agentic AI Top 10	A1 — Agentic Access Control	Only if the system card covers tool-enabled autonomous behaviour and delegated actions.
Recommendation — Map tool-enabled actions to explicit access controls and review delegated permissions.

Practitioner Guidance

What to verify: Confirm that the system card describes the live deployment, including external tools, access boundaries, oversight points, and residual risks that the model card cannot express. If those elements are missing, treat the document as incomplete for approval or risk acceptance.

Decision rule: Use the model card for baseline model evaluation, but use the system card for deployment decisions. If a document does not change how you would assess operational risk, it is probably not a true system card in practice.

Common mistake: Treating model documentation as if it proves safety in the deployed workflow. The most useful review asks what changed after the model was embedded, because that is where the real governance burden usually appears.

Practitioner takeaway: The value of the distinction is not semantic precision, but whether the documentation lets you judge the actual system you are exposing to users, data, and action.