California AB 2013 Training Data Disclosure

California Civil Code §3111, enacted as AB 2013, requires the developer of a generative AI system or service made publicly available to Californians to post documentation about the data used to train it. The first deadline was January 1, 2026, and the duty repeats before each later release or substantial modification. It reaches back to systems released on or after January 1, 2022.

The law has been challenged. xAI sued the Attorney General in December 2025, a federal district court denied its motion for a preliminary injunction on March 4, 2026, and xAI appealed to the Ninth Circuit. The statute remains in effect while the appeal proceeds. It contains no penalty provision of its own, and in the litigation the Attorney General's office declined to say whether or when it would bring enforcement actions.

This article describes what the statute asks for and how to build the documentation so it can be produced, checked and updated on every release. Whether and how it applies to a particular system is a question for counsel.

Who counts as a developer

The definitions in §3110 are wider than "AI lab":

A developer is 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. Members of the public, for this purpose, excludes affiliates and a hospital's medical staff.
A substantial modification is a new version, release or update that materially changes functionality or performance, expressly including the results of retraining or fine-tuning.
To train a system includes testing, validating and fine-tuning it.

Read together, these reach organizations that never pretrain a model. A regional insurer that fine-tunes an open-weights model and offers a claim-status assistant on its public website fits the pattern the definitions describe, and each materially different fine-tune it releases would be a new trigger. A tool used only by employees raises a different question about "members of the public." The statute exempts three narrow categories: systems whose sole purpose is security and integrity, systems whose sole purpose is operating aircraft in national airspace, and national security, military or defense systems available only to a federal entity.

The twelve items, mapped to evidence

Section 3111(a) asks for a high-level summary of the datasets covering 12 items. Each one should trace to a field in your internal manifest, and each field to a system that produced it.

§3111(a) item	Manifest field	Evidence behind it
1. Sources or owners	`sources[].owner`	Data inventory, contracts
2. How the data furthers the system's purpose	`sources[].purpose`	Use-case specification
3. Number of data points (ranges allowed)	`counts.range`	Pipeline counters
4. Types of data points or labels	`record_types`, `label_schema`	Annotation guidelines
5. Copyright, trademark or patent, or public domain	`rights.ip_status`	License register
6. Purchased or licensed	`rights.acquisition`	Procurement records
7. Personal information (§1798.140(v))	`privacy.personal_information`	PII scan results
8. Aggregate consumer information (§1798.140(b))	`privacy.aggregate_consumer_info`	Data owner attestation
9. Cleaning, processing or modification, and its purpose	`transformations[]`	Pipeline run logs
10. Collection period, with notice if ongoing	`collection.period`, `collection.ongoing`	Source system metadata
11. Dates first used in development	`first_used`	Training run registry
12. Synthetic data generation used	`synthetic.used`, `synthetic.purpose`	Generation logs

Two documents, one source of truth

Keep two artifacts and generate one from the other. The internal manifest is record-level and confidential: content hashes, license contracts, reviewer IDs, per-batch counts and the deletion log. The public page is the statute's high-level summary. If the page is rendered from the manifest by a template, every public sentence traces back to a field, and the two can't drift apart.

Counts are the clearest example. The statute allows general ranges and estimated figures for dynamic datasets. Choose your bands in advance (under 10,000; 10,000 to 100,000; 100,000 to 1 million; and so on) so they stay stable from release to release and disclose no more than you decided to.

How much detail a summary needs is not settled. xAI posted what it called a high-level, limited disclosure the day after filing suit and argued that more would expose trade secrets; the district court's order addressed whether to halt the law, not where the line sits. Build the manifest at full detail internally, and decide the public level of abstraction once, deliberately, with counsel.

A manifest that speaks a standard

There's no need to invent a schema. MLCommons Croissant is a JSON-LD vocabulary for machine learning datasets built on schema.org, and its Responsible AI extension adds properties that line up with several of the statute's items: rai:dataCollection, rai:dataCollectionTimeframe, rai:dataPreprocessingProtocol, rai:dataAnnotationProtocol and rai:personalSensitiveInformation. An illustrative entry, in YAML for readability:

dataset_id: claims-notes-2022-2025
documents_release: claim-status-assistant-v3.2
sources:
  - name: Adjuster notes from the claims platform
    owner: first-party
    purpose: Teach the assistant claim-status vocabulary and next-step logic
    rights: { ip_status: copyrighted_first_party, acquisition: none }
    collection: { period: "2022-01 to 2025-12", ongoing: true }
    counts: { unit: notes, range: "1M-10M" }
  - name: Vendor repair-estimate guides
    owner: licensed third party
    purpose: Ground answers about repair timelines
    rights: { ip_status: copyrighted_third_party, acquisition: licensed, license_ref: LIC-0042 }
    counts: { unit: pages, range: "10K-100K" }
privacy:
  personal_information: true        # before redaction; see transformations
  aggregate_consumer_info: false
transformations:
  - { step: exact_and_near_dedup, purpose: "remove copied-forward notes" }
  - { step: pii_redaction, purpose: "remove claimant identifiers", recall_measured: 0.996 }
  - { step: quality_filter, purpose: "drop notes under 20 words" }
synthetic: { used: true, purpose: "fill rare claim types", share_of_training_records: "under 10%" }
first_used: 2026-03-02
croissant_rai:
  rai:dataCollectionTimeframe: "2022-01/2025-12"
  rai:personalSensitiveInformation: "Claimant names, policy numbers, addresses; redacted before training"

The same file can feed a Croissant export for internal catalogs and, if you also place models on the EU market, much of the European Commission's template for public training-content summaries.

The fields that take judgment

Item 5, intellectual property. Nearly all business text belongs to someone: your employees' notes, a vendor's manual, a customer's email. "Entirely in the public domain" is rarely accurate for enterprise data. Record the status per source rather than per dataset.

Item 7, personal information. The statute points to the California Consumer Privacy Act definition, not HIPAA's. Answer from a scan of the actual data, and record which definition the answer applies, because a set de-identified under one regime may still contain personal information under another.

Items 9 to 11, history. Cleaning steps need their purpose, collection needs dates and an "ongoing" flag, and first use needs a date from a training run registry. These are easy to log as you go and nearly impossible to reconstruct a year later.

Item 12, synthetic data. The question is whether the system used or continuously uses synthetic data generation. If every generated record carries lineage tags, as in our synthetic data checklist, this is a query, not an investigation.

Base models. A fine-tuner knows its own fine-tuning, validation and test data in detail and the base model's pretraining data only through its provider. Record the base model, its version and the provider's published documentation next to your own entries, and ask counsel how the two fit together.

Make the release process enforce it

The statute ties disclosure to each release, so tie the page to the release pipeline:

The model card, the manifest and the public page share a version number.
A deployment check fails if the manifest changed since the page was last rendered.
The page shows its version and date, and previous versions are archived rather than overwritten.
A named owner signs off on items 5, 7 and 12 for each release, because those answers take judgment.

Our data provenance and compliance work builds this manifest as a by-product of preparing the data, and every Benner House delivery already ships with one. You can see the shape of it in our sample datasheet.

Checklist

Map every publicly available generative system, and every fine-tuned release of one, to an owner and a release date.
Confirm with counsel which systems the definitions reach, including fine-tunes and anything released on or after January 1, 2022.
Build the internal manifest at record level; render the public page from it.
Fix count ranges in advance and keep them stable across releases.
Record IP status, acquisition and personal-information answers per source, with the definition used.
Log cleaning steps with their purpose, collection periods, and first-use dates as they happen.
Tag synthetic records at generation time.
Version the page with the model and block releases when they diverge.

California AB 2013: a training-data provenance manifest you can publish