A model card is a structured description of a model's technical attributes. The practice traces back to a 2019 academic proposal recommending standardized reporting of model performance across different conditions. In current industry practice, a model card typically covers architecture, a summary of training data, intended use cases, out-of-scope uses, evaluation metrics, and known limitations or biases. Anthropic's published Claude model cards follow this pattern, disclosing training data sources, intended uses, evaluation results, and limitations.
A system card covers more ground. Rather than describing only the underlying model, it documents the broader deployed system: safety testing methodology, red-teaming results, guardrails, and monitoring mechanisms. OpenAI's system cards for models like GPT-4 and GPT-4o are structured this way, describing safety evaluations and risk mitigations at the system level rather than the model level alone. Google has published comparable system-level documentation for Gemini covering responsible AI practices and impact assessments.
The distinction matters for governance teams because a model card and a system card answer different questions. A model card tells you what the model was trained on and how it performs on benchmarks. A system card tells you what happens when that model is deployed with specific safeguards, integrations, and oversight. Enterprises evaluating third-party AI need to know which document they are looking at, because risk-relevant detail, such as guardrails or monitoring, may only appear in system-level documentation.
Two Layers of AI Documentation
Architecture, training data summary, intended use, evaluation metrics, known limitations.
Deployment context, safety testing, red-teaming findings, guardrails, monitoring mechanisms.
Feeds risk registers, procurement approval records, and audit trails.
Why This Matters for Enterprise Governance
Enterprises deploying AI models and agentic systems face a documentation gap. Without standardized descriptions of model behavior, training data, evaluation results, and risk considerations, governance teams cannot consistently assess risk, enforce policy, or support audits. This gap is more acute now that organizations are evaluating models from multiple vendors, each publishing documentation in a different format.
Hugging Face addresses part of this problem for openly shared models through a YAML-based model card template that structures intended use, limitations, and training data in a machine-readable way. Frontier system cards from providers like OpenAI, Anthropic, and Google are typically narrative documents, PDF or web-based, which makes them harder to compare programmatically across vendors. There is no single universally adopted schema. This means governance teams evaluating a multi-vendor AI portfolio need an internal normalization process to make model cards and system cards comparable, rather than assuming vendor documentation arrives in a consistent format.
NIST's AI Risk Management Framework treats documentation of AI system design, data, and performance characteristics as supporting evidence for its Map, Measure, and Govern functions. It does not mandate a specific card format, and it is voluntary guidance rather than binding regulation. The EU AI Act takes a firmer regulatory position, requiring providers of high-risk AI systems to maintain technical documentation describing system design, data governance, and risk mitigation measures, though it also does not prescribe a specific card template.
What Governance Teams Should Require From Vendors
When evaluating a third-party model or agentic system for procurement, governance teams should first determine whether the vendor is providing a model card, a system card, or both, and what deployment context the documentation actually covers. A vendor that supplies only a model-level card may be omitting the safeguards and monitoring detail that a governance review actually needs.
Documentation should be version-controlled and explicitly tied to the model version or configuration in production. Fine-tuning, retraining, or reconfiguration can change a model's risk characteristics, and some providers version their cards alongside releases to reflect this. If a vendor cannot confirm that the documentation matches the currently deployed version, that gap should be treated as an identified risk factor in the governance review, not something to resolve later.
Evaluation depth also varies significantly. Some cards provide benchmark performance tables; others offer only qualitative descriptions of safety testing categories such as harmful content, bias, or misuse potential. Governance teams should ask directly what training data sources and evaluation methodologies are disclosed, and what is explicitly out of scope or undisclosed. Where possible, ask whether the vendor can map their documentation format to recognized frameworks such as NIST AI RMF categories, which makes internal governance mapping more tractable.
| Question | Model card | System card |
|---|---|---|
| What was it trained on and how does it perform? | Typically covered | May reference, not primary focus |
| What guardrails and monitoring exist in deployment? | Usually not covered | Typically covered |
| What red-teaming or safety testing was performed? | Rarely covered | Typically covered |
| Is documentation tied to the deployed version? | Ask explicitly | Ask explicitly |
From Documentation to Runtime Governance
Model cards and system cards describe intended behavior and known limitations at a point in time. They do not, by themselves, enforce anything once a model or agent is deployed. A card can disclose that a model has certain limitations or is out of scope for certain uses, but it cannot prevent an agent from being invoked outside that scope, or confirm that guardrails described on paper are actually active in a live deployment.
This is the practical link between documentation and runtime governance. The limitations, intended use boundaries, and risk considerations captured in a model card or system card are exactly the inputs that should inform permissioning decisions, monitoring rules, and policy enforcement for deployed AI agents. If a system card discloses that a model was not evaluated for a particular task category, that finding should translate into a runtime control restricting the agent from that task, not just a note in a procurement file.
Where Trussed AI fits
Trussed AI provides runtime governance and security for enterprise AI agents, including runtime policy enforcement, runtime monitoring, agent identity and permissions, least privilege controls, tool approval workflows, and audit logging. These capabilities operate on the deployed system, which is where documented limitations and risk considerations from model cards and system cards need to be enforced in practice, and where audit logging can demonstrate that the enforcement actually occurred.