Datasheets, model cards, system cards

Lesson 4 of 5 in Data Governance and Documentation Artifacts for AI.

Because learned behaviour has no source code to read, AI governance runs on documentation artifacts — structured self-disclosures that make a system inspectable by people who were not in the room. Three research proposals became the industry’s standard stack, and each documents a different thing.

Datasheets for Datasets (Gebru et al., 2018) document the data, borrowing the metaphor of an electronics component datasheet. Seven question sections — motivation (why was this created, funded by whom), composition (what is in it, whose data, is it a sample and of what), collection process (how, by whom, with what consent), preprocessing/labelling, uses (intended, performed, inadvisable), distribution (licence, restrictions), and maintenance (who curates it, will it be updated, erasure handling). The intellectual bet: most model failures are data failures, so document the data before anyone trains on it. Cousins exist for specific niches — data statements for NLP corpora (Bender & Friedman), Data Nutrition Labels for at-a-glance quality signals.

Model cards (Mitchell et al., 2019) document the model: details and version, intended use and out-of-scope use, the factors the model is sensitive to, metrics disaggregated across demographic groups and conditions, evaluation and training data, ethical considerations, and caveats. The disaggregation requirement is the heart — a single accuracy number is exactly the kind of claim model cards were invented to break apart.

System cards (the GPT-4/Claude-era genre) document the deployed system: not just a model but its guardrails, filters, retrieval layers, and tools — plus safety evaluations, red-teaming findings, observed failure modes, and mitigations. The distinction matters to buyers: a model card tells you what the engine can do; a system card tells you what the shipped product does after the safety engineering. A deployer integrating a frontier model into a consequential workflow should demand the system-level evidence, because that is the layer their users will actually touch.

Key terms: datasheet, model card, system card, technical documentation, intended purpose

The documentation stack — each layer documents a different thing, for a different reader

  1. Annex IV technical file — The system, for the regulator

    The EU AI Act’s regulator-facing dossier for high-risk systems (Art 11): system description, development process, risk management, data governance, accuracy/robustness/cybersecurity metrics, post-market plan. Drawn from the layers below — teams with real datasheets and model cards assemble it; teams without them reconstruct history under deadline.

  2. System card — The deployed system, for deployers & the public

    Model plus scaffolding: guardrails, filters, tools, retrieval — with safety evaluations, red-team findings, and mitigations. The layer that answers “what does the shipped product actually do?”

  3. Model card — The model, for evaluators & integrators

    Intended and out-of-scope use, disaggregated performance metrics, training and evaluation data, ethical considerations, caveats. One card per model version — a card that outlives its version is misinformation with a DOI.

  4. Datasheets for datasets — The data, for everyone downstream

    Motivation, composition, collection, preprocessing, uses, distribution, maintenance — written by the dataset creator, read by every team that trains on it. The foundation layer: most model failures trace to facts a datasheet would have surfaced.

A bad model card

Model: SentimentAnalyzer-Pro. Description: State-of-the-art sentiment classification using advanced deep learning. Performance: 94% accuracy. Intended use: analysing text sentiment. Limitations: as with all AI, results may vary.

Every sentence fails its job. Which version? Unstated — the card cannot be matched to a deployment. 94% on what? No dataset, no baseline, no disaggregation — accuracy on movie reviews says nothing about customer complaints in Nigerian English. “Analysing text sentiment” restates the product category instead of bounding it — no out-of-scope statement means every misuse is arguably intended. “Results may vary” is a horoscope, not a limitation. This card is worse than nothing: it manufactures diligence-theatre for buyers who check a box that documentation exists.

The same model, documented honestly

Model: SentimentAnalyzer v2.3.1 (fine-tuned RoBERTa-base, Jan 2026 snapshot). Eval: F1 0.91 on held-out English product reviews; F1 0.83 on social-media text; degrades on code-switched and non-English text (F1 0.61 on Spanglish test set). Disaggregated: sarcasm-heavy text −11 points; African-American English −7 points vs standard test set (see table 3). Intended: routing English customer feedback for human review. Out-of-scope: employment/credit decisions, mental-health inference, non-English deployment, any use without human review of negative classifications. Known failure: negation in long sentences. Training data: see datasheet DS-114; contains no data collected after Jan 2026.

Same model — now a governance instrument. A deployer can check fit against their population, an auditor can verify claims, and the out-of-scope list creates a paper trail that makes misuse a documented choice.

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.