California AI Transparency and Training-Data Disclosure Laws: The Documentation Burden Arriving in 2026

California’s AB 2013 turns a question your team probably cannot answer today into a published legal disclosure: what, exactly, was this model trained on. The documentation burden is real, it is retroactive, and it lands as an engineering problem long before it lands as a legal one.

Most commentary on AB 2013 has been written by lawyers, for lawyers, about litigation risk and trade secrets. That is a legitimate concern, but it is not the one that will keep a CTO awake. The problem for the technology function is more basic: the law asks you to describe the datasets behind a generative system in structured detail, and the honest answer for most teams is that nobody wrote it down at the time. This is a data-lineage problem dressed as a transparency statute, and you cannot reconstruct lineage you never captured.

What AB 2013 actually requires

AB 2013, the Generative Artificial Intelligence: Training Data Transparency Act, was codified as Section 3111 of the California Civil Code and took effect on 1 January 2026. It applies to a developer that designs, codes, produces or substantially modifies a generative AI system or service made available to Californians. Crucially, it reaches back: the obligation covers systems released, or substantially modified, on or after 1 January 2022. If you shipped or meaningfully updated a generative feature in the last few years and it is available in California, you are in scope, whether or not you consider yourself an AI company.

The requirement is to post, on the developer’s public website, a high-level summary of the datasets used to develop the system. The statute is specific about what that summary must address. Among the required elements:

• The sources or owners of the datasets.
• How the datasets further the intended purpose of the system, and the number of data points (general ranges and estimates are permitted).
• The types of data points and, where labelled, a description of the labels.
• Whether the datasets include material protected by copyright, trademark or patent, or in the public domain.
• Whether the datasets were purchased or licensed by the developer.
• Whether the datasets contain personal information or aggregate consumer information, as defined under the CCPA.
• Whether the developer cleaned, processed or otherwise modified the datasets, and to what end.
• The time period over which the data was collected, the dates the datasets were first used, and whether synthetic data generation was used.

There are narrow carve-outs, chiefly for systems whose sole purpose is security and integrity, the operation of aircraft, or national security and defence. Everything else consumer-facing is exposed. Read that list again as an engineer, not a lawyer, and the difficulty is obvious: almost every item is a fact about provenance that had to be true at the moment the data entered your pipeline. You cannot infer, after the fact, whether a scraped corpus was licensed, or which slice of it carried personal information, unless you recorded the answer when you ingested it.

Why most teams cannot produce this today

The uncomfortable truth is that training pipelines were built for throughput, not for evidence. Data was pulled from public sources, vendor feeds, internal logs and third-party corpora, concatenated, deduplicated, filtered and tokenised, and the metadata that would answer AB 2013 was discarded somewhere in the shuffle. Provenance was treated as overhead. The result is a classic instance of the data and governance debt that accumulates silently until a regulator gives it a due date.

Reconstruction after the fact is expensive and often impossible. If you fine-tuned an open-weight base model, you inherit the provenance questions of a dataset you did not assemble and may not be able to characterise. If you used a vendor’s foundation model under the bonnet, you depend on their disclosure to complete your own, which is precisely the AI supply-chain dependency that most contracts never addressed. The disclosure obligation sits with you as the developer of the deployed system, but the facts you need to disclose may be locked inside someone else’s pipeline.

This is a lineage-capture problem, so instrument the pipeline

The right response is not to write the disclosure. It is to build the system that produces the disclosure, so that the next model version documents itself. That means capturing, at ingestion, the source, the acquisition basis (scraped, purchased, licensed, internal), the collection window, the presence of personal or copyrighted material, and every transformation applied downstream. The dataset summary then becomes a report generated from a manifest, not a research project run against fading institutional memory.

Teams that have already engaged with the EU’s obligations have a head start, because the underlying discipline is the same. The provenance controls demanded by AI Act Article 10 on data governance and the structure of the GPAI public training-data summary template overlap heavily with what AB 2013 wants published. If you build a single lineage layer that can answer both, you are not maintaining two compliance regimes; you are maintaining one dataset manifest and rendering it into two formats. The alternative, standing up a bespoke California process, guarantees the work will be duplicated the moment the next jurisdiction asks the same question in a slightly different shape.

The companion laws widen the surface

AB 2013 does not arrive alone. California’s AI Transparency Act, SB 942 as amended by AB 853, sets a compliance date of 2 August 2026 for covered providers, broadly those whose generative systems exceed one million monthly users in the state. It requires a free AI-detection tool, manifest and latent provenance disclosures embedded in generated content, and carries a stated penalty of 5,000 dollars per violation, with each non-compliant day counted separately. Further duties on hosting platforms and large online platforms follow from 1 January 2027. Where AB 2013 asks what went into the model, SB 942 asks the model to mark what comes out of it. Both are provenance obligations; both assume infrastructure that most teams have not built.

AB 2013 itself is being litigated. In late December 2025, xAI filed suit arguing the disclosure requirement compels speech and forces the surrender of proprietary training data. However that resolves, betting your compliance posture on the statute being struck down is not a plan. The engineering work, capturing dataset lineage as a first-class output of the training pipeline, is worth doing regardless, because every serious AI regime now converging on the market wants the same evidence.

Dataset documentation has quietly become a shipping requirement rather than a research nicety. The teams that treat it as one, and instrument provenance before the model is trained, will publish a summary in an afternoon. The teams that did not will spend the year trying to remember what they fed the machine, and writing down the parts they cannot prove.