First Question: Does This Release Trigger the Law?
For California AB 2013, the first practical question is not yet what a developer must say about its datasets. It is whether the developer, the generative-AI system or service, and the release event fit the statute’s scope. This chapter traces that sequence so a reader can distinguish a covered public release or substantial modification from an ordinary internal experiment, without treating a product label as the legal test.
The distinction matters because a training-data summary is meaningful only when attached to the right object and the right event. “The model” may refer to an original system, a new version, a fine-tuned service, or an application that uses someone else’s model. The cited provisions do not resolve every possible product arrangement, but they provide a functional vocabulary for asking the scope question.
The law follows the public release
Section 3111 sets out two timing layers. The first is a general deadline: on or before January 1, 2026, the developer must meet the documentation duty for covered systems or services. The second is recurring: before each later time that a covered system or service, or a substantial modification to one, is made publicly available to Californians for use, the developer must post the required documentation. The text applies regardless of whether use is compensated.
That sentence contains several conditions that should be kept together.
The system or service must have been released on or after January 1, 2022. It must be made publicly available to Californians for use. And the party with the duty must be a developer as the statute defines that term. If one of those facts is unknown, a confident conclusion about scope is premature. The law’s California connection is not incidental: the trigger is public availability to Californians, not simply the fact that a company operates somewhere in the world or that a model could theoretically be accessed from California.
The timing rule also changes how to think about documentation. It is not best understood as a historical report filed once at the moment of initial pretraining. A later version or material update may create another event that matters. A public reader evaluating a system in 2026 therefore needs to ask which version or service the document describes, when it was made available, and whether the document belongs to that release or to an earlier stage.
The statute does not answer every edge case in the opening sentence. The retained text does not, for example, give a complete rule for geofenced access, private beta programs, enterprise-only arrangements, or every meaning of “publicly available.” Those questions require facts beyond the general wording. The safe reading is not that every ambiguous product is covered or that every ambiguous product is excluded. The safe reading is that the statutory conditions must be tested against the actual access arrangement.
Who counts as a developer?
Section 3110 defines “developer” by role. It includes 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. That definition makes the actor’s relationship to the system important. It does not say that only the organization that first trained a base model can be the relevant developer.
This matters in a layered AI market. One organization may produce a general-purpose model. Another may substantially modify or package a system for public use. A third may offer an application built around the system. The statutory definition does not let a reader decide the answer from business branding alone. The reader has to ask what each organization actually designed, produced, or substantially modified, and for whom the resulting system is intended.
The definition also uses “members of the public,” which gives the public-use relationship a central place in the scope analysis. A system built solely for an internal process may present a different question from a service made available to external users. But the available text does not provide a complete catalogue of all access patterns. A cautious explanation can identify the statutory boundary without pretending that the definition supplies an automatic answer for every contract, deployment, or distribution model.
What makes the system generative?
The statute defines “generative artificial intelligence” functionally. It means artificial intelligence that can generate derived synthetic content—such as text, images, video, and audio—that emulates the structure and characteristics of the artificial intelligence’s training data. The definition is therefore connected to what the system can generate, not to whether a provider calls it a foundation model, assistant, copilot, search product, or something else.
“Derived synthetic content” can sound abstract, so the practical point is worth stating plainly: the provision is aimed at systems that generate content in forms related to the patterns and characteristics of their training data. Text generation is an obvious example, but the statutory examples also include images, video, and audio. A product’s marketing category may be useful context, but it does not replace the functional definition.
The relationship between this definition and the developer definition is important. A public generative system is the object being made available; the developer is the actor whose role brings the documentation duty into view. The statute is not asking a reader to classify every AI technique in the abstract. It is asking whether a defined kind of system or service, produced or substantially modified by a defined kind of actor, is being made available under the stated conditions.
The trigger is a lifecycle, not a single training run
The statute defines “substantially modifies” or “substantial modification” as a new version, new release, or other update that materially changes functionality or performance. It expressly includes the results of retraining or fine-tuning. It also says that “train” includes testing, validating, or fine-tuning by the developer.
These definitions widen the relevant development vocabulary beyond initial pretraining. Pretraining is one familiar stage, but a developer may also test a system, validate it, fine-tune it, or retrain it. If a later version materially changes what the system does or how well it performs, the release may be a substantial modification even if the provider describes it as an update rather than a new model.
There is an important limit here. The fact that the statute includes testing, validation, and fine-tuning in “train” does not mean that every internal test or minor adjustment is automatically a new public trigger. Two questions must remain separate. First, what development activities fall within the definition of training? Second, did the resulting version, release, or update materially change functionality or performance and then become publicly available under the statutory conditions? The first question concerns the content of the documentation. The second concerns whether a new release event falls within the recurring duty.
xAI’s public document shows why this distinction is useful. In its description of Grok’s data recipe, xAI refers to pretraining, reinforcement learning through human feedback, verifiable rewards, and model grading, and supervised fine-tuning of specific capabilities. Those terms describe a development process with multiple stages. They do not, on their own, prove that each stage created a separate covered release or that every change was substantial. They do show why a reader should not assume that “training data” refers only to the first dataset assembled for pretraining.
The temporal relationship can be represented simply:
The diagram is a reasoning aid, not a substitute for applying facts. A covered candidate becomes relevant when the release-date condition and public-availability condition align. A material later change can send the system through another documentation checkpoint. A listed exclusion can remove a system from the duty, but only if the statutory conditions for that exclusion actually hold.
The exclusions are narrower than their labels
Section 3111 says that a developer is not required to post documentation regarding data used to train a generative-AI system or service in three situations. The first is a system whose sole purpose is to help ensure security and integrity, using the meaning supplied by the cross-referenced Civil Code definition. The second is a system whose sole purpose is operating aircraft in the national airspace. The third is a system developed for national-security, military, or defense purposes that is made available only to a federal entity.
The limiting words do most of the work. “Sole purpose” matters in the first two categories. A system that includes a security feature, serves security as one function among many, or is used by a security team is not described by that text as automatically exempt. Likewise, “developed for” and “made available only to a federal entity” narrow the third category. The provision does not say that any system used by a government customer, or any system related to defense, falls outside the duty.
This is a place where ordinary language can mislead. A reader may see “security,” “aircraft,” or “defense” and jump to a broad policy conclusion. The legal question is narrower: does the system fit the stated purpose and access conditions? The cited provisions do not provide enough facts to decide a hypothetical product merely from its industry or customer list.
The exclusions also illustrate why the scope test should come before the disclosure checklist. If a system is outside the cited duty, the twelve-category summary is not the right first question. If it is inside, the exclusion cannot be used as a general excuse for avoiding difficult disclosures about a mixed-purpose product. Scope is not a moral judgment about the system. It is a threshold question about the rule’s defined conditions.
A repeatable scope check
A reader evaluating a public AI service can begin with five factual questions:
- Who is the relevant developer? Identify the person or organization that designed, coded, produced, or substantially modified the public system or service.
- What is the object? Determine whether the object being offered is a generative-AI system or service under the functional definition, rather than relying only on its product name.
- When was it released? Check whether the system or service, or the relevant modification, was released on or after January 1, 2022.
- How is it made available? Ask whether it is publicly available to Californians for use and whether compensation changes the answer; the statute says the duty applies regardless of compensation.
- Does a listed exclusion fit exactly? Test the sole-purpose, aircraft, or federal-only national-security conditions without expanding them to neighboring cases.
This is not a substitute for legal advice about a particular deployment. It is a disciplined way to avoid two opposite mistakes. The first is overreach: assuming that every AI-related update anywhere in a company’s technology stack automatically creates the same public documentation duty. The second is underreach: treating a model’s initial training date or a product’s marketing label as enough to dismiss later public releases and material modifications.
The scope conclusion should also carry its uncertainty. If the release date is known but the California access arrangement is unclear, the answer is partly established, not fully settled. If a provider calls an update “minor” but it materially changes functionality or performance, the label does not settle the statutory question. If a system serves both security and non-security purposes, the word “security” alone does not satisfy the sole-purpose condition.
Once the scope is clear, the reader can turn to the content of the website documentation. The next issue is not a demand for every record in the training corpus. It is the more structured question of what a high-level summary must say about the data used in development.