How to Write an AI System Card: Template and Examples
An AI system card is a governance document for a deployed AI-enabled application or agent. It records what the system is intended to do, who uses it, what models and data it depends on, what tools it can access, what risks and limitations are known, what controls are in place, how it was evaluated, and who owns ongoing oversight. Unlike a model card, an AI system card should describe runtime behavior, permissions, monitoring, human approval points, auditability, and lifecycle governance.
What an enterprise AI system card should capture
A useful AI system card gives reviewers a clear view of the deployed system, not only the model behind it. It should make the system purpose, deployment context, data dependencies, runtime behavior, control environment, evaluation evidence, and ownership understandable to governance, security, legal, risk, and operational teams.
The document is most valuable when it is practical enough to support deployment review and ongoing oversight. For AI-enabled applications and agents, that means documenting what the system can do at runtime, what it is allowed to access, what must be approved by a human, and what evidence is retained after execution.
What is an AI system card?
An AI system card documents a deployed AI-enabled application or agent. It records the system purpose, intended users, model and data dependencies, tool access, known risks and limitations, implemented controls, evaluation evidence, and ownership for ongoing governance.
The distinction matters because enterprise AI risk does not come only from the model. Risk also comes from the way the model is embedded in a workflow, the data it can retrieve, the tools it can call, the actions it can take, and the level of human oversight required before those actions are completed.
Practical definition
An AI system card should help an enterprise answer a concrete question: what is this AI system intended to do, what can it access or change, what controls limit its behavior, how was it evaluated, and who is accountable for its operation?
AI system card vs. related governance documents
Unlike a model card, an AI system card should describe runtime behavior, permissions, monitoring, human approval points, auditability, and lifecycle governance. A model card can explain model-level purpose, limitations, and evaluation results. An AI system card should go further by explaining how the model is used inside the deployed system.
For systems that use agents, tools, plugins, APIs, retrieval sources, or other integrations, the system card should make the runtime environment visible. Reviewers need to understand not only what the system can generate, but what it can do.
| Area | Model card focus | AI system card focus |
|---|---|---|
| Object documented | The model and its known behavior. | The deployed AI-enabled application or agent. |
| Runtime behavior | May be limited or not described. | Documents permissions, monitoring, approval points, auditability, and lifecycle governance. |
| Dependencies | Model-level information and evaluation context. | Models, data, prompts, retrieval sources, integrations, tools, and output destinations. |
| Operational control | Explains limitations and evaluation results. | Explains controls, residual risks, ownership, review cadence, and evidence retained after execution. |
AI system card template for enterprise use
The supplied AI system card template organizes documentation around the information enterprise reviewers need for deployment and oversight. The sections below translate the template into a practical structure that can be used for an AI-enabled application or agent.
Purpose and scope
Document the business objective, intended users, supported tasks, prohibited uses, and deployment context. This section should make clear what the system is designed to support and where its use should stop.
Architecture and data
Document the models, prompts, retrieval sources, integrations, data classifications, retention, and output destinations. This gives reviewers a clear understanding of the system dependencies and the information that may flow through the system.
Runtime controls
Document agent identity, tool permissions, policy enforcement, approval gates, logging, and fallback behavior. For agentic systems, this section is central because it explains how the enterprise limits what the system can do.
Evidence and ownership
Document evaluation results, residual risks, incidents, approvals, responsible owners, and review cadence. The card should support ongoing governance rather than serving as a one-time approval artifact.
| Template area | What to record | Why it matters |
|---|---|---|
| Purpose and scope | Business objective, intended users, supported tasks, prohibited uses, and deployment context. | Clarifies intended use and boundaries for reviewers and operators. |
| Architecture and data | Models, prompts, retrieval sources, integrations, data classifications, retention, and output destinations. | Makes dependencies and data movement visible. |
| Runtime controls | Agent identity, tool permissions, policy enforcement, approval gates, logging, and fallback behavior. | Shows how runtime agency is limited and governed. |
| Evidence and ownership | Evaluation results, residual risks, incidents, approvals, responsible owners, and review cadence. | Supports auditability, accountability, and lifecycle governance. |
AI system card examples by system type
AI system cards should be adapted to the system being reviewed. The same core questions apply across deployed AI-enabled applications and agents, but the emphasis changes depending on the system behavior, access, and permissions.
AI-enabled application
For a deployed AI-enabled application, the system card should explain the purpose, users, data dependencies, known risks and limitations, evaluations, controls, oversight model, and ownership.
AI agent with tool access
For an AI agent, the system card should describe which tools it can call, what permissions those tools carry, whether actions require human approval, how policy is enforced, and what evidence is retained after execution.
System using retrieval sources
For a system that relies on retrieved context, the card should document retrieval sources, data classifications, prompts, output destinations, monitoring, and evaluation evidence.
System with human approval points
For workflows that require review before execution, the card should show approval thresholds, escalation ownership, fallback behavior, and the audit trail used to investigate behavior.
How to document runtime governance for AI agents
Runtime behavior is where many AI system cards are too thin. For AI agents and AI-enabled applications, reviewers need to understand not only what the system can generate, but what it can do. This includes which tools it can call, what permissions those tools carry, whether actions require human approval, how policy is enforced, and what evidence is retained after execution.
Excessive agency is a practical risk in LLM-based systems when the system can invoke functions, tools, plugins, or APIs. The system card should show how the enterprise limits that agency. Useful fields include allowed actions, denied actions, approval thresholds, tool-call scopes, execution environment, fallback behavior, monitoring coverage, and incident escalation ownership.
The system card should also document the audit trail. Depending on legal, security, and operational requirements, this may include prompts or prompt metadata, retrieved context, tool calls, approvals, errors, policy violations, user feedback, and incident links. The goal is not to log everything by default. The goal is to record what is necessary to investigate behavior, demonstrate control operation, and support ongoing governance.
-
Describe what the system can do
List the tools, functions, plugins, or APIs the system can call, and document the permissions those actions carry.
-
Set limits on agency
Record allowed actions, denied actions, tool-call scopes, approval thresholds, and fallback behavior.
-
Show how policy is enforced
Explain monitoring coverage, policy enforcement, human approval points, and incident escalation ownership.
-
Define the audit trail
Document the evidence retained after execution, including the information needed to investigate behavior and demonstrate control operation.
Implementation guidance for governance leaders
Governance leaders should treat the AI system card as a living record of the deployed system. It should help teams understand purpose, risk, control operation, evaluation evidence, ownership, and review cadence throughout the lifecycle of the system.
The strongest system cards are specific about runtime behavior. They document tool permissions, human approval points, monitoring, auditability, and escalation ownership in a way that can be used by governance, security, legal, and operational teams.
Implementation note
The goal is not to log everything by default. The goal is to record what is necessary to investigate behavior, demonstrate control operation, and support ongoing governance.
Frequently asked questions
What is an AI system card?
An AI system card is a governance document for a deployed AI-enabled application or agent. It records purpose, users, dependencies, risks, controls, evaluations, oversight, and ownership.
How is an AI system card different from a model card?
Unlike a model card, an AI system card should describe runtime behavior, permissions, monitoring, human approval points, auditability, and lifecycle governance.
What should an AI agent system card include?
It should include tool access, permissions, approval thresholds, policy enforcement, monitoring coverage, fallback behavior, audit trail requirements, and incident escalation ownership.
Govern AI agents at runtime
Trussed AI provides runtime governance and security for enterprise AI agents, including policy enforcement, monitoring, controls, agent identity, permissions, tool approval workflows, and audit logging.
Request a Demo