A Practical Reading of AB 2013

California AB 2013 requires a covered AI developer to post website documentation about the data used to train a generative-AI system or service. The practical question is what that sentence includes: which public releases and modifications are covered, what a high-level summary must contain, and what conclusions the resulting document can support. Taken together, the statutory rule and the public statements from OpenAI and xAI point to a disciplined answer: AB 2013 creates structured visibility into development data, not a raw-corpus publication duty or a universal guarantee about the system.

That answer has three parts. First, determine whether the developer, system, release, and access arrangement fit the rule. Second, read the summary through the statute’s twelve disclosure categories, preserving the units, dates, and qualifiers the developer uses. Third, separate the fact that a developer reports a practice from the different question of whether the practice is lawful, private, safe, complete, fair, or effective. The order matters. A reader who begins with a provider’s impressive number or reassuring rights statement can miss the more basic question of what object and event the document actually describes.

The short answer: timely website documentation about training data

Section 3111 requires a developer, on or before January 1, 2026, and before each time thereafter that a covered generative-AI system or service—or a substantial modification to one—is made publicly available to Californians for use, to post documentation on the developer’s internet website. The obligation applies whether or not the use is compensated. The cited text covers systems or services released on or after January 1, 2022.

The required documentation concerns the data used by the developer to train the system or service. It must include a high-level summary of the datasets used in development and the specified information about those datasets. The law therefore establishes a public account of development data, its treatment, and its history. It does not, in the cited provisions, instruct the developer to publish every underlying record or to provide a separate safety, privacy, quality, or performance certification.

The phrase “high-level summary” is the key to the design. It sets a level of description without making the required subjects optional. A developer can summarize source classes rather than list every URL, report a general range rather than claim an exact immutable count for a dynamic dataset, and describe broad data characteristics rather than disclose the contents of every item. But the summary still has to address the categories the statute names.

The law’s basic exchange is therefore clear. The public receives more than a vague statement that “data was used,” but less than a complete public copy of the development corpus. That middle ground is not a loophole in the concept of transparency. It is the form of transparency the cited provisions specify.

Start with scope, not the checklist

Before evaluating a disclosure, identify the legal object. Section 3110 defines “developer” as a person, partnership, state or local government agency, or corporation that designs, codes, produces, or substantially modifies an AI system or service for use by members of the public. The relevant developer is thus identified by what they do in relation to a public system or service, not only by who originally trained a base model.

The statute defines “generative artificial intelligence” by function. It covers artificial intelligence that can generate derived synthetic content, including text, images, video, and audio, that emulates the structure and characteristics of the AI’s training data. A product label such as “assistant,” “copilot,” or “platform” does not replace that functional inquiry.

Next, check the release conditions. The system or service, or the relevant substantial modification, must fall within the statutory release-date boundary and be made publicly available to Californians for use. Compensation does not remove the duty. The text makes California public availability central, so a reader should not infer coverage or noncoverage merely from a company’s location, a model’s global reputation, or the theoretical possibility that someone in California could access it.

The final scope question concerns the event itself. A substantial modification is a new version, new release, or other update that materially changes functionality or performance, including the results of retraining or fine-tuning. The statute also says that “train” includes testing, validating, and fine-tuning by the developer. That language reaches beyond initial pretraining, but it does not mean that every internal experiment is automatically a new public trigger. The content of the development account and the existence of a new public release remain related but distinct questions.

There are three listed exclusions. The documentation duty does not apply to a generative-AI system whose sole purpose is helping ensure security and integrity; a system whose sole purpose is operating aircraft in the national airspace; or a system developed for national-security, military, or defense purposes that is made available only to a federal entity. The limiting words matter. A system with a security feature is not described by the cited text as automatically exempt. A government customer is not the same as availability only to a federal entity. A mixed-purpose system is not obviously a sole-purpose system.