60. AI Model Cards Explained: How to Document an AI System for Transparency, Risk, and Trust

Last Updated: September 13, 2026

An AI model card template in 2026 is no longer just a transparency document — it is evidence. EU AI Act Article 13 requires providers of high-risk AI systems to supply deployers with clear, comprehensive documentation of how their system functions, what its limitations are, and what risks it carries — before deployment. Non-compliance carries penalties of up to €35 million or 7% of global annual turnover for serious violations, according to GDPR Local’s analysis of the EU AI Act’s enforcement provisions. The August 2026 transparency provision deadline has already passed for organizations that needed to be audit-ready, and regulators are now evaluating technical evidence — not intentions. As one 2026 analysis put it directly: organizations will be evaluated on their verifiable technical evidence, not their compliance reports.

The concept of the model card originated in a 2018 Google research paper by Mitchell et al. — a framework proposing short documents accompanying trained machine learning models that provide benchmarked evaluation across different conditions, disclose the context in which models are intended to be used, and document relevant limitations. That original proposal was voluntary and academic. In 2026, the same core concept has been codified into binding regulatory requirements across multiple jurisdictions. NIST’s AI Risk Management Framework maps model documentation requirements to governance controls. ISO/IEC 42001 references model documentation as a core component of an AI Management System. The EU AI Act imposes legally binding documentation obligations on high-risk AI providers. Model cards sit at the intersection of all three frameworks — making them the most practical, cross-compatible transparency document available to AI practitioners in 2026.

This article covers AI model cards from the foundational level through to full regulatory compliance. You will find a plain-English explanation of what model cards are and why they matter, a complete copy-paste template updated for 2026 compliance requirements, a comparison table mapping every model card field to its EU AI Act Article 13 requirement, real-world examples from Google, Meta, and Hugging Face, and the practical guidance for completing a model card that satisfies both internal governance and external regulatory scrutiny. Whether you are writing your first model card for a small internal deployment or building a compliant documentation program for high-risk AI at enterprise scale, this guide gives you the structure and the content to do it right.

1. 🤔 What Is an AI Model Card and Why Does It Matter in 2026?

An AI model card is a structured transparency document that describes a trained machine learning model — what it does, how it was built, what data it was trained on, how it performs across different groups and conditions, what its limitations are, and what risks it carries for specific use cases. The term was coined by Google researchers in 2018, drawing an analogy to the nutrition labels on food packaging: just as a nutrition label gives consumers the information they need to make an informed decision about a product, a model card gives deployers, users, and regulators the information they need to make an informed decision about an AI system.

In practice, model cards serve four simultaneous purposes in 2026. First, they are a transparency tool — communicating the model’s intended use, performance characteristics, and limitations to anyone who needs to evaluate whether the model is appropriate for a given deployment context. Second, they are a risk communication tool — documenting known failure modes, demographic performance disparities, adversarial vulnerabilities, and out-of-scope use cases so that deployers can make informed governance decisions. Third, they are a compliance artifact — providing the documented evidence that EU AI Act Article 13, NIST AI RMF, ISO 42001, and other governance frameworks require from AI providers. Fourth, they are a living governance record — a reference document that should be updated whenever the model is retrained, fine-tuned, or deployed in a new context, creating an audit trail of the model’s evolution over its operational lifecycle.

The distinction between a model card and an AI system card is worth understanding before you begin documenting. A model card documents the underlying trained model — the weights, the training data, the performance benchmarks, the bias evaluation. An AI system card documents the complete deployed system — including the model, the retrieval layer, the safety filters, the human oversight mechanisms, and the full user-facing application. Our guide to AI system cards covers the system-level documentation that wraps around the model card for complete deployment transparency. For most internal governance purposes, you need both — the model card for the ML artifact and the system card for the production deployment. For EU AI Act Article 13 compliance, the technical documentation requirement encompasses elements of both.

Who Needs a Model Card in 2026?

The practical answer to who needs a model card in 2026 has expanded significantly from the original research-community audience. Any organization that trains, fine-tunes, or deploys an AI model in a consequential context should have model card documentation — not just those publishing to public repositories. The EU AI Act makes this obligation explicit for high-risk AI providers: biometric identification, critical infrastructure management, education, employment, essential services, law enforcement, migration, justice, and democratic processes all qualify as high-risk categories under Annex III. For organizations operating in those sectors, model card documentation is not voluntary best practice. It is a legal requirement with enforcement consequences. The Colorado AI Act (effective February 2026) creates parallel documentation and disclosure obligations at the US state level for high-risk AI used in employment, housing, healthcare, and financial services. Even for lower-risk AI deployments, the governance value of model card documentation — forced precision about what your model does and does not do, documented before rather than after a deployment incident — is sufficiently high that the investment is justified across virtually all professional AI deployment contexts.

2. 📋 EU AI Act and Model Cards: What’s Required in 2026

The EU AI Act’s transparency provisions became fully effective on August 2, 2026, ending the grace periods that gave organizations additional time to build compliance infrastructure. GDPR Local’s analysis of AI transparency requirements confirms that legal obligations now require organizations to provide clear, comprehensive documentation — and that non-compliance carries the Act’s harshest penalties, with additional penalties applied for supplying incorrect, incomplete, or misleading transparency information to users or regulators.

Article 13 of the EU AI Act — “Transparency and Provision of Information to Deployers” — is the provision most directly relevant to model card documentation. It establishes that high-risk AI systems must be designed to be transparent, so that those using them can understand and use them correctly. Providers must deliver clear, comprehensive information to deployers on the system’s functioning, limitations, and potential risks. The Article 13 requirement operates alongside the technical documentation obligation in Article 11, which requires providers to prepare and maintain detailed technical documentation before placing a high-risk AI system on the market. That technical documentation must include: a general description of the AI system and its intended purpose; a description of the elements of the AI system and the development process; information on monitoring, functioning, and control; a description of the risk management system; data governance information; information on accuracy, robustness, and cybersecurity; and post-market monitoring details.

The shift from static reports to automated, living model cards is identified by 2026 compliance practitioners as the critical evolution needed to meet Article 13’s practical requirements. A static PDF model card produced at the time of initial deployment and never updated fails to meet the Act’s expectation that documentation reflects the current state of a deployed system — particularly for high-risk applications where model updates, retraining events, or new deployment contexts materially change the risk profile. In 2026, data lineage — the ability to map every piece of training data from its source to its influence on model weights — is described as the essential first step for high-risk AI compliance. An automated model card provides a tamper-proof trail of how a model was built, tested, and deployed. You cannot have a trustworthy model if you do not know where the data came from — and Article 13 requires you to be able to demonstrate that you do. Our full guide to the EU AI Act covers the complete compliance requirements, risk tier definitions, and implementation timeline that organizations need to navigate the regulation in full.

The EU AI Act compliance reality for model cards in 2026: Regulators are not asking whether you have a model card. They are asking whether you have verifiable technical evidence that your model is fair, safe, and transparent — documented before deployment, maintained through the model’s operational life, and auditable on demand. A model card that was written once and never updated is not compliance. It is a paper trail that stops at the point where it most needs to continue.

Article 13 Requirements Mapped to Model Card Sections

The practical compliance value of understanding Article 13’s specific information requirements is that it allows you to design your model card to serve both internal governance and external regulatory purposes simultaneously — rather than maintaining separate documents for each audience. The Article 13 information requirements that map most directly to model card content are: the identity and contact details of the provider; the characteristics, capabilities, and limitations of the AI system; performance metrics disaggregated across relevant population groups; changes to the system that have been pre-determined and assessed; human oversight measures required for the system to function as intended; computational and hardware requirements; data retention requirements for automatically generated logs; and the expected lifetime of the system and maintenance and care measures.

ISO/IEC 42001 — the AI Management System standard — reinforces these requirements at the process level. Rather than specifying what a model card must contain (as Article 13 does), ISO 42001 specifies that organizations must maintain documented information about their AI systems sufficient to support their AI governance obligations — with model cards as the most widely recognized format for satisfying that documentation requirement. Organizations that build their model card template to satisfy both Article 13’s content requirements and ISO 42001’s documented information standards create a single document that serves multiple governance frameworks simultaneously. The template in the next section is designed to do exactly that.

3. ✅ AI Model Card Template: Copy-Paste Ready (2026)

The template below is designed to satisfy EU AI Act Article 13 documentation requirements for high-risk AI systems while remaining accessible and useful for lower-risk internal deployments where full regulatory compliance is not required. Fields marked with ⚠️ are required for EU AI Act Article 13 compliance. Fields marked with 💡 are recommended best practice that strengthen governance but are not mandated by Article 13 specifically. Complete every ⚠️ field before any high-risk AI deployment. Complete 💡 fields for all AI deployments where the system affects consequential decisions about individuals.

Before completing this template, read our companion guide to Datasheets for Datasets — the parallel documentation standard for the training data that feeds into your model. A complete AI transparency documentation package combines the model card (this template) with a dataset datasheet (for the training data) and an AI system card (for the deployed application). Each document serves a distinct audience and governance purpose, and together they provide the full accountability trail that regulators, auditors, and deployers increasingly require.

Template instructions: Replace every [bracketed placeholder] with your specific information. Do not leave placeholders blank — if a field is not applicable to your model, write “N/A — [one-sentence explanation of why]” rather than leaving it empty. Blank fields in a compliance document are treated as missing information by auditors, not as acknowledged gaps.

═══════════════════════════════════════════
AI MODEL CARD — [MODEL NAME] v[VERSION NUMBER]
Last Updated: [DATE] | Status: [Draft / Under Review / Approved / Deprecated]
═══════════════════════════════════════════

SECTION 1: MODEL OVERVIEW ⚠️

Model Name: [Full name of the model including version number]
Model Version: [Version number — e.g., v2.3.1]
Model Type: [Architecture — e.g., Large Language Model / Classification Model / Computer Vision Model / Recommendation System]
Release Date: [Date of initial release or deployment]
Model Developer / Provider: [Organization name and contact email — required under EU AI Act Article 13]
License: [License type — e.g., MIT / Apache 2.0 / Proprietary / CC BY 4.0]
Primary Language(s): [Languages the model supports — e.g., English, French, German]
Contact for Questions: [Email or governance portal URL]

SECTION 2: INTENDED USE ⚠️

Primary Intended Use: [Describe the specific task the model is designed to perform — be precise, not generic]
Intended Users: [Who is expected to use this model — e.g., medical professionals, legal researchers, customer service agents, enterprise data analysts]
Intended Deployment Context: [Where and how the model is designed to be used — e.g., internal enterprise tool / customer-facing application / API accessed by third-party deployers]
Out-of-Scope Uses: [Explicitly list uses the model is NOT designed for — e.g., real-time medical diagnosis without clinician review / automated credit decisions without human oversight]
Prohibited Uses: [Uses that are explicitly prohibited regardless of capability — e.g., generating synthetic media of real individuals without consent / use in prohibited AI practices under EU AI Act Article 5]

SECTION 3: TRAINING DATA ⚠️

Training Dataset(s): [Name and description of dataset(s) used for training — link to Datasheet for Datasets where available]
Data Sources: [Where the training data came from — web scraping, licensed datasets, proprietary internal data, etc.]
Data Collection Period: [Date range of data included in training set]
Data Volume: [Approximate size of training data — tokens, examples, or gigabytes as appropriate]
Data Preprocessing: [What cleaning, filtering, or preprocessing was applied to the data before training]
Known Data Gaps or Limitations: [Groups, languages, time periods, or domains that are underrepresented in the training data]
Data Governance: [How data consent, licensing, and privacy obligations were managed — required for Article 13 compliance in regulated sectors]

SECTION 4: MODEL PERFORMANCE AND EVALUATION ⚠️

Primary Evaluation Metrics: [What metrics were used to assess performance — e.g., F1 score, accuracy, BLEU, ROUGE, hallucination rate]
Benchmark Results: [Performance scores on standard benchmarks relevant to the model type and task — include benchmark name, version, and score]
Evaluation Dataset(s): [What test data was used for evaluation — should be different from training data]
Disaggregated Performance: [Performance broken down by demographic group, language, domain, or other relevant factors — required for EU AI Act high-risk systems]
Performance Limitations: [Tasks, domains, or conditions where performance degrades significantly — be specific]
Human Evaluation: [Was the model evaluated by human raters? If so, describe the methodology and findings]

SECTION 5: BIAS AND FAIRNESS ⚠️

Known Biases: [Specific biases identified in testing — demographic, linguistic, cultural, or domain-specific]
Bias Mitigation Steps Taken: [What was done to reduce identified biases — data augmentation, algorithmic debiasing, output filtering, etc.]
Residual Bias Risk: [Biases that were identified but not fully mitigated, and the risk they carry for specific use cases]
Fairness Evaluation Method: [How fairness was assessed — which metrics, which groups, which evaluation datasets]
Recommended Monitoring: [What ongoing monitoring is recommended to detect bias drift after deployment]

SECTION 6: SAFETY AND RISKS ⚠️

Known Risks: [Specific risks associated with this model — hallucination, jailbreaking vulnerability, output toxicity, privacy leakage, etc.]
Safety Testing Completed: [What adversarial testing, red teaming, or safety evaluation was conducted]
Safety Mitigations in Place: [Filters, guardrails, rate limiting, human review requirements, or other safety controls]
Residual Safety Risks: [Risks that safety mitigations do not fully address]
Incident Reporting: [How to report a safety incident involving this model — contact information and process]

SECTION 7: HUMAN OVERSIGHT REQUIREMENTS ⚠️

Required Human Oversight Level: [What level of human review is required for model outputs — None / Advisory review / Mandatory approval before action / Full human decision authority]
Autonomous Decision Authority: [What decisions, if any, can the model make without human review — and under what conditions]
Escalation Triggers: [Conditions under which the model should defer to a human rather than generating an autonomous output]
Accountability Owner: [Named role responsible for this model’s outputs and governance — required for EU AI Act Article 13 compliance]

SECTION 8: TECHNICAL SPECIFICATIONS 💡

Model Architecture: [Technical architecture — e.g., Transformer / CNN / Ensemble — with parameter count if disclosable]
Training Framework: [Software framework used — e.g., PyTorch, TensorFlow, JAX]
Compute Requirements: [Hardware and compute required for inference — relevant for deployers making infrastructure decisions]
Inference Latency: [Expected response time at typical load — p50 and p99 latency where available]
Carbon Footprint: [Estimated CO2 equivalent emissions from training — increasingly expected in 2026 governance reporting]

SECTION 9: VERSIONING AND CHANGE HISTORY 💡

Previous Version: [Link to previous model card version if applicable]
Changes in This Version: [What changed from the previous version — training data, architecture, safety mitigations, performance]
Planned Future Updates: [Known upcoming changes that will require model card revision]
Deprecation Plan: [When this version will be deprecated and what replaces it]

SECTION 10: REFERENCES AND ADDITIONAL DOCUMENTATION 💡

Research Paper / Technical Report: [Link to the paper or technical report describing the model, if publicly available]
Dataset Datasheet: [Link to the Datasheet for Datasets for training data]
AI System Card: [Link to the AI System Card for the deployed application using this model]
Related Model Cards: [Links to model cards for related or predecessor models]
Relevant Regulations: [List applicable regulatory frameworks — e.g., EU AI Act Article 13, Colorado AI Act, HIPAA, SR 26-2]

4. 📊 Model Card Field Comparison: What to Include, EU AI Act Requirement, and Example Entry

5. 🔍 Real Model Card Examples: Google, Meta, and Hugging Face

The most effective way to understand what a well-executed model card looks like in practice is to study the real examples published by the organizations that have been most influential in defining the standard. Google, Meta, and Hugging Face each take different approaches reflecting their distinct audiences, model types, and governance philosophies — and examining those differences is instructive for practitioners building their own model card programs.

Google’s Gemma Model Card (gemma 4, April 2026). Google’s Gemma 4 model card, last updated April 17, 2026, represents the current state of the art in open-weight model documentation from a major AI lab. The Gemma 4 card is notable for several characteristics that distinguish it from earlier model card standards: granular performance disaggregation across multiple languages and domains; explicit documentation of the model’s capability boundaries with specific examples of tasks it should not be used for; detailed safety evaluation results including red team findings and the safety mitigations that were applied; and a clear human oversight guidance section that tells deployers what level of review is appropriate for different use case categories. Google’s approach to the carbon footprint section — estimating training emissions and providing per-query inference emission estimates — is now considered a baseline standard for environmentally responsible model documentation. The Gemma 4 card is publicly available and serves as a practical reference point for any organization building a model card for an open-weight deployment.

Meta’s Responsible AI Model Documentation. Meta’s approach to model documentation has evolved significantly through the Llama model family releases, culminating in Llama 4’s documentation that introduces model cards with integrated fairness dashboards — allowing users to interactively explore disaggregated performance across demographic dimensions rather than reading static tables. Meta’s model documentation is particularly strong on the intended use and out-of-scope use sections, which are unusually specific about the commercial and research contexts in which each model variant is appropriate. The Llama 4 documentation also notably includes an extensive section on the acceptable use policy that accompanies the Meta license — a recognition that open-weight model documentation must address not just what the model can do technically but what users are permitted to do with it legally. For organizations deploying open-weight models internally, Meta’s documentation approach offers a useful template for integrating license compliance into the model card rather than treating it as a separate legal document.

Hugging Face’s Model Card Infrastructure. Hugging Face’s contribution to the model card ecosystem is not a single reference model card but a complete platform and tooling infrastructure that makes model card creation, hosting, and discovery accessible across the entire ML community. The Hugging Face Model Card Guidebook — which draws together academic and industry model card work into a unified framework — provides an annotated template, a Model Card Creator Tool for non-programmers, and a library of real-world examples drawn from the 100,000+ models hosted on the Hub. Hugging Face’s specific contribution to model card best practice is the structured metadata YAML header that accompanies every Hub model card — machine-readable metadata that enables automated discovery, filtering, and evaluation result display. The model card is also identified as the appropriate place to document CO2 impact, with Hugging Face providing a dedicated guide on tracking and reporting carbon emissions from model training. For teams looking to publish model cards that are both human-readable and machine-parsable, Hugging Face’s YAML metadata standard is the most widely adopted format currently available.

What the best model cards have in common: Google’s Gemma 4 card, Meta’s Llama 4 documentation, and Hugging Face’s curated examples all share four characteristics that distinguish them from weak model cards: specificity (precise numbers, not vague qualitative assessments), honesty (explicit documentation of limitations and known biases rather than omitting them), actionability (clear guidance to deployers on appropriate human oversight requirements), and living documentation (cards that are updated to reflect the current model version, not the version at initial release). These are the four characteristics your model card should be evaluated against before considering it complete.

Key Differences Between Leading Model Card Approaches

The three approaches above reflect different organizational contexts and audiences that translate into meaningfully different model card design choices. Google’s Gemma cards are written primarily for technical developers and enterprises deploying the model in production — they include extensive benchmark detail, compute specifications, and detailed safety evaluation findings that support technical deployment decisions. Meta’s Llama documentation is written for a broader audience that includes both technical practitioners and policy and legal teams — the out-of-scope use sections and license integration reflect a dual technical and legal audience that most model cards do not serve simultaneously. Hugging Face’s framework is explicitly democratized — designed to make high-quality model card creation accessible to researchers and practitioners who are not professional technical writers or compliance officers, with tooling that automates the sections that can be automated and templates that guide the sections that cannot.

For organizations building their first model card program, the most practical approach is to use Hugging Face’s Model Card Creator Tool and annotated template as the starting structure, fill in the content guidance from the template in Section 3 of this article, and use Google’s Gemma 4 card as the quality reference point — asking of each section: “Is our documentation as specific, as honest, and as actionable as what Google has published for Gemma 4?” That benchmark, applied rigorously, will produce model cards that satisfy both internal governance requirements and external regulatory scrutiny.

6. 🗂️ Model Cards vs System Cards vs AI Fact Sheets — Which Document Do You Need?

One of the most common points of confusion in AI documentation programs is understanding which transparency document is required for which purpose. In 2026, three formats have emerged as the dominant standards: model cards, AI system cards, and AI fact sheets. They are not interchangeable. They document different artifacts, serve different audiences, and satisfy different regulatory obligations. Understanding the distinction before you begin your documentation program will save you from either over-documenting a single deployment or — more commonly — assuming one document satisfies obligations that actually require all three.

The clearest way to understand the difference is through the artifact each document describes. A model card documents the ML model itself — the trained artifact, the weights, the benchmark performance, the training data, the known biases. It answers the question: what is this model, and what does it do? An AI system card documents the complete deployed application built on top of that model — the retrieval layer, the safety filters, the human oversight mechanisms, the system prompt, the full user-facing product. It answers the question: how is this model being used in production, and what safeguards are in place? An AI fact sheet is a shorter, less technical summary document designed for non-specialist audiences — procurement teams, regulators, end users — that communicates the key facts about an AI system without the technical depth of a full model card or system card.

The regulatory landscape in 2026 requires all three documents for high-risk AI deployments operating in the EU. EU AI Act Article 13 covers deployer information requirements — addressed by the system card. Article 11 covers technical documentation requirements — addressed primarily by the model card. Article 50 covers transparency obligations toward end users — addressed by the fact sheet or equivalent user-facing disclosure. Organizations that believe their model card alone satisfies all three obligations are operating with a documentation gap that will be visible to auditors. The table below maps each document to its primary purpose, primary audience, regulatory hook, and approximate scope.

For a full treatment of system-level documentation requirements, including the additional fields that system cards add on top of model card content, see our dedicated guide to AI system cards explained. For the dataset-level documentation that feeds into the training data sections of your model card, see our guide to Datasheets for Datasets. Together, the model card, system card, and dataset datasheet form the complete AI transparency documentation stack that regulators, auditors, and enterprise deployers expect from responsible AI providers in 2026.

7. 🇪🇺 EU AI Act Annex IV — What Model Cards Cover (and What They Miss)

EU AI Act Annex IV specifies eight categories of required content for the technical documentation that high-risk AI providers must prepare under Article 11 before placing a system on the market. Model cards — even well-constructed ones — satisfy approximately 50–60% of Annex IV’s requirements directly. The remaining 40–50% requires supplementary documentation that a model card alone cannot provide. Understanding precisely which Annex IV elements your model card satisfies and which it leaves uncovered is essential for any compliance program targeting EU market access for high-risk AI after August 2026.

The eight Annex IV categories are: (1) a general description of the AI system and its intended purpose; (2) a description of the elements of the system and the development process, including training data, architecture, and computational resources; (3) detailed information on the monitoring, functioning, and control of the system; (4) a description of the risk management system implemented in accordance with Article 9; (5) a description of changes made to the system throughout its lifecycle; (6) a new and updated EU declaration of conformity; (7) a detailed description of the system used for the evaluation of the high-risk AI system’s performance; and (8) where applicable, a description of the post-market monitoring plan. Categories 1, 2, 5, and 7 map well to standard model card content. Categories 3, 4, 6, and 8 require documentation that goes beyond what a model card typically provides.

The four Annex IV categories that model cards most commonly fail to address are worth examining in detail, because they are the areas where compliance gaps are most likely to be exposed during a regulatory audit. Post-market monitoring (Category 8) requires a documented plan for how the provider will track system performance, detect incidents, and respond to emerging risks after deployment — not just at the point of initial release. Conformity assessment (Category 6) requires a formal declaration that the system meets the Act’s requirements, signed by an authorized representative, and in many cases reviewed by a notified body. Human oversight measures (Category 3) requires operational detail about how humans interact with and can intervene in the system — going beyond the model card’s standard human oversight section to cover system-level controls, logging requirements, and intervention mechanisms. Risk management system documentation (Category 4) requires evidence of an Article 9-compliant iterative risk management process — not just a list of known risks, but a documented system for identifying, evaluating, and mitigating them on an ongoing basis.

The practical implication for organizations building compliance programs is straightforward: treat the model card as the foundation of your Article 11 technical documentation package, not as a substitute for it. A complete Annex IV-compliant documentation set will include the model card, a post-market monitoring plan, a conformity assessment record or notified body certificate, operational documentation of human oversight controls and audit logging, and evidence of an ongoing risk management process. Organizations that submit only a model card in response to an Annex IV documentation request are providing approximately half of what is required. See our full guide to the EU AI Act for the complete Annex III and Annex IV requirements, conformity assessment pathways, and implementation timelines for each high-risk category.

8. 🏗️ ISO 42001 Controls A.6.2 and A.8.4 — What the AI Management System Standard Requires From Model Documentation

ISO/IEC 42001:2023 — the internationally recognized AI Management System (AIMS) standard — approaches model documentation differently from the EU AI Act. Where the Act specifies what information must be documented, ISO 42001 specifies how documentation must be governed: who is responsible for it, how it is reviewed and updated, how it integrates into the organization’s broader AI governance processes, and what documented evidence of good governance must be retained. For organizations building a compliant AI management system, understanding the two ISO 42001 controls most directly relevant to model card documentation — A.6.2 and A.8.4 — is essential for ensuring that model cards function as genuine governance instruments rather than static documents that satisfy a checklist and then go unreviewed.

Control A.6.2: AI System Impact Assessment. ISO 42001 Annex A Control A.6.2 requires organizations to conduct and document an impact assessment for AI systems that could affect individuals, groups, or society. The control specifies that organizations must identify and evaluate the potential impacts of the AI system on individuals — particularly vulnerable groups — before deployment, and must document the assessment findings and the actions taken in response to identified risks. Model cards satisfy the documentation output requirement of A.6.2 by capturing the bias evaluation, disaggregated performance data, fairness assessment methodology, and known limitations that an impact assessment must address. However, the control goes further than documentation alone: it requires that the impact assessment be a structured process conducted by identified responsible parties, reviewed at defined intervals, and updated whenever the system changes in a way that could alter its impact profile. An organization that has a well-documented model card but no documented impact assessment process does not satisfy A.6.2 — it satisfies the output requirement without the process requirement that gives it governance meaning.

Control A.8.4: Documentation of Intended Purpose, Performance Targets, and Known Limitations. ISO 42001 Annex A Control A.8.4 requires organizations to document, for each AI system, its intended purpose, the performance targets set for the system, and its known limitations. This control maps almost exactly to the core content of a well-constructed model card: the intended use section covers intended purpose; the benchmark performance section covers performance targets; and the known limitations and performance limitations sections cover the control’s documentation requirements for system constraints. The key governance requirement that A.8.4 adds beyond a static model card is that the documentation must be kept current — updated to reflect the system’s actual performance targets as they evolve through retraining or fine-tuning, and updated to reflect newly identified limitations discovered through production monitoring. An A.8.4-compliant model card is a living document with a defined review and update cadence, not a document produced at deployment and archived.

For organizations pursuing ISO 42001 certification, the model card should be positioned explicitly as the primary documented information artifact satisfying A.8.4, with the impact assessment process feeding into and updating the model card’s bias, fairness, and limitations sections in accordance with A.6.2. The certification auditor will look for evidence that the model card exists, that it is current, that it was reviewed following the most recent change to the system, and that there is a documented process governing who is responsible for maintaining it. Building that process — and building it into the model card’s ownership structure before the audit — is the difference between a model card that satisfies ISO 42001 certification requirements and one that is technically compliant in content but ungoverned in practice. Our guide to ISO/IEC 42001 covers the full Annex A control set, certification pathway, and implementation guidance for organizations building a compliant AI management system.

9. 🤖 LLM-Specific Model Card Fields — What Traditional ML Documentation Misses

The model card format originated in 2018 to document classical supervised machine learning models — classifiers, regression models, computer vision systems, recommendation engines. The core template served that purpose well. But large language models introduce a set of technical characteristics, risk profiles, and deployment dynamics that traditional model card templates do not address — and that are directly relevant to EU AI Act compliance, enterprise risk management, and deployer decision-making in 2026. An organization that documents an LLM using an unmodified classical ML model card template will produce a document that is technically present but substantively incomplete for the model type being deployed.

The following fields should be added to any model card documenting a large language model, retrieval-augmented generation system, instruction-tuned model, or multi-modal foundation model. They are not required by the original Mitchell et al. (2019) model card format, but they are increasingly expected by enterprise deployers, AI governance frameworks, and the EU AI Act’s technical documentation requirements for GPAI models subject to the GPAI Code of Practice (effective July 10, 2025, with a mandatory 10-year documentation retention requirement).

Context Window and Token Limits. Document the model’s maximum context window in tokens, the practical effective context (typically 60–70% of the advertised maximum due to accuracy degradation in middle positions — the “lost in the middle” effect), and the output token cap where separate from the input limit. These limits directly constrain deployment architecture decisions and must be disclosed to deployers. For example, a model with a 1M token input window but a 128K token output cap — as with GPT-5.5 as of September 2026 — has a significant asymmetry that affects agentic workflows and long-document summarization use cases. Context window documentation should also note any pricing surcharges that apply beyond specific thresholds, since these affect total cost of ownership for enterprise deployments.

Tokenizer and Language Coverage. Document which tokenizer the model uses, how it handles non-Latin scripts, and which languages the model has been evaluated on versus which it merely handles without performance validation. Tokenizer efficiency varies significantly across languages — a model trained predominantly on English text may tokenize languages like Thai, Arabic, or Japanese at significantly lower efficiency, meaning the effective context window for those languages is substantially smaller than the advertised maximum. For EU AI Act high-risk systems deployed in multilingual contexts, tokenizer documentation is a prerequisite for accurate disaggregated performance reporting across language groups.

Alignment and RLHF Methodology. Document whether the model was trained with reinforcement learning from human feedback (RLHF), direct preference optimization (DPO), constitutional AI, or another alignment method. Describe the preference data used — who provided it, what instructions raters followed, and what values the alignment process was optimizing for. This section is particularly important for compliance with the GPAI Code of Practice, which requires GPAI providers to document the values, objectives, and training processes embedded in their general-purpose AI models. Alignment methodology documentation is also directly relevant to the safety testing and bias sections of the model card — the alignment method determines which failure modes are mitigated by training and which remain as residual risks.

System Prompt Behavior and Instruction Following. Document how the model responds to system prompts — whether system prompt instructions reliably override user-level instructions, what the model does when system and user prompts conflict, and whether the model’s behavior in the presence of a system prompt has been evaluated differently from its base behavior. For enterprise deployments that rely on system prompts to enforce safety guardrails, compliance constraints, or role-specific behavior, this section is operationally critical. Deployers need to know whether the safety controls they implement at the system prompt level can be overridden by sufficiently crafted user inputs — a question that standard model card templates do not address.

Hallucination Rate and Grounding Evaluation. Document the model’s hallucination rate on standardized benchmarks — including the benchmark name, version, and evaluation methodology. Hallucination rates vary significantly by task type (factual QA vs. summarization vs. code generation) and by domain (medical, legal, financial information tends to produce higher hallucination rates than general knowledge). For high-risk deployments in healthcare, legal, or financial services, the hallucination rate section of the model card is among the most important disclosures a provider can make — and its absence from a model card submitted to regulators in those sectors will be noted. Where the model is deployed with a retrieval-augmented generation layer, document the grounding rate: the proportion of model outputs that can be attributed to retrieved source documents.

Refusal Rate and Safety Behavior. Document the model’s refusal rate — the proportion of inputs the model declines to respond to — and the categories of inputs that trigger refusal. A model with a very high refusal rate for borderline inputs may be safer but less useful for legitimate edge-case queries; a model with a very low refusal rate may be more capable but carry higher misuse risk. For EU AI Act compliance, documenting refusal behavior is directly relevant to the safety testing section — demonstrating that the model has defined response policies for prohibited use cases, and that those policies are consistently enforced. Refusal rate should be measured separately for direct harmful requests, indirect or jailbreak attempts, ambiguous dual-use queries, and false-positive refusals of legitimate requests.

Multi-Modal Inputs and Attack Surface. For multi-modal models accepting image, audio, or video inputs alongside text, document the additional attack surface created by each modality. Multi-modal adversarial attacks — including adversarially perturbed images that cause the model to ignore text instructions, and audio inputs that embed inaudible commands — represent a distinct risk category that text-only model cards do not address. Document which modalities the model accepts, what safety evaluation was conducted for each modality independently and in combination, and what guardrails are applied at the modality-specific input layer. For a deeper treatment of adversarial attacks on LLMs and multi-modal systems, see our guide to adversarial machine learning.

Agentic Use Disclosure. Document whether the model is intended to be used in agentic configurations — where it takes sequences of actions, calls external tools, browses the web, executes code, or operates with minimal human oversight across extended task horizons. Agentic deployments create fundamentally different risk profiles from single-turn inference — including prompt injection via environmental inputs, tool misuse, cascading errors across multi-step task execution, and identity and authorization risks that do not arise in standard conversational deployments. For model cards covering models intended for agentic use, this section should cross-reference the model’s function calling capabilities, the tool use authorization model, the human oversight requirements for agentic tasks, and any known vulnerabilities to prompt injection that could redirect the agent’s actions. Our guides to function calling and tool use and prompt injection provide the technical background for documenting these risks accurately.

10. ✔️ Model Card Completion Checklist — 7-Section Quick Reference

The 10-section template in Section 3 of this article provides the complete copy-paste structure for a full model card. But in practice, model card completion often stalls because the template is too detailed to review quickly — it is not easy to scan a 10-section document and confirm at a glance that nothing has been omitted. The checklist below condenses the mandatory content into a 7-section quick-reference format that functions as a pre-publication gate for any model card, regardless of the full template format used. Before marking any model card as ready for production, run through this checklist and confirm every item has a substantive answer — not a placeholder, not an “N/A” without explanation, and not a qualitative statement where a quantitative one is possible.

This checklist is designed to be used by the person responsible for model card sign-off — not the person who wrote the card. The author is too close to the content to catch gaps that a reviewer with the checklist will catch immediately. The seven sections correspond to the seven areas most commonly cited by regulators, auditors, and enterprise deployers as the areas where submitted model cards are most frequently incomplete.

☐ Section 1 — Identity and Contact
☐ Model name and version number specified — not generic
☐ Provider organization name included
☐ Contact email or governance portal URL present and valid
☐ License type explicitly stated
☐ Last updated date reflects current version — not initial release date

☐ Section 2 — Intended Use
☐ Primary intended use described with sufficient precision to distinguish appropriate from inappropriate deployments
☐ Intended users named — not “general users” or “enterprises”
☐ Out-of-scope uses explicitly listed — not implied
☐ Prohibited uses listed, including reference to EU AI Act Article 5 prohibited practices where applicable
☐ Agentic use disclosed if applicable

☐ Section 3 — Training Data
☐ Training dataset(s) named — not described only as “proprietary” without further detail
☐ Data collection period specified — with start and end dates
☐ Known data gaps explicitly documented — including underrepresented groups, languages, or time periods
☐ Data governance section confirms consent, licensing, and privacy compliance
☐ Link to Datasheet for Datasets included where a public or internal datasheet exists

☐ Section 4 — Performance
☐ Benchmark scores provided with benchmark name, version, and evaluation date
☐ Evaluation dataset specified and confirmed separate from training data
☐ Disaggregated performance included — broken down by at least one relevant demographic or domain dimension
☐ Performance limitations stated for specific failure conditions — not described only as “may perform worse in some cases”
☐ For LLMs: hallucination rate documented with methodology

☐ Section 5 — Bias and Fairness
☐ Specific identified biases named — not “model may exhibit bias”
☐ Bias mitigation steps documented with description of what was done, not just that bias mitigation occurred
☐ Residual bias risk quantified or estimated — not left at “low” without basis
☐ Fairness evaluation methodology named — which metrics, which groups, which evaluation data
☐ Post-deployment bias monitoring recommendation included

☐ Section 6 — Safety and Human Oversight
☐ Safety testing completed — red team methodology and date stated
☐ Safety mitigations described with specific controls named, not described as “guardrails in place”
☐ Residual safety risks stated — including any known jailbreak vectors or adversarial vulnerabilities
☐ Required human oversight level stated with decision authority thresholds specified
☐ Escalation triggers documented — conditions requiring human review before model output is acted upon
☐ Accountability owner role named — not left as “the deploying organization”

☐ Section 7 — Versioning and Living Document Status
☐ Version history includes previous version and link to previous model card
☐ Changes in current version described — not summarized as “various improvements”
☐ Planned future updates documented where known
☐ Deprecation plan stated — or explicitly noted as “no deprecation planned at this time” with next review date
☐ Review cadence confirmed — model card owner has scheduled next review and it is documented

Any checklist item that cannot be completed without using vague, non-specific language is a content gap in the model card — not a drafting problem. The solution is not better phrasing. It is returning to the evaluation data, the safety testing records, or the governance process to obtain the specific information that the checklist item requires. A model card that passes this checklist with specific, quantified, honest answers to every item is a model card that will withstand regulatory scrutiny. One that passes only by treating the checklist items as questions to be answered in any form is a compliance document in name only.

11. 👥 Model Card Ownership — Who Writes, Approves, Maintains, and Audits

One of the most frequently overlooked elements of a model card program is the governance structure around the document itself. Organizations invest significant effort in the content of their model cards — the template, the benchmark data, the bias evaluation — and then assign no one to maintain it, review it on a cadence, or update it when the model changes. The result is a model card that is accurate at the point of initial publication and progressively less accurate with every subsequent retraining event, fine-tuning run, or new deployment context — until the document no longer reflects the system it purports to describe. EU AI Act Article 13’s expectation that documentation reflects the current state of the system makes this a compliance failure, not just a documentation hygiene issue.

A functional model card ownership structure requires four distinct roles. These roles may be held by four different individuals in a large AI team, or by two or three people in a smaller organization — but the responsibilities must be explicitly assigned regardless of how they are distributed. Leaving model card governance to “the team” or “whoever wrote it” is equivalent to leaving it to no one.

Role 1: Model Card Author. The Author is responsible for drafting and completing the model card content. This is typically an ML engineer or AI researcher with direct knowledge of the model’s architecture, training process, evaluation methodology, and known limitations. The Author does not have final accountability for the model card’s accuracy — that rests with the Approver — but they are the primary subject matter expert whose knowledge the document depends on. The Author must be identified by name and role in the model card’s ownership metadata, and must commit to briefing the Approver on any model changes that require a card update before the next scheduled review. For LLM-specific fields — hallucination rate, context window details, agentic behavior, system prompt documentation — the Author may need to involve additional subject matter experts (security engineers for adversarial vulnerability sections, data governance teams for training data sections) and should document which experts contributed to which sections.

Role 2: Model Card Approver. The Approver is responsible for reviewing the completed model card against the compliance requirements applicable to the deployment — EU AI Act Article 13, ISO 42001 A.8.4, internal governance standards — and formally approving it as accurate and complete before it is published or submitted to a deployer or regulator. The Approver is typically a governance, compliance, or legal role rather than a technical role — someone who can evaluate whether the model card satisfies documentation obligations without necessarily being able to evaluate whether the benchmark data is correctly calculated. The Approver’s sign-off is what transforms the model card from a technical document into a compliance artifact — and that sign-off must be documented, dated, and retained as part of the model governance record. In organizations pursuing ISO 42001 certification, the Approver function may need to be fulfilled by someone with management authority over the AI system rather than by a peer reviewer.

Role 3: Model Card Maintainer. The Maintainer is responsible for keeping the model card current throughout the operational life of the model. This is the role most frequently left unfilled in practice, and its absence is the direct cause of the “written once, never updated” model card failure mode. The Maintainer must monitor the model’s evolution — retraining events, fine-tuning runs, new deployment contexts, safety incidents, post-market monitoring findings — and trigger a card update whenever a material change occurs. “Material change” should be defined in the organization’s model governance policy, not left to judgment: common materiality thresholds include any change to training data composition, any performance change exceeding a defined threshold on a key benchmark, any new deployment context outside the original intended use, and any safety incident that reveals a previously undocumented failure mode. The Maintainer does not necessarily author the updates — they coordinate the update process, involving the Author and triggering a new Approver review for any substantive revision.

Role 4: Model Card Auditor. The Auditor is responsible for periodic independent review of the model card to confirm that it accurately reflects the deployed system. In small organizations, this may be an internal reviewer from outside the team that built the model; in large organizations or those subject to external audit requirements, it may be an external auditor or a notified body reviewer for EU AI Act conformity assessment purposes. The Auditor’s role is adversarial by design — they are looking for gaps between what the model card claims and what the model actually does, between what the training data section documents and what the data governance records show, and between the human oversight requirements stated in the card and the oversight controls actually implemented in production. The frequency of audit reviews should be proportional to the risk tier of the deployment: annually for lower-risk internal systems, semi-annually or on-change for high-risk EU AI Act systems. Audit findings should be documented and fed back into a card update within a defined remediation period — not added to a backlog and addressed in the next major revision.

The four-role ownership structure described above maps directly to ISO 42001’s documented information requirements, which specify not just that documentation must exist but that organizations must control it — ensuring it remains appropriate for its purpose, is protected from unintended alteration, and is retained and disposed of appropriately. A model card without a defined Maintainer and Auditor is documented information without control — and an ISO 42001 auditor reviewing your AI management system will identify the absence of that control as a nonconformity. Building the ownership structure before the model card is published, and recording the role assignments in the card’s ownership metadata section, is the minimum governance requirement for a model card that functions as a genuine compliance instrument rather than a documentation artifact.

12. 🏁 Conclusion: Model Cards Are Now Compliance Infrastructure, Not Documentation Overhead

The status of model cards in 2026 has completed a journey from academic proposal to industry best practice to legal requirement in eight years. The EU AI Act’s August 2026 deadline has created a clear before-and-after: before, model cards were produced by organizations that took AI transparency seriously as an ethical commitment. After, they are required from any organization deploying high-risk AI in EU markets — with enforcement consequences for those who treat them as optional. The Colorado AI Act creates parallel obligations at the US state level. ISO 42001 builds them into the documented information requirements of a certified AI management system. The direction of regulatory travel is unambiguous and it is consistent across jurisdictions: AI documentation that was voluntary yesterday is mandatory today and will be audited tomorrow.

The practical guidance for organizations that have not yet built a model card program is simple: start with the template in this article, study the real-world examples from Google, Meta, and Hugging Face to understand what completeness looks like, and treat model card completion as a pre-deployment gate rather than a post-deployment documentation exercise. A model card written after a deployment incident is not a governance document — it is a retrospective that arrives too late to prevent the harm it describes. The organizations that are navigating the 2026 AI regulatory environment most effectively are the ones that built their documentation infrastructure before it was required, rather than racing to satisfy compliance requirements after regulators began asking for evidence. Use the template in this guide, document honestly, update consistently, and build model cards into every AI deployment workflow before the first production query runs — not the day before the audit.

📌 Key Takeaways

❓ Frequently Asked Questions: AI Model Cards

What is an AI model card and what does it contain?

An AI model card is a structured transparency document that describes a trained machine learning model — including its intended use, training data, performance benchmarks, known limitations, bias evaluation, safety testing results, and human oversight requirements. Model cards were introduced by Google researchers (Mitchell et al.) in 2019 and have since been adopted as the primary format for AI transparency documentation across industry and regulation. In 2026, a complete model card for EU AI Act high-risk systems contains ten or more sections covering everything from provider identity and contact details to versioning history and post-market monitoring references. The model card describes the ML model artifact itself — it is paired with an AI system card (for the deployed application) and a Datasheet for Datasets (for the training data) to form a complete transparency documentation package.

Is a model card legally required in 2026?

For high-risk AI systems deployed in EU markets, yes — model card documentation is effectively required under EU AI Act Article 11 (technical documentation) and Article 13 (transparency and provision of information to deployers), both of which became fully enforceable in August 2026. The GPAI Code of Practice (final July 10, 2025) additionally requires all general-purpose AI providers to maintain technical documentation with a minimum 10-year retention period. The Colorado AI Act (effective February 2026) creates parallel documentation and bias impact assessment obligations for high-risk AI in employment, housing, healthcare, and financial services at the US state level. For lower-risk AI deployments outside EU high-risk categories, model cards are not legally mandated but are expected by enterprise deployers, required for ISO 42001 certification, and recommended by NIST AI RMF governance controls. The direction of regulatory travel is unambiguous: documentation that is voluntary today will be required tomorrow.

What is the difference between a model card and an AI system card?

A model card documents the trained ML model artifact — the weights, the training data, the performance benchmarks, the known biases, and the safety testing results. It describes the model as a technical object, independent of how it is deployed. An AI system card documents the complete deployed application built on top of that model — including the retrieval layer, the safety filters, the system prompt, the human oversight mechanisms, and the full user-facing product. The system card answers the question “how is this model being used in production?” rather than “what does this model do?” For EU AI Act Article 13 compliance, both documents are required: the model card satisfies Article 11 technical documentation requirements; the system card satisfies Article 13 deployer information requirements. Our dedicated guide to AI system cards covers the additional fields and governance requirements that system-level documentation introduces beyond the model card baseline.

What EU AI Act requirements must a model card satisfy?

A model card for a high-risk AI system must address the EU AI Act’s requirements across three primary articles. Article 11 (technical documentation) requires documentation before market placement covering: a general system description and intended purpose; development process detail including training data, architecture, and computational resources; monitoring and control information; risk management system description; lifecycle change history; performance evaluation methodology; and a post-market monitoring plan. Article 13 (transparency to deployers) requires clear information on: provider identity and contact; system characteristics, capabilities, and limitations; disaggregated performance metrics; pre-determined system changes; human oversight measures; computational requirements; and data retention for automated logs. Article 15 (accuracy, robustness, and cybersecurity) requires documentation of performance standards and adversarial testing. A model card satisfies approximately 50–60% of Annex IV’s eight technical documentation categories directly — the remaining requirements for post-market monitoring plans, conformity assessment records, and operational oversight documentation require supplementary documents beyond the model card itself.

How often should a model card be updated?

A model card should be updated whenever a material change occurs to the model or its deployment — not on a fixed calendar schedule alone. Material changes that require an immediate model card update include: any retraining event that changes the model’s weights or training data composition; any fine-tuning run that modifies model behavior; any new deployment context outside the original intended use described in the card; any safety incident that reveals a previously undocumented failure mode or vulnerability; and any performance evaluation that identifies a significant change in benchmark scores or disaggregated performance across demographic groups. Beyond event-triggered updates, a model card should undergo a scheduled review at minimum annually for lower-risk systems and semi-annually for EU AI Act high-risk systems. ISO 42001 Control A.8.4 requires the documented information to be kept current — a model card that is not updated after model changes is a nonconformity in an ISO 42001-certified AI management system. The EU AI Act’s Article 72 post-market monitoring requirements additionally create an obligation to update technical documentation in response to monitoring findings throughout the operational lifetime of the system.

What are the most common mistakes in model card documentation?

The six most common model card documentation failures — and the ones most likely to be flagged by regulators, auditors, or enterprise deployers — are: (1) No disaggregated performance data — reporting only aggregate accuracy or F1 scores without breaking down performance by demographic group, language, or domain, which fails EU AI Act high-risk requirements and the Colorado AI Act’s bias impact assessment mandate. (2) Vague limitation statements — writing “the model may perform worse in some conditions” rather than specifying which conditions, which metrics, and by how much. (3) No version history — treating the model card as a static document rather than a living record updated at every model change. (4) Missing human oversight detail — stating that “human oversight is required” without specifying the required oversight level, the decision authority thresholds, the escalation triggers, or the named accountability owner. (5) Absent ownership structure — no assigned Maintainer responsible for keeping the card current after initial publication, producing the “written once, never updated” failure mode. (6) LLM fields omitted from LLM cards — using an unmodified classical ML model card template for a large language model, missing hallucination rate, context window limits, alignment methodology, system prompt behavior, and agentic use disclosure that enterprise deployers and regulators increasingly require.

🔗 Related Articles

• 📖 AI System Cards Explained: How to Document AI Apps for Transparency, Safety, and Trust
• 📖 EU AI Act Explained: A Beginner-Friendly Compliance Guide and Practical Checklist
• 📖 Datasheets for Datasets Explained: How to Document AI Data for Quality, Privacy, and Trust
• 📖 AI Governance Explained: How to Build an AI Policy Framework Your Organization Will Follow
• 📖 AI Risk Assessment: How to Evaluate AI Use Cases Before You Deploy Them
• 📖 ISO/IEC 42001 Explained: The AI Management System Standard Your Organization Needs in 2026
• 📖 Adversarial Machine Learning Explained: Attacks, Defences, and the 2026 LLM Threat Landscape
• 📖 Function Calling and Tool Use Explained: How AI Models Interact With External Systems