A model card tells you about the engine. But nobody drives an engine — they drive a car, with brakes, seatbelts, a dashboard, and a manual. AI system cards document the whole vehicle: the model plus everything around it that determines whether the deployed system is safe and trustworthy.
The term was popularized by Meta, which began publishing system cards for its AI-driven products — describing not just the underlying models but the ranking systems, integrity safeguards, and user controls wrapped around them. The idea has since spread as organizations realized that model-level documentation leaves most deployment questions unanswered.
This guide explains what system cards cover, how they differ from model cards, and why they matter. For the governance framework they serve, see my overview of AI governance.
Why should you care? Because system cards are becoming the primary public window into how major AI systems actually work — what data they use, how they’re tested, what safeguards exist, and where the limits are. Whether you’re a journalist, a regulator, a customer, or just a curious reader, learning to read them critically is one of the most practical AI literacy skills you can build.
Table of Contents
- Why the Model Is Not the System
- What a System Card Covers
- System Cards vs Model Cards
- Who Publishes Them
- Anatomy of a Good System Card
- What System Cards Miss
- What Readers Should Look For
- How to Write One
- Frequently Asked Questions
Why the Model Is Not the System
Consider a social media feed. The underlying model might predict “engagement.” But what users experience is shaped by much more: the candidate generation pipeline, the ranking layers, the demotion rules for misinformation, the user controls (hide, snooze, report), the A/B tests running this week, and the human review queues. A model card for the engagement predictor tells you almost nothing about whether the feed is healthy.
This pattern repeats everywhere. A chatbot is a language model plus system prompts, content filters, retrieval layers, rate limits, and escalation paths. A hiring tool is a scoring model plus the UI that presents scores, the humans who interpret them, and the appeal process. Auditing the model while ignoring the system is like crash-testing an engine without the car.
What a System Card Covers
A system card documents the deployed system end to end:
System purpose and context. What the product does, who uses it, and in what settings. The same model deployed as a fun demo versus a hiring tool raises entirely different questions.
Architecture overview. The components beyond the model: data pipelines, pre- and post-processing, filters, human review stages, user-facing controls. A diagram helps enormously.
Safeguards and mitigations. Content filters, rate limits, confidence thresholds, human-in-the-loop checkpoints, kill switches. For each: what it does, how it was tested, and its known gaps.
Evaluation at the system level. Not just model benchmarks, but end-to-end testing: red-teaming the full product, measuring real user outcomes, tracking appeal and override rates.
Monitoring and incident response. What is tracked in production, what triggers alerts, and how incidents are handled. A system without monitoring is a system nobody understands.
User controls and transparency. What users can see and do: explanations, opt-outs, appeal mechanisms, data controls. These are governance features, not just UX.
Known limitations. Where the system struggles, who might be underserved, and what the organization is doing about it.
System Cards vs Model Cards
The distinction is clean:
| Model card | System card | |
|---|---|---|
| Subject | One ML model | The deployed product/system |
| Author | Model developers | Product + integrity teams |
| Covers | Training data, metrics, limitations | Architecture, safeguards, monitoring, user controls |
| Audience | ML practitioners, auditors | Regulators, users, civil society |
| Example | A card for a toxicity classifier | A card for the content moderation system using it |
You need both. The model card answers “does this component work?” The system card answers “does this product behave responsibly?” A perfect model inside a reckless system still produces reckless outcomes.
Who Publishes Them
Meta pioneered the practice with system cards for Facebook Feed, Instagram recommendations, and its generative AI features. Others have followed in various forms:
- Platform companies publish them for recommender and moderation systems, often under regulatory pressure (the EU Digital Services Act requires risk assessments for very large platforms, and system cards are a natural vehicle).
- AI labs publish system cards for flagship models, covering deployment safeguards alongside capabilities.
- Enterprises increasingly write internal system cards for their own AI products as part of governance programs, even when they do not publish them.
Publication is still the exception rather than the rule. Most system cards that exist are internal documents. But the direction is clear: as AI regulation matures, system-level documentation is becoming expected — and the companies that build the habit early will find compliance much easier than those scrambling to document years of deployed systems after a regulation arrives.
Anatomy of a Good System Card
Drawing from the best published examples, a strong system card:
- Opens with a plain-language summary. What the system does, in terms a non-engineer understands.
- Shows the architecture. A diagram of components and data flows. This is the single most informative element.
- Details each safeguard with its purpose, implementation, and testing — honestly noting gaps.
- Reports system-level metrics: not just model accuracy, but prevalence of bad experiences, appeal rates, filter precision/recall in production.
- Describes the human parts: reviewer guidelines, staffing, quality assurance on human decisions.
- Explains user-facing transparency: what users are told, what controls they have.
- Lists limitations and next steps: what is known to be weak and what is being done.
What System Cards Miss
Honest limitations of the format:
- They are self-reported. The company writes about its own system. Independent verification is rare.
- They age quickly. Systems change weekly; cards get updated quarterly at best.
- They can be PR. Vague language and cherry-picked metrics turn documentation into marketing. Readers should look for specifics: numbers, diagrams, named limitations.
- They do not cover business incentives. A system card describes how the system works, not why the company built it that way. Engagement optimization shaped by ad revenue is a governance question no card fully answers.
What Readers Should Look For
System cards vary enormously in quality. When you read one — as a journalist, researcher, customer, or competitor — here’s how to separate substance from PR:
Specificity over adjectives. “Robust safety measures” means nothing. “We ran 12,000 adversarial prompts across 40 categories, blocked 99.1%, and the remaining 0.9% were these failure types” means something. Good cards name numbers, datasets, and procedures.
Named limitations. The most trustworthy part of any card is the “limitations” section. Vague cards say “the system may occasionally produce incorrect information.” Serious cards say exactly what it can’t do, with examples — “the model cannot reliably summarize documents longer than 30 pages” or “safety filters perform worse in these three languages.”
Evidence of process. Look for the evaluation methodology, not just the results. Which benchmarks, how many prompts, who did the red-teaming, what changed as a result. A card that describes its testing process is harder to fake than one that just reports scores.
Version history. A card updated three times with a real changelog shows a living system under active governance. A card from 2023 describing a system that changes weekly is a museum piece — read it as history, not as current documentation.
The skill of reading system cards is increasingly valuable: they’re becoming the primary public window into how major AI systems work. Learn to read them critically, and you’ll see past the marketing to the actual engineering — and its actual limits.
How to Write One
Start smaller than you think. Your first system card doesn’t need to cover every subsystem — pick the highest-impact product, document what you know, and publish it internally. The discipline of writing the first card teaches your team what good documentation looks like, and the second one will be twice as good. Perfection is the enemy here; a rough but honest card beats a polished one that never ships. The organizations with the best system cards all started with a mediocre first draft.
For teams documenting their own AI product:
- Assemble the right authors. You need product, ML, integrity/trust-and-safety, and UX — no single team knows the whole system.
- Start from the user experience and work backward to components. This keeps the card grounded in real impact.
- Diagram first, prose second. The architecture diagram forces clarity about what exists.
- Be specific. “We use human review” is weak. “All high-severity flags go to reviewers trained on a 40-page guideline, with weekly calibration and 5% re-review” is a claim someone can evaluate.
- Publish internally first, gather feedback, then decide what can go public.
- Version it. Date every release; keep the changelog.
Understanding how AI models are trained helps non-ML authors write accurately about the model components, and reviewing deployed AI tools shows how competitors document their systems.
Frequently Asked Questions
An AI system card is a document describing a deployed AI system end to end — not just the underlying model, but the architecture, safeguards, monitoring, user controls, and known limitations. Meta popularized the practice.
A model card documents one machine learning model (training data, metrics, limitations). A system card documents the full deployed product around it (architecture, filters, human review, monitoring, user controls). You need both.
Meta pioneered them for products like Feed and Instagram. AI labs publish them for flagship models, and enterprises increasingly write internal ones. Publication is still the exception, but regulatory pressure is pushing wider adoption.
A plain-language summary, an architecture diagram, detailed safeguards with testing evidence, system-level metrics, human review processes, user transparency features, and honest limitations with next steps.
Not by that name, but regulations like the EU AI Act and Digital Services Act require system-level documentation, risk assessments, and transparency that system cards naturally satisfy. Expect requirements to keep tightening.
