Model Cards, Datasheets and System Documentation

1. Why This Topic Matters

AI systems fail in ways that are difficult to detect after the fact: a model that performs well in aggregate may perform poorly for a minority subgroup, a dataset may contain data collected without proper consent, or a system may be deployed for a purpose its developers never tested. In almost every documented AI incident, investigators ask the same questions: What was this model built to do? What data was it trained on? Who approved it, under what conditions, and how is it monitored? Model cards, datasheets and system documentation exist to answer those questions before an incident occurs, not after.

For the ISACA AAIR (Advanced in AI Risk) exam, this topic sits inside the AI Life Cycle Risk Management domain because documentation is the thread that connects every lifecycle phase. It is how risk identified during data sourcing is communicated to model developers, how model limitations are communicated to deployers, and how the whole system is made auditable for assurance professionals and regulators. ISACA frames documentation as a control, a source of audit evidence, and an accountability mechanism. Expect exam questions to test all three framings.

Key reasons documentation is important:
- Transparency and explainability: stakeholders can understand what the system is and is not designed to do.
- Accountability: named owners, approvals and decision records establish who is responsible.
- Auditability and assurance: auditors and risk professionals need evidence that controls were designed and operated; documentation is that evidence.
- Regulatory compliance: the EU AI Act (technical documentation for high-risk systems), NIST AI RMF (Map and Govern functions emphasize documentation of context, intended use and risks), ISO/IEC 42001 (AI management system documentation requirements) and ISO/IEC 23894 all expect documented lifecycle artefacts.
- Third-party and supply chain risk: when acquiring a model or dataset, documentation is often the only insight into provenance, licensing and limitations.
- Reproducibility and change management: documented versions, parameters and data lineage allow teams to reproduce results and understand the impact of changes.
- Incident response and continuity: when something goes wrong, documentation accelerates root cause analysis and recovery.
- Knowledge retention: staff turnover is high in AI teams; documentation prevents organisational amnesia.

2. What These Artefacts Are

Think of the three artefacts as operating at three different levels of scope: the dataset, the model, and the complete system in its deployment context. The exam frequently tests whether you can match a described concern to the correct level.

2.1 Datasheets for Datasets

Proposed by Gebru et al. (2018, published in CACM 2021), datasheets borrow the idea from electronics, where every component ships with a datasheet describing its characteristics and operating conditions. A datasheet documents a dataset, typically covering:
- Motivation: why the dataset was created, by whom, and who funded it.
- Composition: what the instances represent, how many there are, whether sensitive or personal data is included, whether subpopulations are identified, known errors, noise or redundancies.
- Collection process: how data was acquired, sampling strategy, time frame, whether individuals were notified and consented, ethical review conducted.
- Preprocessing, cleaning and labelling: what was done to the raw data, whether raw data was retained, who performed labelling and how label quality was assured.
- Uses: what the data has been used for, what it should not be used for.
- Distribution: how it is shared, licences, restrictions, export controls.
- Maintenance: who maintains it, how errors are reported, update cadence, retention and deletion.

Related artefacts you may see referenced: Data Statements (Bender and Friedman, for NLP datasets, emphasising speaker demographics and language variety) and Dataset Nutrition Labels.

Risk value: datasheets surface representativeness gaps, consent and privacy issues, licensing exposure, label quality problems and the risk of inappropriate reuse of a dataset outside its original purpose.

2.2 Model Cards

Proposed by Mitchell et al. (2019), model cards are short, structured documents that accompany a trained model. They describe:
- Model details: developer, version, date, model type and architecture, training algorithm, parameters, licence, where to send questions.
- Intended use: primary intended uses and users, and explicitly out-of-scope uses.
- Factors: relevant demographic, environmental or instrumentation factors that may affect performance (for example, skin tone, accent, camera type, lighting).
- Metrics: which performance measures were used, why, and decision thresholds.
- Evaluation data: which datasets were used for evaluation and why they were chosen.
- Training data: summary of training data (often referencing the datasheet).
- Quantitative analyses: performance reported in aggregate and disaggregated across factors and intersections of factors; this is the heart of a model card and a key fairness control.
- Ethical considerations: potential harms, sensitive use cases, mitigations.
- Caveats and recommendations: known limitations, conditions under which the model should not be relied upon, suggestions for further testing.

Risk value: model cards make performance variation visible, prevent scope creep by stating out-of-scope uses, and give deployers the information needed to decide whether a model is fit for their context.

2.3 System Documentation

Models do not operate alone. A model is embedded in a system that includes data pipelines, pre- and post-processing, business rules, user interfaces, human oversight procedures, integrations and monitoring. System documentation describes the whole deployed solution and its governance. Common components include:
- System cards or FactSheets: system-level summaries (OpenAI publishes system cards for GPT models; IBM proposed AI FactSheets) covering purpose, capabilities, safety evaluations, red-teaming results and mitigations.
- Technical documentation: architecture and data flow diagrams, component inventory, dependencies, infrastructure, APIs, security controls.
- Risk and impact assessments: AI risk assessment, algorithmic impact assessment, data protection impact assessment (DPIA), human rights impact assessment where relevant.
- Design and decision records: why particular design choices were made, alternatives rejected, approvals obtained.
- Testing and validation records: test plans, results, bias and robustness testing, red-team findings, acceptance criteria and sign-off.
- Human oversight and operating procedures: who monitors the system, escalation paths, override and kill-switch procedures, user instructions and disclosures.
- Monitoring and maintenance plans: drift detection, performance thresholds, retraining triggers, incident reporting, logging and retention.
- Change and version history: a record of every change to data, model, code and configuration, with associated re-validation.
- Compliance mapping: traceability from requirements (laws, standards, policies) to the controls and evidence that satisfy them.

Under the EU AI Act, providers of high-risk AI systems must maintain technical documentation (Annex IV) covering essentially these elements, plus instructions for use for deployers and automatically generated logs. System documentation is therefore both a good-practice artefact and, in some jurisdictions, a legal obligation.

2.4 Quick Comparison

Datasheet - Scope: dataset - Owner: data steward or data provider - Key question: where did this data come from and what is in it?
Model card - Scope: trained model - Owner: model developer or data science lead - Key question: what does this model do, how well, for whom, and what should it not be used for?
System documentation - Scope: entire deployed system and its governance - Owner: system or product owner, with contributions from engineering, risk, legal and security - Key question: how is this system built, controlled, overseen and maintained?

3. How Documentation Works Across the AI Life Cycle

The exam expects you to understand documentation as a living, lifecycle-integrated process, not a one-off deliverable produced at the end.

Planning and design: document the business problem, intended use, stakeholders, success criteria, risk appetite, applicable regulations and the initial risk assessment. Decide which documentation templates will be mandatory and who owns them.

Data acquisition and preparation: create or obtain datasheets for every dataset. For third-party or open data, require the supplier to provide a datasheet or complete one through due diligence. Record lineage, consent basis, licences, preprocessing and labelling procedures.

Model development and training: maintain experiment logs, hyperparameters, training data versions and evaluation results. Draft the model card as the model takes shape, including disaggregated performance and out-of-scope uses.

Validation and testing: independent validation reviews the model card against actual test results; discrepancies are a red flag. Testing records, bias audits and red-team findings become part of system documentation. A go/no-go gate should require complete documentation as an entry criterion.

Deployment: finalise system documentation, instructions for use, human oversight procedures and monitoring plans. Register the system in the organisation AI inventory with links to all artefacts. Obtain and record approvals.

Operation and monitoring: update documentation when the model is retrained, when data sources change, when performance drifts or when incidents occur. Each version of the model should have a corresponding version of the model card. Periodic reviews confirm documentation remains accurate.

Retirement: document decommissioning decisions, data retention or deletion, and lessons learned.

Governance practices that make documentation effective:
- Ownership and accountability: each artefact has a named owner and approver.
- Standardised templates: consistency enables comparison, review and automation.
- Version control and traceability: documentation is tied to specific model, data and code versions.
- Independent review: second-line risk or internal audit verifies that documentation reflects reality.
- Accessibility and audience fit: technical detail for engineers, plain-language summaries for business owners and users, evidence packs for auditors and regulators.
- Automation where possible: MLOps platforms can auto-generate parts of model cards (metrics, versions, lineage), reducing the risk of stale documentation.
- Integration with the AI inventory and risk register: documentation supports risk classification, control mapping and reporting.

4. Common Risks When Documentation Is Weak

- Models reused outside their validated scope (scope creep) because out-of-scope uses were never stated.
- Undetected bias because performance was only reported in aggregate.
- Privacy and legal exposure because data provenance, consent and licensing were unknown.
- Inability to demonstrate compliance to regulators or to pass audit.
- Slow or ineffective incident response because the system architecture and dependencies were undocumented.
- Stale documentation that describes a previous version, creating false assurance; this is arguably worse than no documentation because it misleads reviewers.
- Over-reliance on vendor marketing material instead of structured model cards and datasheets in third-party procurement.

5. Exam Tips: Answering Questions on Model Cards, Datasheets and System Documentation

Tip 1 - Match the concern to the correct level of scope. If the question mentions data collection, consent, sampling, labelling, composition, or dataset licensing, the answer is datasheet. If it mentions intended use, out-of-scope use, evaluation metrics, disaggregated performance across subgroups, or model limitations, the answer is model card. If it mentions architecture, integrations, human oversight procedures, monitoring plans, instructions for use, change history, or regulatory technical files, the answer is system documentation.

Tip 2 - Remember the primary purpose of each artefact. Datasheets exist to communicate dataset provenance and suitability. Model cards exist to communicate model performance, limitations and appropriate use to downstream users. System documentation exists to make the whole system governable, auditable and maintainable. When a question asks for the best reason or primary purpose, choose the option aligned with these core purposes rather than a secondary benefit.

Tip 3 - Documentation is living, versioned and owned. Any answer option that treats documentation as a one-time deliverable completed at project close is almost always a distractor. ISACA favours answers that describe documentation as updated at each lifecycle phase, tied to versions, and maintained by an accountable owner.

Tip 4 - Think like an auditor. The AAIR exam is an ISACA exam. When asked what a risk professional or auditor should do first, prefer answers about reviewing existing documentation (model cards, datasheets, risk assessments, approvals) to establish the system context before testing controls. When asked what constitutes evidence that a control operated, documentation and logs are the typical answer.

Tip 5 - Third-party scenarios point to documentation requests. If an organisation is acquiring a pre-trained model, foundation model or external dataset, the best risk response usually involves obtaining the model card, datasheet or system card from the provider, incorporating documentation requirements into contracts, and independently validating claims rather than relying on marketing material.

Tip 6 - Disaggregated performance is a fairness control. Questions about detecting disparate performance across demographic groups are pointing to the quantitative analysis section of a model card. The weak answer reports only aggregate accuracy; the strong answer reports performance broken down by relevant factors and their intersections.

Tip 7 - Out-of-scope use statements prevent scope creep. If a scenario describes a model being repurposed for a new use case, the risk is that the new use was never validated. The model card out-of-scope section and a formal change or re-validation process are the relevant controls.

Tip 8 - Stale documentation creates false assurance. If a scenario describes a model retrained several times with a model card last updated at initial deployment, identify the risk as inaccurate documentation and the response as re-validation and documentation update tied to change management.

Tip 9 - Know the regulatory and framework anchors. Be able to connect documentation to the EU AI Act technical documentation and instructions for use for high-risk systems, NIST AI RMF Map and Govern functions, and ISO/IEC 42001 documented information requirements. You do not need to memorise article numbers, but you should recognise that documentation is a compliance obligation, not only good practice.

Tip 10 - Audience awareness. Questions may ask how to communicate model limitations to business users or end users. The best answer tailors documentation to the audience: plain-language summaries and instructions for use for non-technical stakeholders, detailed technical files for engineers and auditors. Dumping a technical appendix on end users is a distractor.

Tip 11 - Eliminate distractors systematically. Typical wrong options include: relying on source code or developer memory instead of documentation; documenting only successful test results; producing documentation only when a regulator asks; assigning documentation ownership to no one or to an external vendor exclusively; or assuming that a model card from a vendor removes the need for internal validation.

Tip 12 - Watch for keywords such as FIRST, BEST, MOST and PRIMARY. For FIRST, choose the step that establishes understanding or governance (review documentation, define requirements, assign ownership). For BEST or MOST, choose the answer that is risk-based, comprehensive, independent and sustainable over the one that is partial or reactive.

6. Sample Question Walkthroughs

Scenario A: A bank is considering a third-party credit scoring model. The vendor has provided a brochure stating 95 percent accuracy. What should the risk professional request first?
Reasoning: Aggregate accuracy tells you nothing about performance across protected groups, intended use, or training data. The best first step is to request the model card and supporting datasheets, including disaggregated performance and out-of-scope uses, before any further evaluation.

Scenario B: An internal team wants to reuse a customer churn model to prioritise fraud investigations. Which document section is most relevant to assessing this request?
Reasoning: This is a change of use. The intended use and out-of-scope use sections of the model card indicate whether the model was validated for anything similar; the correct governance response is a documented re-validation before deployment.

Scenario C: During an audit, the auditor finds that the deployed model is version 7 but the model card describes version 3. What is the primary risk?
Reasoning: The documentation is stale, so stakeholders may be relying on inaccurate information about performance and limitations, creating false assurance. The recommended control is to tie documentation updates to the change management and release process.

Scenario D: A data science team cannot confirm whether a training dataset included personal data collected with consent. Which artefact would best have prevented this gap?
Reasoning: A datasheet documents composition, collection process and consent. The answer is the datasheet, supported by a data governance requirement that no dataset enters training without one.

Scenario E: A regulator requests evidence of human oversight procedures and monitoring thresholds for a high-risk AI system. Where should this information reside?
Reasoning: These are system-level operational controls, so the answer is system documentation (technical documentation and instructions for use), not the model card or datasheet.

7. One-Paragraph Summary to Memorise

Datasheets document data (motivation, composition, collection, preprocessing, uses, distribution, maintenance). Model cards document models (details, intended and out-of-scope uses, factors, metrics, evaluation data, disaggregated performance, ethical considerations, caveats). System documentation describes the whole deployed system and its governance (architecture, risk assessments, testing, human oversight, monitoring, change history, compliance mapping). All three are living, versioned, owned artefacts created and updated across the AI life cycle; they serve as controls, audit evidence and regulatory deliverables. On the exam, identify the scope level, remember the primary purpose, favour lifecycle-integrated and accountable governance, and reject one-time, unowned or marketing-based alternatives.