California’s AB 2013: the Training Data Disclosure Law

AB 2013 is short, and the whole of it is a list. A developer of a generative AI system made available to Californians must publish documentation about the data it was trained on. What makes it worth a page is that several of the required items are admissions rather than descriptions, and that the statute provides no penalty for not making them.

Who has to post, and for which systems

Assembly Bill 2013, signed on 28 September 2024, adds section 3111 to the California Civil Code. The bill record is at California Legislative Information, and the codified section is at the same site’s code display.

The duty falls on a developer, defined as a person, partnership, state or local government agency, or corporation that designs, codes, produces or substantially modifies an artificial intelligence system or service for use by members of the public. Two features of that definition are unusual and both widen it. Public agencies are inside it, which is rare in this area. And “substantially modifies” is defined to mean a new version, new release or update that materially changes functionality or performance, expressly including the results of retraining or fine tuning — so a company that fine-tunes somebody else’s model and releases it publicly is a developer with its own posting duty.

The systems covered are generative AI systems or services released on or after 1 January 2022 and made publicly available to Californians for use, regardless of whether the terms of use say the product is intended for use in California. The look-back is the point: this is not a forward-only obligation, and models already shipped are within it.

There are narrow exclusions, essentially for systems whose sole purpose is the security and integrity of a system, for the operation of aircraft in the national airspace, and for systems developed for national security, military or defence purposes made available only to a federal entity.

What the documentation must contain

The section enumerates the required contents. In substance, the posted documentation must include:

• the sources or owners of the datasets, at a high level of generality — who the data came from, not a file list;
• a description of how the datasets further the intended purpose of the system;
• the number of data points in the datasets, which may be given in general ranges and with estimated figures for dynamic datasets;
• a description of the types of data points, using the labels used in the datasets or, where unlabelled, their general characteristics;
• whether the datasets include any data protected by copyright, trademark or patent, or are entirely in the public domain;
• whether the datasets were purchased or licensed by the developer;
• whether the datasets include personal information as defined in the CCPA at Civil Code section 1798.140;
• whether the datasets include aggregate consumer information as defined in the same section;
• whether there was any cleaning, processing or other modification of the datasets, including the intended purpose of it and how it is consistent with the system’s intended purpose;
• the time period during which the data were collected, with notice if collection is ongoing;
• the dates the datasets were first used during development;
• whether the system used or continuously uses synthetic data generation in its development, optionally with a description of the functional need or desired purpose it serves.

Four of those are yes-or-no questions with consequences elsewhere. The copyright question is an admission that plaintiffs in training-data litigation will read — see the training data copyright page. The personal information question interacts with the CCPA, which since AB 1008 expressly contemplates personal information existing in training data and model output — see that page. The purchased-or-licensed question bears on both. And the ongoing collection question tells a reader whether the disclosure will remain accurate.

A summary, not the data

AB 2013 does not require publication of the training data, a dataset index, a list of URLs, or anything a third party could use to reconstruct the corpus. It requires documentation about the data at a level of generality the statute itself signals repeatedly — “high-level”, “general ranges”, “general characteristics”.

That is a deliberate design, and it is the same design the EU chose for the general-purpose AI model training-content summary under the AI Act, which asks for a sufficiently detailed summary on a template published by the AI Office. The two obligations are not identical — different templates, different triggers, different addressees — but a developer producing both should build one evidence base and render it twice rather than maintain two independent narratives that will eventually contradict each other. The EU side is covered in the training content summary page.

The practical difficulty in both is the same: the disclosure is easy to write for a corpus you assembled deliberately and very hard to write for one that accreted. If you cannot say when a dataset was first used in development, the problem is data lineage, not drafting, and it is not fixable at posting time.

The retraining trigger

The documentation had to be posted on or before 1 January 2026 for systems already released, and must be posted before each new version or substantially modified version released on or after that date. Because “substantially modifies” expressly includes retraining and fine tuning that materially changes functionality or performance, the obligation recurs on the model release cycle rather than annually.

For a team shipping fine-tunes frequently, that turns the disclosure into part of the release checklist. The failure mode is predictable: the first posting is careful and the fifth silently describes the first model’s data. A dated, versioned disclosure page that identifies which system version it describes is both better practice and easier to defend than a single evergreen page that quietly drifts out of date.

The enforcement gap

Section 3111 as enacted contains no penalty provision, no administrative enforcement mechanism, and no private right of action. This is a real feature of the statute and it is worth stating plainly rather than assuming a remedy exists.

What that does not mean is that non-compliance is costless. Two routes are available in principle and neither has been tested on this section. A failure to post, or a materially inaccurate posting, could be advanced as an unlawful or unfair business practice under California’s Unfair Competition Law at Business and Professions Code section 17200, which borrows violations of other statutes as predicates — but standing under that law requires injury in fact and lost money or property, which is a real obstacle for a pure disclosure failure. And a posted disclosure is a public statement by the company: an inaccurate one is usable as an admission in other litigation, and potentially as a deceptive statement in its own right. It is not yet clear whether either route works, and no decision this page can point to has decided it.

The asymmetry is therefore unusual. The cost of a careless disclosure — an admission that lands in a copyright case, or a statement that contradicts your CCPA position — is plausibly higher than the cost of no disclosure at all. That is an argument for taking the drafting seriously, not for skipping it.