Responsible AI
Datasheets, Model Cards, and System Cards
Design documentation for datasets, models, systems, decisions, and changes without treating templates as certification.
By the end you can
- Explain why responsible documentation separates dataset, model, system, decision, change, and incident records and links claims to versioned evidence
- Distinguish Datasheet, Model card, and System card or assurance record
- Identify evidence that connects dataset documentation to change and incident record
- Design a review that moves from identify the object to maintain and retire
The mechanism behind responsible AI documentation
A record should match the object being governed. A dataset, a model, a system, a decision, an incident and a change each need a record of their own. A record communicates evidence and limitations. It does not create evidence that nobody ever collected. Datasheets describe motivation, composition, collection, processing, uses, risks and maintenance of data. Model cards describe model details, intended use, evaluation, factors, limitations and ethical considerations. System cards or assurance cases connect components, workflows, controls and deployment evidence.
Epic Systems reported that its sepsis model scored an area under the ROC curve of 0.76–0.83. Michigan Medicine measured 0.63. The hospital ran the vendor's model against 27,697 of its own patients and 38,455 hospitalizations, between 6 December 2018 and 20 October 2019. Wong and colleagues published the result in JAMA Internal Medicine in 2021. The interval around 0.63 was tight: 95% CI, 0.62–0.64. The model missed 1,709 of 2,552 sepsis patients, 67% of them. It alerted on 6,971 of the 38,455 hospitalizations, 18%. The abstract does not hedge: “This external validation cohort study suggests that the ESM has poor discrimination and calibration in predicting the onset of sepsis.”
The vendor's figure was a true statement about the vendor's evaluation. Only the local validation could produce a statement about the system as it ran. Buyers usually hold the middle record. They need the third.
0.76–0.83 was the vendor's number and 0.63 was the hospital's; only one of the two describes the system a patient actually meets.
Case
Datasheets in 2021, model cards in 2019, and the gap after both
Every electronic component ships with a datasheet: operating characteristics, test results, recommended uses. In 2018 a team led by Timnit Gebru proposed borrowing the habit for data. The abstract makes the transfer in one sentence: “By analogy, we propose that every dataset be accompanied with a datasheet that documents its motivation, composition, collection process, recommended uses, and so on.” Datasheets for Datasets reached its final form in Communications of the ACM in 2021.
The second format is scoped to one model version, and says so in its own abstract. Margaret Mitchell and eight co-authors wrote that “Model cards are short documents accompanying trained machine learning models that provide benchmarked evaluation in a variety of conditions, such as across different cultural, demographic, or phenotypic groups (e.g., race, geographic location, sex, Fitzpatrick skin type) and intersectional groups (e.g., age and race, or sex and Fitzpatrick skin type) that are relevant to the intended application domains.” Model Cards for Model Reporting appeared at FAT* in 2019. It demonstrates the format on exactly two supervised models: a smiling-face detector and a toxic-comment detector.
Put the two scopes side by side. A dataset's motivation, composition and collection process in one. A trained model's benchmarked evaluation across groups in the other. Neither describes a system as it actually runs, with the prompts, the retrieval and the human steps around it. That is the third record, and it is the one a buyer most often lacks.
Example
The regulator's own example model card is not a template
The FDA has published an example model card, and then said what it is not. The agency issued draft guidance on AI-enabled device software functions on 7 January 2025. By then it had authorised more than 1,000 AI-enabled devices. Appendix E supplies an example model card. Appendix F supplies an example 510(k) summary containing one. Appendix E then adds: “It is important to note that FDA does not require the inclusion of a model card or a specific model card format, and this example should not be considered a template.”
The substance FDA recommends lives in the submission, not in the card's layout. It asks for model class, dataset size and source, statistical confidence, and how the model will be updated. It asks for the demographic composition of training versus validation versus intended-use populations. Every page is headed “Contains Nonbinding Recommendations / Draft – Not for Implementation”. It was still a draft in August 2026. A buyer holding a polished card is holding a disclosure that its own regulator declines to treat as a form, let alone as a clearance.
- Model artifact: The card describes one model version and selected evaluations. In FDA's own layout it sits inside a 510(k) summary, beside the submission rather than in place of it.
- Dataset gap: Collection, consent, labels and known skews need separate evidence. FDA asks sponsors for dataset size and source, which a card is free to omit and often does.
- System gap: Prompts, retrieval, tools, thresholds and workflow shape deployed behavior. No model card format covers them. That scope stops at the trained model's benchmarked evaluation.
- Context gap: Buyer data and users differ from the reported evaluation. FDA names training, validation and intended-use populations as three distinct populations, each with its own demographic composition to state.
- Assurance gap: A disclosure document gets mistaken for independent validation or certification, when FDA “does not require the inclusion of a model card or a specific model card format”.
Visual
The wrong artifact answers confidently
Dataset, model, system, decision and change each need their own record. Ask a question of the wrong artifact and the answer sounds complete without being complete. Epic Systems' 0.76–0.83 answered a question about a model. Michigan Medicine's 0.63 answered a question about a deployment. A buyer who reads the first as the second has been answered confidently and wrongly.
- 1
Dataset documentation
Origin, composition, collection, consent, processing, labels, skews, access, and maintenance.
- 2
Model documentation
Version, objective, training, evaluation, intended use, limitations, and owner.
- 3
System documentation
Architecture, prompts, retrieval, tools, policy, human roles, controls, and monitoring.
- 4
Decision record
Approval, alternatives, residual risk, conditions, dissent, and owner.
- 5
Change and incident record
Versions, exceptions, failures, corrections, and lessons.
Comparison
Datasheet, Model card, or System card or assurance record?
Datasheets cover data, model cards cover a version, and system cards cover what the composed thing actually does. EU law already arranges the three that way, with numbers attached. The Artificial Intelligence Act, Regulation (EU) 2024/1689, was adopted in 2024. Its Article 11(1) requires a high-risk AI system's technical documentation to be drawn up before the system is placed on the market, kept up to date, and to contain at a minimum the elements of Annex IV.
Annex IV runs to nine numbered points, and the datasheet is not a tenth standing beside them. It is nested at point 2(d), which calls for “where relevant, the data requirements in terms of datasheets describing the training methodologies and techniques and the training data sets used, including a general description of these data sets, information about their provenance, scope and main characteristics”. Under EU law the dataset record is a component of the system record, not an alternative to it. None of the three records, though, covers how one particular buyer will use the thing in one particular place.
Datasheet
Documents a dataset and its lifecycle.
- Helps consumers assess fit and risk
- Does not evaluate every model use
- Needs updates as data change
- Origin: Datasheets for Datasets
Model card
Documents a model version and evaluation.
- Supports intended-use and subgroup reporting
- Does not describe the whole application
- Can omit local context and workflow
- Origin: Model Cards for Model Reporting
System card or assurance record
Documents composed behavior and controls.
- Covers model plus application and operations
- Can link claims to test evidence
- Needs version and access governance
- Should include unresolved limitations
Steps
How to test responsible AI documentation before release
Identify the object being documented, and only then the audience it is written for. A record that skips the second step is written for nobody. One binding US rule has already worked the list out item by item. That makes it a better checklist than any abstract description of maintenance.
ONC's HTI-1 final rule, published in January 2024, adopted a Decision Support Interventions criterion at 45 CFR 170.315(b)(11). It was the first substantial revision of the programme's decision-support requirements since 2012. ONC's own fact sheet gives the counts: “The HTI-1 final rule expands the number of source attributes that health IT certified to the DSI criterion must support, including 13 for evidence-based DSIs and 31 source attributes applicable to Predictive DSIs.” The 31 are grouped in nine categories. They run from “Details and output of the intervention” through “External validation process” and “Quantitative measures of performance” to “Ongoing maintenance of intervention implementation and use” and “Update and continued validation or fairness assessment schedule”. Validity and fairness measured in local data is among them. Certified developers had to supply conforming health IT by 31 December 2024. From 1 January 2025 they had to keep meeting the ongoing maintenance-of-certification requirement. Step 3 and step 5 below are not aspirations in that programme. They are enumerated attributes with a compliance date.
1. Identify the object
Dataset, model, system, decision, control, change, or incident.
2. Define the audience
Builder, buyer, operator, auditor, regulator, affected person, or public.
3. Link claims to evidence
Include versions, samples, methods, results, uncertainty, and owners.
4. Record limits and exclusions
State unsupported populations, contexts, uses, and unresolved risks.
5. Maintain and retire
Update after change, preserve history, and archive with the system lifecycle.
Example
Claim, evidence, owner, date
Most governance questions get asked of the wrong artifact. This drill sorts the questions before anyone tries to answer one. Its yardsticks already exist: Annex IV's nine points, ONC's 31 Predictive DSI source attributes, and a local validation of the kind that turned 0.76–0.83 into 0.63.
- Artifact map: Assign each governance question to the dataset, model, system or decision record that should answer it. Annex IV point 2(d) puts the datasheet inside the system record, not beside it.
- Claim-evidence trace: Pick five claims and link each to a test, a version, an owner and a date. ONC's Predictive DSI list shows what that trace looks like fully enumerated, at 31 attributes.
- Local applicability: List the evidence the buyer must produce because the vendor card cannot cover local use. Michigan Medicine's 27,697 patients and 38,455 hospitalizations are what producing it costs.
- Staleness check: Find documentation that no longer matches the deployed system. Start with the sections most often left empty: Limitations at 17.4% and Evaluation at 15.4% across 32,111 cards.
Key idea
Limitations filled in 17.4% of the time
Filling in every box of a template can hide uncertainty behind professional formatting. The boxes that go unfilled are not random. A 2024 study in Nature Machine Intelligence went through 32,111 Hugging Face model cards and counted which sections people actually write. Its results section, in the authors’ preprint, reports: “Across all the model cards, Environmental Impact (2.0%, or 639 out of 32,111 model cards), Citation (14.4%), Evaluation (15.4%), and Limitations (17.4%) sections exhibit the lowest filled-out rates, while the Training section (74.3%) is most frequently filled out”. Among the top-1,000 most-downloaded models, Limitations still reached only 22.1%. Of the 639 Environmental Impact sections that were filled in, 542 — 84.8% — appear to have been generated automatically by model-building tools rather than written by a person. The section describing what a model was trained on is four times as likely to be present as the section describing what it cannot do.
A reviewer should therefore check each claim for four things: evidence tied to a named version, an evaluation run on people who resemble the local ones, an owner who answers for it, and limits that are still current. A published record can also expose confidential or security-sensitive information. Here too a statute has already drawn the line. Article 78(1) of the AI Act binds the Commission, market surveillance authorities, notified bodies and any other person applying the Regulation. They must “respect the confidentiality of information and data obtained in carrying out their tasks and activities in such a manner as to protect, in particular: (a) the intellectual property rights and confidential business information or trade secrets of a natural or legal person, including source code”. The same article protects the effective conduct of inspections and audits, and public and national security interests. Article 11 nonetheless still requires the full Annex IV documentation to exist and to be available to national competent authorities and notified bodies. Sensitivity governs who may read the record, not whether it is kept.
Across 32,111 cards the Training section was filled 74.3% of the time and Limitations 17.4%; a complete template proves the template was satisfied.
When evidence about responsible AI documentation supports restriction or redesign
Documentation is a claim about a version, and versions move underneath it. Staleness is the failure mode worth measuring. ONC gives that measurement a name and a place in the record. “Update and continued validation or fairness assessment schedule” is one of the nine source-attribute categories, with validity and fairness measured in local data among the rest. The Epic Sepsis Model shows what such a measurement returns when it is finally taken. 0.63 against a reported 0.76–0.83. 1,709 of 2,552 sepsis patients missed. 6,971 alerts across 38,455 hospitalizations.
Name the claim-evidence gap or record-to-deployment drift that would force the reviewer to redesign, restrict, remedy, or retire the model.
Key takeaways
- Datasheets, model cards and system cards describe different governed objects: a dataset's motivation, composition and collection process in the first, one trained model version's benchmarked evaluation across groups in the second.
- Documentation communicates evidence and limitations but cannot create missing assurance. Epic Systems' reported 0.76–0.83 became 0.63 when Michigan Medicine measured it across 27,697 of its own patients.
- Version, intended use, population, method, uncertainty, owner and date make a record actionable. ONC's HTI-1 rule turns that list into 31 source attributes for Predictive DSIs at 45 CFR 170.315(b)(11).
- A vendor document cannot replace local evaluation and workflow governance. FDA's January 2025 draft guidance says it does not require a model card, and that its own Appendix E example is not a template.
- Decision, change, exception and incident records complement technical documentation. Annex IV of the EU AI Act runs to nine points and nests the datasheet inside them at point 2(d).
- Detailed records may need controlled access while meaningful transparency remains available. Article 78(1) protects trade secrets including source code; Article 11(1) still requires the full Annex IV documentation to exist and stay up to date.