The Disclosure Is the Point: What AB 2013 Makes Visible
California AB 2013 is about a specific relationship: a developer makes a generative-AI system or service available to Californians, and the developer must make certain facts about the data used in development visible on its website. This opening asks what kind of visibility the law creates—not whether it makes a developer reveal an entire training corpus—and establishes a way to read the public statements that follow without turning them into stronger conclusions than they support.
The central idea is simple but easy to miss. AB 2013 is not principally a law about what an AI system says to a user. It is about what the developer says about the system’s development data. That shift—from output to origin, treatment, and timing—gives the public a different way to examine a technology that otherwise presents itself mainly through a chat window, an image, a voice, or an application interface.
The law starts with a visibility problem
A person using a generative-AI product can observe an answer, but usually cannot observe the development process that made the answer possible. The user may not know whether the underlying datasets came from public material, third-party or partner-provided material, users, contractors, or internally generated work. They may not know whether collection is still occurring, whether the developer processed the data before using it, or whether synthetic data entered later stages of development. Even a broad statement about “internet data” leaves several important questions open: who supplied it, how the developer characterizes its rights, what kinds of information it contains, and how its scale is being measured.
The chaptered text of AB 2013 responds by adding Title 15.2, called “Artificial Intelligence Training Data Transparency,” to the California Civil Code. Its subject is documentation about data used to train covered generative-AI systems or services. The operative design is therefore neither total secrecy nor total disclosure. It creates a public account of selected features of development data while leaving the underlying records, model weights, and many technical details outside the account described in the cited provisions.
That middle position matters. The cited provisions do not require the public to receive every underlying record. They require a high-level summary while separately asking whether the datasets include personal information or material protected by copyright, trademark, or patent. But a statement so vague that it says only “we used data” would tell the public almost nothing. AB 2013 addresses that gap by requiring a high-level summary and naming the kinds of questions the summary must address.
This is why the law should not be read as a demand for a single giant list. It is better understood as a transparency schema: a set of connected dimensions that make a development pipeline more legible. The public does not receive the whole object. The public receives a structured description of the object’s sources, purpose, scale, character, treatment, and history.
What the statute makes visible
Section 3111 says that the developer must post documentation on the developer’s internet website regarding the data used to train the covered system or service. The documentation must include, among other things, a high-level summary of the datasets used in development. The statute then supplies twelve content categories. They can be remembered more easily as a handful of related questions.
First: Where did the data come from? The summary must identify the sources or owners of the datasets. This is a provenance question. It does not necessarily demand a record-by-record inventory; it asks the developer to describe the origin or ownership of the material at the level of the required summary.
Second: Why was the data used? The developer must describe how the datasets further the intended purpose of the AI system or service. This is different from naming a source. “Publicly available data” describes a source class; it does not, by itself, explain why that class is relevant to a system intended to generate language, images, audio, or other content.
Third: How much data is involved, and what kind is it? The statute asks for the number of data points, while allowing general ranges and estimated figures for dynamic datasets. It also asks for the types of data points. For labeled datasets, that means the types of labels used; for datasets without labeling, it refers to general characteristics. The wording recognizes that a dataset can be described through different measurement and classification systems.
Fourth: What legal and informational conditions accompany the data? The summary must address whether datasets include material protected by copyright, trademark, or patent, or are entirely in the public domain. It must separately state whether datasets were purchased or licensed. It also must address personal information and aggregate consumer information. These are not decorative disclosures. They tell a reader which legal-status, acquisition, and privacy questions the developer itself has considered relevant.
Fifth: What happened to the data before or during development? The developer must describe cleaning, processing, or other modification and the purpose of those efforts in relation to the system or service. The statute also asks whether synthetic-data generation was used or is continuously used, with an optional description of its functional need or desired purpose. Because a developer may clean, process, or otherwise modify datasets, the processing account helps explain the transformation between source material and development material.
Sixth: When did the data enter the process? The summary must state the period during which the data was collected, including notice if collection is ongoing, and the dates the datasets were first used during development. These dates give the disclosure a lifecycle. They help distinguish a dataset’s history from the date a particular product became public.
Taken together, these categories create a public vocabulary for asking what a model developer reports about its data. They do not eliminate uncertainty. They make uncertainty more specific. Instead of asking vaguely whether an AI system is “transparent,” a reader can ask whether its source, purpose, scale, composition, rights, privacy, processing, synthetic-data use, and timing are described—and at what level of precision.
The relationship is more useful than the checklist
The statutory categories make the most sense when kept in relation to one another. Provenance without purpose can be a name list with no explanation. Scale without a unit can create false precision. A rights statement without an acquisition statement can blur legal status and commercial pathway. A privacy statement without a processing account can hide how the developer tried to reduce or manage sensitive information. A collection date without a first-use date can make the history of the data appear more definite than it is.
The relationship also runs through the actors. The developer is not merely a narrator standing outside the system. Under the statute’s definition, a developer can be an organization that designs, codes, produces, or substantially modifies an AI system or service for public use. The system or service is the public-facing object. The datasets are the development inputs whose origin and treatment are being described. The website documentation is the bridge between that private development process and public scrutiny.
A useful mental model is therefore:
This model also explains why the title question—what AB 2013 actually requires—cannot be answered by looking only at a provider’s marketing language. The legal relationship is between a developer, a covered system or service, a public availability event, and a website document. The content of that document matters only after the reader understands which object and which developer are being described.
What the public examples make concrete
OpenAI’s public summary shows the compact form this kind of account can take. OpenAI says its publicly available generative-AI systems in California are developed using publicly available data, data accessed through third-party partnerships, information provided or generated by users or human trainers and researchers, and synthetic data. It connects those sources to purposes such as helping systems understand human language and the world, enhancing creativity, and advancing scientific discovery and medical research. It also reports datasets containing trillions of tokens across textual, image, audio, and audiovisual content.
Those statements answer several of the statute’s questions at once, but only at a high level. They identify broad source classes, explain intended value, provide an order of magnitude, and name modalities. They do not present a record-level account of every dataset. That is not a contradiction. It is the difference between a summary and an inventory.
xAI’s document offers another form. Its data-disclosure section says that Grok’s pretraining recipe includes publicly available Internet data, data produced by third parties for xAI, data from users other than Grok 1 or from contractors, and internally generated data. It reports datasets and dynamic datasets containing trillions to tens of trillions of tokens. It also describes reinforcement learning through human feedback, verifiable rewards, and model grading, along with supervised fine-tuning of specific capabilities.
The two examples should not be treated as a provider ranking. “Trillions of tokens” and “trillions to tens of trillions of tokens” are not automatically comparable measurements of the same object. The documents do not establish a shared definition of data point, token, dynamic dataset, modality, or counting boundary. What they do provide is a concrete lesson in reading: preserve the provider’s unit, range, timeframe, and qualifier instead of converting them into a cleaner but unsupported comparison.
The examples also show why the law’s central value is intelligibility. A reader can begin to ask better questions when a provider identifies source classes, intended purposes, scale, modalities, processing stages, or ongoing collection. That is meaningful progress from silence. It is not the same thing as independent verification.
Visibility is not proof
The most important boundary is the one between a disclosure and an assurance. A provider’s statement supports the proposition that the provider reports a particular practice or characterization. It does not, by itself, prove that every dataset has been identified, that every rights claim would prevail in court, that privacy controls eliminate all risk, or that the resulting model is safe, fair, accurate, or effective.
The xAI document makes this distinction especially visible because it places its AB 2013 data disclosure after a separate Frontier Artificial Intelligence Framework. Earlier portions of that document discuss malicious use, loss of control, benchmarks, safeguards, thresholds, information security, governance, and deployment decisions. Those are safety and risk-management questions. The later data-disclosure section addresses training sources, rights, privacy, processing, dates, and synthetic data. The subjects may interact, but one form of transparency does not substitute for the other.
A careful reader can therefore hold two ideas at once. AB 2013 makes development data more publicly legible, and the law does not turn a developer’s summary into a complete audit. The practical judgment this series supports begins with that balance. Before asking whether a disclosure covers every category, first ask whether the release is within the statutory scope. Once that scope is clear, read the summary as a structured set of claims, preserving its units and qualifiers. Then separate what the document reports from what would require a different legal, privacy, safety, quality, or performance review.
That is the point of the disclosure: not to make uncertainty disappear, but to give the public a more disciplined way to see where the uncertainty begins.