A model card is a one-page (or short multi-page) document describing an AI model's intended use, training data, performance, limitations, ethical considerations and operational owner. The format was proposed by Mitchell et al. (Google, 2018) and is now operationalised in ISO 42001 Annex A.7 and the EU AI Act's Annex VIII technical documentation requirements. A working 2026 model card has nine sections — the same nine an auditor will read. The trap most teams fall into: writing model cards as marketing rather than as evidence.
- Model card
- Structured documentation accompanying an AI model — covering intended use, training data, evaluation, performance, limitations, ethical considerations and accountable owner — designed to enable downstream users, auditors and regulators to understand the model's behaviour and constraints.
- Nine sections: identity, intent, data, performance, limitations, ethics, ops, contact, version.
- Write for the auditor and the next engineer — not for the marketing site.
- Performance section needs disaggregated metrics by demographic group. Aggregate-only metrics fail audit.
- "Limitations" is the section that earns trust. Be honest; auditors will find what you hide.
- Version every model card. Outdated model cards are worse than missing ones.
The nine sections
1. Model identity
Name, version, type (foundation, fine-tune, classifier, embedding…), base architecture, parameter count if disclosed, training compute order-of-magnitude. Auditor's first check: does the card match the model actually in production?
2. Intended use
What the model is for. What it is not for. What users are in-scope and out-of-scope. The "not for" list is often more useful than the "for" list — it scopes the risk surface.
3. Training data
Source(s), consent/licence basis, time window, language distribution, demographic composition where measurable, known biases. Cite specific datasets where possible. If proprietary, describe in enough detail for an auditor to assess representativeness. For DPDP/GDPR context see our GDPR vs DPDP essay.
4. Evaluation methodology
Test sets used, sampling methodology, metrics chosen, why those metrics. Disclose what was measured and what wasn't.
5. Performance
Aggregate metrics + disaggregated metrics by demographic group. For Indian deployments, that means by language (English vs Hindi vs code-mix vs other Indic), by region where relevant, by gender, and by socioeconomic axis where data permits. Aggregate-only performance reporting is the single most common audit finding.
6. Limitations and known failure modes
Document the cases where the model is known to fail or degrade. This section is where mature teams distinguish themselves. Auditors and procurement teams calibrate trust by how candid this section reads.
7. Ethical considerations
Mapped to your responsible-AI principles. Bias risks, dual-use risks, privacy risks, and the controls in place for each. Cross-reference the model's row in the AI risk register; do not duplicate.
8. Operational
Deployment environment, inference latency profile, monitoring in place (drift, accuracy, fairness), retraining cadence, rollback procedure, incident-response link. This is the section a reliability engineer reads.
9. Accountability and contact
Named system owner, model card version, last review date, next scheduled review, contact channel for affected users or external researchers. ISO 42001 Annex A.3 compliance.
What auditors look for
- Disaggregated performance metrics. Aggregate-only = finding.
- Named owner with a real email. "Engineering team" = finding.
- Version + date. Undated cards = finding.
- Honest limitations section. A card with no documented failure modes is suspicious.
- Cross-references to the risk register and impact assessment. Standalone cards are weaker evidence.
Common mistakes Indian teams make
- English-only evaluation reported for a product serving Indian users in multiple languages.
- Foundation-model card copied wholesale for a fine-tune — auditors expect the fine-tune to have its own card with delta documentation.
- "Trained on publicly available data" as the entire training-data section. Inadequate.
- Model card on the marketing site only. It must live in the internal documentation system, version-controlled.
How the model card fits the bigger picture
Model cards are one of three pillars of AI documentation — alongside risk assessments and impact assessments. Together they satisfy ISO 42001 Annex A.5–A.7, the NIST AI RMF MAP function, and the EU AI Act Annex VIII transparency requirements. See our companion essay on the four principles of responsible AI.
Frequently asked
- What is a model card?
- Structured documentation accompanying an AI model — covering intended use, training data, evaluation, performance, limitations, ethical considerations and accountable owner — designed to enable downstream users, auditors and regulators to understand the model's behaviour and constraints.
- What should a model card include?
- Nine sections: identity, intended use, training data, evaluation methodology, performance (disaggregated), limitations, ethical considerations, operational details, accountability and contact. Version + date required.
- What is the most common audit finding on model cards?
- Aggregate-only performance metrics. Disaggregated performance by demographic group, language and region is mandatory; aggregate-only fails ISO 42001 Annex A.7 audit.
- Should a model card be public?
- Internal cards must exist for audit. External cards are a judgment call — they build trust but expose detail. Most production teams maintain a richer internal card and a redacted public version.
Auto-generate model cards from your stack.
The Lab's policy engine drafts a nine-section model card from your code and config, ready for editing. Free preview, ₹799 for the full pack.
Dr. Nitnem Singh Sodhi is a Lead Auditor for ISO/IEC 42001, 27001 and 27701, accredited by ANSI/ABICB since March 2025.
— Bharat NeuroTech · /dr-sodhi