AB 2013 Documentation Guide: How to Write a Compliant Training Data Summary in 2026

California AB 2013 — the Generative Artificial Intelligence: Training Data Transparency Act — took effect January 1, 2026 and requires developers of generative AI systems made publicly available to Californians to post a high-level summary of their training data, organized around twelve enumerated disclosure categories. This guide walks through what each of those twelve categories actually asks for, how to write a summary that is "high-level" without being evasive, what the early implementation pattern from OpenAI and Anthropic looks like, and what the xAI litigation tells us about the trade-secret limits of the statute. It is built for the engineer, compliance lead, or general counsel who needs to ship a working disclosure this quarter — not a 2024-vintage preview of a law that's already in force.

What AB 2013 actually says (and what it doesn't)

AB 2013 is a transparency statute, not a content statute. It does not regulate what data you can train on, whether you can use copyrighted material, or how you must obtain consent. It only regulates what you must tell the public about the data you used. The covered behavior is making a generative AI system publicly available to Californians at any point on or after January 1, 2026, where that system was first released or substantially modified on or after January 1, 2022. The compliance act is publishing a documented, high-level summary on the developer's website. The statute applies regardless of whether use of the system involves payment, which means free chatbots, free image generators, and freemium products are covered as squarely as paid services.

Two things AB 2013 does not contain are worth flagging up front. First, there is no trade-secret exemption — the absence is conspicuous, and is the central argument in the xAI v. Bonta litigation. Second, there is no standalone enforcement mechanism. The statute is enforceable through California's Unfair Competition Law (UCL), which the Attorney General, district attorneys, certain city attorneys, and (for actual injury) private plaintiffs can invoke. UCL penalties cap at $2,500 per violation, but the more meaningful exposure is class-action and reputational, especially because compliance disclosures are public and become discoverable evidence in unrelated copyright and privacy litigation.

The 12 required disclosure categories, in plain language

The statute enumerates twelve items the "high-level summary" must cover. Treat this as your document outline and you cannot accidentally omit a required field. The first category is the sources or owners of the datasets — who provided or owned the data, whether commercial vendor, public-web crawl, licensed corpus, or user-generated. The second is how the datasets further the system's intended purpose — a brief explanation of why each dataset was selected. The third is the number of data points, which the statute permits as a general range or as an estimate for dynamic datasets, so "approximately 12 billion text tokens" or "between 100M and 500M images" satisfies the standard.

The fourth category is a description of the types of data points — either the labels used (for supervised data) or general characteristics (for unsupervised). Fifth is copyright/trademark/patent status: whether the data is protected, public-domain, or mixed. Sixth is licensing and acquisition method: whether you purchased, licensed, or otherwise obtained the data. Seventh is whether the data includes personal information as defined by the CCPA. Eighth is whether it includes aggregate consumer information, a separate CCPA-defined category. Ninth is the time period during which the data was collected. Tenth is the dates of first use in training. Eleventh is whether the developer modified or cleaned the data and a description of those modifications. Twelfth is whether the system used or continuously uses synthetic data generation, with an optional description of the functional purpose of that synthetic data.

A practical compliance pattern that is now emerging from major-vendor disclosures: organize the document as a list of dataset categories (e.g., "Public Web Crawl," "Licensed Books," "Synthetic Reasoning Traces," "Code Repositories," "User Conversations"), and answer the twelve enumerated questions for each category. This is more useful for readers than a flat document and is easier to maintain when datasets change.

How "high-level" is high-level? The xAI litigation as a real-world test

The single most asked question about AB 2013 is what "high-level" actually means in practice. The statute does not define it. Until very recently this was pure speculation, but the post-effective-date evidence is now meaningful. As of January 2026, OpenAI and Anthropic both posted AB 2013 disclosures on their websites — described in legal commentary as "generalized" in OpenAI's case and as enumerating the statutory categories without disclosing dataset-level proprietary detail. Neither company sued.

xAI took the opposite path. On December 29, 2025, three days before AB 2013 took effect, xAI filed a federal complaint in the Central District of California against Attorney General Rob Bonta, asserting that the statute is an "unconstitutional trade-secrets-destroying disclosure regime." The complaint advanced four counts: per se Takings, regulatory Takings, compelled speech in violation of the First Amendment, and unconstitutional vagueness under the Due Process Clause. xAI sought a preliminary injunction. On March 4, 2026, Judge Jesus G. Bernal denied the motion, finding that xAI had standing but had not demonstrated a likelihood of success on any of the three constitutional theories. The case continues, but enforcement was not blocked.

The most useful piece of the ruling for compliance teams was implicit rather than explicit: the court was unimpressed by xAI's generalized trade-secret claims given that similarly situated competitors (OpenAI, Anthropic) had complied without apparent harm. That tells you the practical floor: if a model card or disclosure of comparable specificity to what OpenAI and Anthropic published is in the field, your "but it's a trade secret" argument needs to be specific to your situation, not generalized. The complement is also true — if you publish at materially less detail than your competitors and a regulator notices, you do not have a strong "everyone redacts" defense.

A working AB 2013 documentation process

For teams that are still building this, the right sequence is roughly as follows. Begin by inventorying every dataset used in training, fine-tuning, or substantial modification of every covered system. The legal definition of "train" explicitly includes testing, validation, and fine-tuning, so RLHF data, evaluation sets, and reward-model training data are all in scope, not just pretraining corpora. Then categorize: cluster datasets into logical groups (public web, licensed text, licensed media, user-contributed, synthetic, code, instruction-tuning). For each group, answer the twelve enumerated questions. Where any answer is genuinely sensitive, document the redaction and its specific justification. Have legal review the draft against trade-secret risk, with attention to whether your redactions hold up against the "but your competitor disclosed it" comparator. Publish on a stable, easy-to-find URL on your developer-facing website. Add a date and version. Update on substantial modifications. This guide's companion piece, the step-by-step inventory walkthrough, covers the audit phase in more depth, and the high-level summary writing guide covers tone and structure.

The retroactivity problem and how to handle it

AB 2013 reaches backward — it covers any covered system released or substantially modified on or after January 1, 2022. For models trained in 2022 or 2023, before formal data-provenance practices were widespread, retrospective documentation is genuinely difficult. Many engineering teams did not retain detailed dataset manifests, license records, or modification logs from that era. The statute does not provide grace for this. Three practical approaches have emerged. First, reconstruct from secondary sources — git history, dataset access logs, vendor invoices, and engineering Slack archives can often reconstruct enough to answer the twelve categories at a defensible level. Second, narrow the scope: a substantial modification (a major retraining or significant fine-tune) restarts the relevant disclosure clock for that version, so for many actively-developed systems the practical compliance horizon is the most recent training run, not the original 2022 one. Third, where reconstruction is impossible, disclose the gap: an honest statement that records prior to a specific date are incomplete is better than a fabricated retrospective and is consistent with the statute's spirit. Goodwin's post-effective-date analysis flags this as one of the most contested compliance areas to watch.

How AB 2013 fits with the rest of California's 2026 AI regime

AB 2013 is one of five statutes you should think about as a single compliance posture. It governs training data transparency. SB 942 governs watermarking and provenance for AI-generated output. SB 53 (the TFAIA, also effective January 1, 2026) governs catastrophic-risk safety frameworks for frontier developers above the 10^26 FLOP threshold. The CCPA/ADMT regulations from the California Privacy Protection Agency govern automated decision-making technology used for significant decisions. AB 489 and AB 3030 govern healthcare-specific AI behavior. For most generative AI products available to Californians, AB 2013 and SB 942 apply at minimum; if your product makes significant decisions about people, ADMT layers in; if it ships into healthcare, AB 489 and AB 3030 layer in; if you are a frontier developer, SB 53 sits on top. Our 2026 California AI Compliance Roadmap walks the combined sequencing.

What to do this week

If you ship a generative AI system to Californians and have not published an AB 2013 disclosure, the law is already in force and the AG's office is reportedly building in-house AI expertise to evaluate disclosures. The minimum-viable path to compliance is: produce a structured document covering the twelve enumerated categories for your covered systems, post it at a stable URL on your developer site, link it from your privacy policy or developer documentation index, and version it. The structure is the easy part — our free Training Data Transparency Generator outputs the twelve-category skeleton so you do not omit required fields. The hard part is the substantive content, which has to come from your team. Block out engineering, legal, and data-governance time, draft for the categories above, and treat the published version as a living document that updates with substantial modifications.

Sources

The primary statute is AB 2013 on California Legislative Information. Post-effective-date implementation analysis comes from Goodwin Procter's January 2026 alert, Perkins Coie's compliance guide, and the post-xAI ruling analysis from Hintze Law via Mondaq. The xAI litigation is tracked by the IAPP's xAI v. Bonta explainer. The constitutional commentary from the Institute for Law & AI provides additional doctrinal context. Watch the IAPP and Goodwin pages for updates on the merits ruling, which is expected later in 2026, and on any AG-issued interpretive guidance that narrows or clarifies what "high-level" requires.