TL;DR: AI Model Cards in 2026: What Regulators Now Expect and How to Write One, a practical compliance guide for enterprise and HR teams in 2026.
When researchers at Google published "Model Cards for Model Reporting" in 2018, the document was a proposal for a voluntary best practice. The authors, led by Margaret Mitchell and Timnit Gebru, argued that machine learning models should come with standardized documentation, the way prescription drugs come with package inserts. They imagined model cards as a tool for transparency, not a compliance artifact.
By 2026, that framing has shifted substantially. Three regulatory instruments now either require model documentation outright or treat it as a material governance obligation: the EU AI Act's Article 53, California's AB 2013, and the NIST AI Risk Management Framework. Product teams and legal counsel at AI companies can no longer treat model cards as a marketing decision or a voluntary disclosure. Getting the documentation wrong creates regulatory exposure. Getting it right creates a compliance asset that speeds up enterprise sales cycles, reduces due-diligence friction, and protects against enforcement.
This guide walks through what each regulatory requirement demands, how they overlap and differ, what a compliant model card looks like in 2026, and what the most common gaps in published documentation create as legal risk.
The original model card concept and what regulators borrowed from it
The 2018 Mitchell et al. paper proposed that every deployed machine learning model should come with a short document covering six areas: the model details (architecture, version, training dates), the intended use, the factors that affect performance (such as demographic group or operating environment), the evaluation results by subgroup, the training data, and quantitative analysis of performance variation.
The framing was explicitly about transparency across demographic groups. The paper's examples centered on face recognition and smile detection models where performance varied by skin tone and gender. The authors were trying to make algorithmic disparate impact visible.
Regulators picked up the concept but expanded the scope significantly. The EU AI Act's technical documentation requirements care less about demographic subgroup analysis and more about system-level information for enforcement: what compute was used, what data was sourced from where, what the model's capabilities are at a technical level. California AB 2013 cares primarily about data provenance and whether personal information was used in training. NIST AI RMF cares about risk management across the model lifecycle.
None of these regulatory instruments directly cites the 2018 paper. But the underlying logic is the same: require documentation before deployment rather than after harm occurs.
What EU AI Act Article 53 requires from GPAI providers
Article 53 of the EU AI Act applies to providers of general-purpose AI models: models trained on large volumes of data at scale that can serve a wide range of tasks. The most common examples are large language models, text-to-image models, and multimodal models. Providers placing these models on the EU market, whether through an API or as downloadable weights, must comply.
The specific content requirements are in Annex XI of the Act. For the technical documentation that all GPAI providers must maintain, the requirements include:
A general description of the model, including the architecture type, the number of parameters, the modalities supported, and the version.
A description of the training process, including the training methodology, the optimizer used, the hardware used for training, and the training compute in floating-point operations.
Information about the training data, including the data collection methodology, the data sources and their characteristics, the languages represented, the approximate volume measured in tokens or other relevant units, and the data filtering and cleaning process applied.
A description of the evaluation approach, listing the benchmarks used, their versions, the dataset splits used for evaluation, and the results achieved. This must be specific enough that the AI Office could independently verify the evaluation.
A description of the intended use cases and foreseeable misuse cases, with particular attention to uses that the provider has actively marketed or enabled.
Known limitations and failure modes, including performance degradation in specific contexts, known biases in outputs, and tasks the model cannot reliably perform.
The documentation must be kept up to date. When a provider releases an updated model version that materially changes any of these properties, the documentation must be updated before the new version is made available. The AI Office can request documentation at any time; providers must respond within a defined window.
For GPAI providers who also offer models classified as having systemic risk (models trained with more than 10^25 FLOPs), additional technical documentation is required under Article 55. This includes the systemic-risk assessment methodology and results, red-teaming test results, incident logs, and cybersecurity protection measures.
Companies that act as downstream deployers rather than original model providers have lighter documentation obligations. A company that fine-tunes an open-weight model and deploys it in a product must document that the underlying model is GPAI-compliant and must maintain documentation of the fine-tuning process and any capability changes introduced. They do not need to reproduce the base model documentation, but they must reference it.
California AB 2013 and the training data summary requirement
California Assembly Bill 2013 was signed by Governor Newsom on 28 September 2024 and took effect on 1 January 2026. It applies to developers of generative AI systems that are publicly available to Californians, including systems made available through a paid subscription or a free tier.
The requirement is more targeted than the EU AI Act. AB 2013 does not require full technical documentation. It requires a publicly accessible training data disclosure that covers:
The high-level description of the datasets used in training and post-training, including the primary sources or owners of each dataset.
Whether any of the training data was purchased or licensed, or whether it was collected from publicly available sources.
Whether the training data included personal information as defined under the California Consumer Privacy Act, and if so, a description of what categories of personal information were included.
The dates of data collection for each dataset, or the date range during which the data was collected.
The disclosure must be posted on the developer's website in a manner reasonably accessible to the public. It cannot be placed behind a login, a terms-of-service agreement wall, or a page that requires account creation to access.
AB 2013 includes an exemption for AI systems used solely for internal testing and research, and for systems not yet publicly available. But once a system is made publicly available to any California user, the disclosure obligation applies.
The most practically significant aspect of AB 2013 is the data collection date requirement. Many AI companies have published high-level training data descriptions but have not disclosed specific collection dates. The California Attorney General can bring enforcement actions for non-compliant disclosures, and several consumer privacy organizations have flagged AB 2013 compliance monitoring as a priority for 2026.
If a company has already prepared EU AI Act technical documentation that includes training data descriptions, much of the California AB 2013 content can be derived from that documentation. The formats are different, and the California disclosure is designed for public consumption while the EU documentation is primarily for regulators, but the underlying factual content overlaps significantly.
See the EU AI Act compliance guide for small teams for how to integrate these documentation requirements into a single compliance workflow.
How NIST AI RMF treats model documentation
The NIST AI Risk Management Framework, published in January 2023 and updated in 2024, treats model cards as a core governance artifact in its "Govern" and "Map" functions. Unlike the EU AI Act and AB 2013, NIST AI RMF does not impose legal requirements. But it is referenced in an increasing number of regulatory and contractual contexts that do create legal obligations.
The Texas Responsible AI Governance Act (TRAIGA) passed in 2025 references NIST AI RMF as a safe harbor: companies that can demonstrate compliance with the framework's practices are entitled to a presumption of reasonable care in the event of harm caused by an AI system. Several enterprise procurement contracts and federal government contracts now require AI suppliers to demonstrate NIST AI RMF alignment. The FTC has cited NIST AI RMF practices in AI-related enforcement actions as evidence of what reasonable AI governance looks like.
Under NIST AI RMF, model documentation is expected to cover the entire model lifecycle, not just the pre-deployment snapshot. This means the model card should include: the original evaluation results at launch, any changes to performance observed post-deployment, incidents or near-misses involving the model, and updates made in response to identified risks.
This lifecycle framing is the key difference between NIST AI RMF's approach and the static document approach implied by the regulatory requirements. A model card that satisfies NIST AI RMF is a living document with version history, not a one-time filing.
The AI tool register template shows how to track model versions and documentation updates across an organization's AI tool inventory.
A template with the 8 sections regulators now check
Based on the requirements above, a model card that satisfies EU AI Act Article 53, California AB 2013, and NIST AI RMF governance expectations needs to cover these eight sections:
Section 1: Model identification. The model name, version number, release date, developer or provider name, and a brief statement of what the model does. This section should also include a link to the prior version's card for version continuity.
Section 2: Technical specifications. Architecture type (transformer, diffusion model, etc.), parameter count, modalities supported, context window or input constraints, and the hardware used for training. Include training compute in FLOPs if the model qualifies as GPAI under the EU AI Act.
Section 3: Training data. For each dataset used: the source or owner, whether it was purchased, licensed, or publicly collected, the collection date range, the approximate volume, the primary languages represented, and whether personal data as defined under CCPA was included. This section directly satisfies AB 2013 disclosure requirements.
Section 4: Training process. The training methodology, the optimization approach, any post-training techniques applied (RLHF, DPO, supervised fine-tuning), and the date the training run completed.
Section 5: Evaluation results. For each benchmark used: the benchmark name and version, the evaluation dataset and split, the metric used, and the result achieved. Include evaluations across demographic groups or language subgroups where relevant.
Section 6: Intended uses and out-of-scope uses. What the model is designed for, the specific use cases the provider actively supports, and use cases the provider explicitly does not support and will not assist with.
Section 7: Known limitations and risks. Performance degradation in specific contexts or languages, known biases in outputs, failure modes observed in testing, and populations or use cases where the model has demonstrated unreliable performance.
Section 8: Update log. A dated record of changes to the model card, including what changed and why. This section is required for NIST AI RMF alignment and is good practice for avoiding compliance drift as models are updated.
The AI governance checklist 2026 includes model card completion as one of the core governance milestones before deployment.
Common gaps that create compliance risk
Reviewing publicly available model cards from major providers reveals a consistent set of gaps that create legal exposure or enforcement risk.
Vague training data dates. Many published model cards say something like "data collected through early 2024" without specifying the collection window per dataset. California AB 2013 requires specific date ranges per dataset. A vague statement does not satisfy the requirement.
Unlisted benchmark versions. A model card that says "we evaluated on MMLU with a score of 87.2%" without specifying which version of MMLU and which dataset split was used cannot be independently verified. The EU AI Office has signaled that unverifiable benchmark claims may be treated as incomplete documentation.
Missing coverage of model updates. A card prepared at a model's initial release often omits information about subsequent fine-tuning, safety training modifications, or capability additions. When a model is updated, the card must be updated too. Cards that fall out of sync with the deployed model create a discrepancy that enforcement investigators can use as evidence of inadequate governance.
No personal data disclosure. Companies that trained on web-scraped data that included social media posts, blog entries, or forum comments likely trained on content that qualifies as personal data under CCPA. Cards that are silent on this point may fail the AB 2013 disclosure requirement. The obligation is to disclose whether personal data was included, not to have avoided it.
Absent demographic or subgroup evaluation. The original Mitchell et al. model card framework centered on this, and NIST AI RMF expects it, but many published cards omit subgroup evaluation entirely, particularly for language models. For high-risk AI systems under the EU AI Act, this gap can prevent downstream deployers from completing the fundamental rights impact assessments they are required to conduct.
No update log or version history. Cards that are silently replaced when a new model version launches leave no trace of what the prior documentation said. If a regulatory investigation covers a period during which multiple model versions were deployed, the absence of version-specific documentation makes it impossible to demonstrate what governance was in place at each point.
The pattern across these gaps is the same: model cards were initially written as communications tools, and their compliance function was added afterward. Teams that treat the model card as a regulatory document from the start and build update processes around it avoid most of these problems.
