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 the datasets were purchased or licensed by the developer, and whether they include data protected by copyright, trademark or patent or are entirely in the public domain.
Whether the datasets include personal information as defined under the California Consumer Privacy Act, and separately whether they include aggregate consumer information.
The time period during which the data in the datasets were collected (with a notice if collection is ongoing), and the dates the datasets were first used in development.
The documentation must be posted on the developer's website. The statute doesn't spell out a format, so we'd put it on a public page anyone can reach without an account.
AB 2013 exempts only three kinds of systems: those whose sole purpose is security and integrity, those whose sole purpose is operating aircraft in the national airspace, and national security, military or defense systems made available only to a federal entity. There's no exemption for internal testing. The trigger is making a system, or a substantial modification of it, publicly available to Californians.
The most practically significant aspect of AB 2013 is the collection-period requirement. Many AI companies have published high-level training data descriptions without saying when the data was collected. The statute itself doesn't name an enforcement mechanism or a penalty, which is a reason to document carefully rather than a reason to skip it.
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 with a companion Generative AI Profile added in July 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, HB 149) names NIST's Generative AI Profile in one of its defenses: a company can't be found liable for a violation it discovers through an internal review process while substantially complying with the most recent version of that profile or another recognized AI risk framework (enrolled text, Sec. 552.105(e)). A dated model card with an update log is the kind of review record that defense depends on. Some enterprise procurement contracts also ask AI suppliers to show NIST AI RMF alignment.
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 giving the collection period for each dataset. California AB 2013 asks for the time period during which the data in the datasets were collected and the dates they were first used in development, so a single cutoff date is thin.
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.
Correction, October 15, 2026: an earlier version said AB 2013 exempts AI systems used solely for internal testing and research, that the California Attorney General can bring enforcement actions and consumer privacy groups had flagged compliance, that the disclosure can't sit behind a login or terms wall, that developers must describe categories of personal information and whether data came from public sources, and that the law requires specific date ranges per dataset. The statute (Civil Code 3111) has three exemptions (security and integrity, aircraft operation, federal national security systems), names no enforcer, sets no format, asks whether datasets include personal information and whether they're copyrighted or public domain, and asks for the collection period and first-use dates.
Correction, October 20, 2026: an earlier version said TRAIGA treats NIST AI RMF as a safe harbor that gives a presumption of reasonable care to companies that follow it. HB 149 presumes reasonable care for everyone (Sec. 552.105(c)); the NIST-linked defense is separate, names the Generative AI Profile, and covers violations found through internal review. We also removed a claim that the FTC has cited NIST AI RMF practices in enforcement actions, which we couldn't source.
