L8.5.2 — System cards, data sheets & AI-BOM revisited¶
Type: Theory · Duration: ~5 min · Status: Mandatory Module: Module 8 — AI Governance, Risk & Compliance Framework tags: NIST AI RMF Govern 1.3, Map 4.1 · EU AI Act Annex IV (technical documentation)
Learning objectives¶
- Distinguish model card from system card and identify when each applies.
- Identify the role of a data sheet and the AI-BOM in the documentation stack.
Core content¶
Model card vs system card¶
Model card (L8.5.1): describes a single trained model artifact.
System card: describes a complete AI system — the model + its application surrounding + its deployment context. A system card may reference multiple models, multiple data sources, multiple decision pathways.
The distinction: - Model card = "here's the model, what it does, its evaluation." - System card = "here's the whole thing — model, retrieval pipeline, tools, agents, UI, monitoring — and how it interacts with users."
System cards emerged as a 2023-2024 norm (OpenAI's "System Card for GPT-4," Anthropic's similar artifacts) to address the gap that model cards alone don't describe how a model is actually deployed. A GPT-4 model card describes GPT-4; the ChatGPT system card describes ChatGPT-the-product.
For an application team in 2026: you author model cards for any models you fine-tune; you author a system card for your AI product as deployed.
When to write each¶
| Artifact | Audience | When to author |
|---|---|---|
| Model card | ML community, downstream users of the model | When you train or fine-tune a model others will use |
| System card | Customers, regulators, internal stakeholders | When you deploy an AI product |
| Data sheet | ML researchers, data governance reviewers | When you curate / publish a dataset |
| AI-BOM | Security teams, auditors, supply-chain reviewers | Always; auto-generated per release |
A single AI product might have: a system card (for the product), N model cards (one per fine-tuned model), a data sheet (for any curated training/eval datasets), and an AI-BOM (the inventory of everything). Plus an EU AI Act Article 11 documentation package that consolidates the above.
Data sheets (Gebru et al. 2018)¶
Data sheets for datasets describe a dataset the way a model card describes a model. Structure (adapted from Gebru et al. 2018):
- Motivation — why was the dataset created?
- Composition — what's in it; how much; statistical properties.
- Collection process — how was it gathered; consent; legal basis.
- Preprocessing / cleaning — what was modified before publication.
- Uses — what's it appropriate for; what should it not be used for.
- Distribution — license; access controls.
- Maintenance — who maintains it; how is it updated; how to report issues.
Most production teams don't author data sheets for their internal fine-tune datasets — but for published datasets (research, open-source, customer-facing), it's expected. The EU AI Act Article 10 data governance requirements effectively require this level of dataset documentation for high-risk systems.
AI-BOM revisited (from M4 L4.5.2)¶
Module 4 introduced the AI Bill of Materials as an inventory. Module 8 adds the governance lens:
- The AI-BOM is the provenance backbone that ties together model cards, system cards, data sheets.
- For EU AI Act Article 11, the AI-BOM is implicit in Annex IV Section 2 (detailed description of system elements) — most teams produce a CycloneDX-AI document and reference it from the Article 11 package.
- For procurement (L8.3.2), the AI-BOM is the artifact customers ask for.
Treat the AI-BOM as the single source of truth that the other documentation references. Don't re-state the AI-BOM contents in each model card; reference the AI-BOM.
The full documentation stack¶
For an EU AI Act-compliant, well-governed AI product, the full documentation stack:
EU AI Act Article 11 / Annex IV package
├── System card (deployment-level overview)
│ ├── References model card(s) — one per model
│ ├── References data sheet(s) — one per curated dataset
│ ├── References AI-BOM — single inventory artifact
│ ├── References threat model (L2.6)
│ ├── References eval reports (L7.7, L7.8)
│ ├── References IR playbook (L7.6.1, L7.9)
│ └── Risk register extract
├── Model card(s)
├── Data sheet(s) [if applicable]
└── AI-BOM (CycloneDX-AI)
Each artifact has its purpose. Together they form the package an enterprise customer / auditor / regulator can consume.
What L8.7 builds¶
L8.7 walks you through authoring a system card + model card + risk assessment for the M1 RAG app. It's a light-depth pass — not a 200-page production package — but the right shape. You'll know what each artifact looks like by the end.
Real-world example¶
OpenAI's GPT-4 System Card (March 2023) and Claude system cards (across versions) are the most-cited 2026 examples of system-card-as-public-artifact. Both publish risk assessments, evaluation results, and deployment-context information at meaningful depth. Read 2-3 of each before authoring your own.
Key terms¶
- Model card — single trained model artifact documentation.
- System card — complete AI system (model + application + deployment) documentation.
- Data sheet — dataset documentation (Gebru et al. structure).
- AI-BOM — inventory backbone; ties the other documentation together.
- Documentation stack — the integrated package: Article 11 + system card + model cards + data sheets + AI-BOM.
References¶
- Gebru et al., "Datasheets for Datasets" (2018) — https://arxiv.org/abs/1803.09010
- OpenAI System Cards (per major model release).
- Anthropic Responsible Scaling Policy + system cards.
- L4.5.2 (AI-BOM introduction).
Quiz items¶
- Q: Distinguish a model card from a system card. A: Model card describes a single trained model artifact. System card describes a complete AI system — model + application + deployment context. May reference multiple models, multiple data sources, multiple decision pathways.
- Q: What does a data sheet describe and when do you author one? A: A dataset (Gebru et al. structure: motivation, composition, collection, preprocessing, uses, distribution, maintenance). Author when you curate or publish a dataset; required for EU AI Act high-risk systems' training datasets.
- Q: What's the role of the AI-BOM in the documentation stack? A: Provenance backbone — single source of truth that the other documentation references. For EU AI Act Article 11, supports Annex IV Section 2 (detailed description of system elements). For procurement, the artifact customers ask for.
Video script (~600 words, ~4.5 min)¶
[SLIDE 1 — Title]
System cards, data sheets, and AI-BOM revisited. Five minutes.
[SLIDE 2 — Model card vs system card]
Model card from last lesson describes a single trained model artifact. System card describes a complete AI system — model plus application surrounding plus deployment context. May reference multiple models, multiple data sources, multiple decision pathways.
Distinction: model card equals "here's the model, what it does, its evaluation." System card equals "here's the whole thing — model, retrieval pipeline, tools, agents, UI, monitoring — and how it interacts with users."
System cards emerged as 2023-2024 norm — OpenAI's GPT-4 System Card, Anthropic's similar artifacts — to address the gap that model cards alone don't describe how a model is actually deployed.
For an application team in twenty-twenty-six: you author model cards for any models you fine-tune. You author a system card for your AI product as deployed.
[SLIDE 3 — When to write each]
Quick matrix. Model card: ML community, downstream users; author when you train or fine-tune. System card: customers, regulators, internal stakeholders; author when you deploy an AI product. Data sheet: ML researchers, data governance reviewers; author when you curate or publish a dataset. AI-BOM: security teams, auditors, supply-chain reviewers; author always, auto-generated per release.
Single AI product might have a system card for the product, N model cards (one per fine-tuned model), a data sheet for any curated datasets, an AI-BOM (inventory of everything). Plus an EU AI Act Article 11 package that consolidates.
[SLIDE 4 — Data sheets]
Data sheets for datasets — Gebru et al, 2018. Describe a dataset the way a model card describes a model. Structure: motivation, composition, collection process, preprocessing and cleaning, uses, distribution, maintenance.
Most production teams don't author data sheets for internal fine-tune datasets. For published datasets — research, open-source, customer-facing — expected. EU AI Act Article 10 data governance requirements effectively require this level of dataset documentation for high-risk systems.
[SLIDE 5 — AI-BOM revisited]
Module 4 introduced AI Bill of Materials as inventory. Module 8 adds governance lens. AI-BOM is provenance backbone tying together model cards, system cards, data sheets. For EU AI Act Article 11, implicit in Annex IV Section 2. Most teams produce a CycloneDX-AI document and reference it from the Article 11 package. For procurement, the artifact customers ask for.
Treat AI-BOM as single source of truth. Other documentation references the AI-BOM rather than re-stating contents.
[SLIDE 6 — Full documentation stack]
Full documentation stack for a well-governed AI product. EU AI Act Article 11 package at top, references system card. System card references model cards, data sheets, AI-BOM, threat model from L2.6, eval reports from L7.7 and L7.8, IR playbook from L7.6.1 and L7.9, risk register extract. Each artifact has its purpose. Together they form the package an enterprise customer, auditor, regulator can consume.
[SLIDE 7 — L8.7 + up next]
L8.7 walks you through authoring a system card plus model card plus risk assessment for the M1 RAG app. Light-depth pass, but right shape. You'll know what each artifact looks like by the end.
Next: case study teardown — a 2025 AI incident walked end-to-end. Five minutes.
Slide outline¶
- Title — "System cards, data sheets & AI-BOM revisited".
- Model card vs system card — split with example: "GPT-4 model card" vs "ChatGPT system card."
- When to write each — matrix from lesson body.
- Data sheets — Gebru et al. structure as 7-bullet list.
- AI-BOM revisited — single-source-of-truth diagram (other artifacts reference it).
- Full documentation stack — tree diagram from lesson body.
- L8.7 + up next — lab callout + pointer.
Production notes¶
- Recording: ~4.5 min. Cap 5.
- Slide 6 (full doc stack) is the consolidating visual for the module.