California AI Laws: How to Meet AB 2013’s January 1, 2026 Training Data Disclosure Mandate

This guide maps AB 2013's requirements to a versioned, URL-published training-data disclosure page.

It focuses on the exact elements developers must cover for GenAI systems released to Californians on or after January 1, 2026.

What AB 2013 Actually Requires

At its most direct level, AB 2013 is a statutory change, not a set of industry guidelines. According to the Stanford Tech Review, AB 2013 adds Title 15.2 to the California Civil Code, establishing the framework for public disclosures about training data for generative AI. This codification is the mechanism that creates the obligation in the first place, and it is set to take effect on January 1, 2026, as reported by PYMNTS (Sept. 24, 2025).

With that effective date in place, the mandate applies to developers of generative AI models who release their systems to Californians on or after January 1, 2026. The requirement is to publicly disclose what data is used to train those systems, but the press coverage alone does not list every element that must be shown. For that reason, the statute itself must be treated as the source of truth, rather than any secondary summary of it.

Before assuming compliance, the necessary check is to pull the current text of Civil Code Title 15.2 directly from leginfo.legislature.ca.gov. From there, each required disclosure element must be mapped against the actual training pipeline, with specific attention to datasets or categories, source types, collection periods, and whether personal data is involved. This mapping must be done against the exact text in effect at the time of review, as codifications can shift before the effective date.

Finally, it is worth noting that the obligation is tied to the act of release to Californians, not to internal development alone. Because of that trigger, the question is not if Title 15.2 exists, but whether a system's release window falls on or after January 1, 2026. Only by verifying against the live statute can a developer know exactly what must be disclosed under this framework.

The Evidence: Who Is Covered, When

The trigger for coverage is not where a developer is incorporated, but where the system is released. For any generative AI system made available to Californians, the determining factor is audience reach. Instead of looking to company location, check your product's terms of service for a statement of served jurisdictions. If California is listed, or if the access path makes it reasonably available to Californians, treat that release as covered. This is a jurisdictional check, not a model-size check, and it should be made at the point of release planning.

The clearest enforcement-adjacent signal comes from litigation. According to Law360, xAI failed in its attempt to block California's disclosure law in court. This is the only verified court outcome in the provided grounding that directly addresses an attempt to halt the law itself. While no ruling can guarantee the future of every challenge, this failed attempt is the strongest available signal that constitutional preemption arguments will not remove the obligation before it takes hold. Treat it as a timing signal, not a blanket immunity from all future litigation.

That timing signal carries weight because the trigger is active, not passive. A system with a narrow use case can still meet coverage if it is openly accessible to Californians through a public interface. On the other hand, a deliberate geo-restriction that fully blocks California access would change that determination. The key is the actual availability path, not intent alone. If your terms of service are silent on California, do not assume exclusion. Instead, verify the real sign-up or access route used for Californians and record that verification for your release decision.

With the court path narrowed by the reported outcome, the most common mistake is looking inward. Teams often audit their corporate structure first, when the obligation looks outward to user reach. By locking in a jurisdictional check now, you can separate the question of "who we are" from the question of "who we serve". That distinction is the difference between guessing coverage, and knowing it based off of verifiable access.

Three Compliance Paths Compared

When weighing build effort against the public nature of this obligation, the question to test is not whether information can be produced once, but whether it can be produced for the exact model version released. With that test in mind, three approaches can be compared directly against the need for a public disclosure.

Path A, a static PDF whitepaper, is often the first idea considered. While it can present a broad overview, it breaks on every model version bump and cannot be regenerated on demand. For a system that changes over time, a frozen file leaves no reliable way to point to the training-data scope for a specific release, creating a versioning gap that cannot be patched by simply adding a new cover page.

Path C, per-request API disclosures, runs in the opposite direction. Because the requirement calls for a public disclosure, not a contractual one, gating the information behind a request is a structural mismatch. Even if counsel is brought in to draft marketing copy for those responses, the access model itself does not meet the public test. On top of that, a request queue makes it difficult to prove what was disclosed at the time of a given release, pushing cost and friction to their highest point for the least defensible fit.

Path B, a versioned public documentation page, is the only one that matches the public requirement. By listing datasets or categories, source types, time ranges, and flags for personal data and copyright, and by tying each set of entries to a model version with a stable URL, the page can be updated without reissuing a one-off file. This structure makes it regenerable, auditable, and directly accessible without a gate. For these reasons, the explicit comparison points to Path B as the winner.

Before committing to any path, run one concrete check: take your next planned model version bump and see if you can publish its disclosure to a public URL within the same release window. If that action requires rebuilding a frozen document or opening a ticket queue, the path fails the public test.

Costs and Numbers That Matter

The only framing to weigh here is the cost-of-being-wrong: reconstruction cost versus documentation-as-you-go cost. For planning purposes only, budget the audit as (number of training datasets) × (hours to trace provenance per dataset) × (blended data-engineering rate). As a method example, a 30-dataset inventory at 4 hours each is roughly 120 hours of data-engineering time. This is strictly planning arithmetic, not a statutory cost, and your own blended rate will shift that total. The point is not the exact number, but the formula you can apply to your own inventory.

The real asymmetry is scale of effort. Documenting each dataset at ingestion is hours, because the questions of source type, dataset boundaries, and collection period can be answered at the moment of acquisition or curation. By contrast, reconstructing provenance for data collected years ago under no documentation regime is weeks. This is not a matter of writing a page, but of rebuilding a paper trail from storage locations, transfer logs, license records, and any surviving notes. The longer that trail has gone unlogged, the more of those records will be missing entirely.

Before locking into any timeline, run a direct capacity check: pick three of your oldest training datasets and see how many distinct people and systems are needed to answer, without a brand new investigation, where each one came from and its collection period. If the answer requires pulling from multiple teams or archived systems, treat that as a multiplier for every dataset in that same age bracket. The available sources does not provide a universal dollar amount for this work, so do not substitute one. Instead, use that multiplier against your own inventory to see how fast reconstruction grows.

Ultimately, the cost is not the act of publishing a URL, but the state of your evidence. Every dataset you cannot trace today is one that will pull more hours into reconstruction later, while every dataset you log at ingestion keeps that effort to hours. That is the cost-of-being-wrong, and it is the only cost factor this section introduces. Treat it as a capacity constraint first, and a budget constraint second, based off of your own records.

What the Evidence Does Not Establish

For all of the attention placed on California Civil Code Title 15.2, there are specific blanks that the public record does not fill. The only new item to lock in here is the explicit gaps table below, because treating ungrounded commentary as settled fact is one of the easiest ways to misstate compliance. Each of these gaps must be treated as a verification task, not an assumption.

To begin, there is no grounded figure for penalty amounts or enforcement posture in the provided sources. While the Stanford Tech Review describes the framework for public disclosures, it does not publish any stated fees or stated enforcement actions. For that reason, do not repeat blog-quoted dollar figures. Instead, check the current enacted text of Title 15.2 and the California Privacy Protection Agency's site for any stated enforcement authority or stated amounts at the time of review.

Next, the available sources offers no explicit guidance on granularity or scope. It does not state whether the law expects named datasets versus broader categories, or how to draw any line between fine-tuning and pretraining. These are not implied by the framework alone. To avoid inferring a split, verify against the enacted Title 15.2 text and the legislative history on leginfo, not secondary summaries, as those are the only places where an operative distinction would appear.

Finally, the open-weight release edge case has no explicit answer from the listed sources. It is not clear when the rule breaks versus when it may still apply to a release made available to Californians. Treat this strictly as a boundary check: read the operative language for any conditions or carveouts in the enacted text, and do not assume a blanket exemption based on release format.

Until each of these items is checked against primary sources, any concrete number or bright-line rule attached to them should be treated as ungrounded, regardless of how often it appears in commentary.

And Disclosure Template

To put documentation into practice, work through a concrete example using a customer-support LLM. For this model, the training set can be broken into three datasets: (1) web-scraped text collected from 2019–2023, (2) a licensed news corpus collected from 2020–2024, and (3) customer chat logs collected from 2021–2025. The first checkpoint for each of these is to confirm the collection period per dataset against ingestion timestamps, not just the stated range. If the actual ingestion timestamps do not match the stated range, the published time range must be corrected to reflect what was used before going public.

The second checkpoint is personal data presence. For dataset (3), customer chat logs, the working assumption must be that personal data was present, so it must be explicitly flagged. For dataset (1), web-scraped text, there is no way to confirm presence from the range alone, so it must be flagged as unknown and require a sampling check. Dataset (2), the licensed news corpus, still requires this check against its terms, as a license does not automatically rule out personal data.

The third checkpoint is copyright status. Dataset (2) can be noted as licensed, but only if the license scope is tracked and verifiable. Datasets (1) and (3) cannot be assumed cleared by their collection method, so both must be flagged for copyright status review. These three checkpoints must be applied per dataset, with flags used in place of assumptions until verification exists.

With those checks in mind, the disclosure table below shows the minimum structure to complete for each dataset or category. Do not collapse multiple datasets into one line, and do not replace "unknown" with "no". Every entry must be filled with verifiable information, or an explicit flag.

The rule for this disclosure is simple: a flag is a valid answer until verification exists. If any cell cannot be completed with verifiable information, it must remain flagged on the public page, with the review noted, rather than being omitted or guessed.

Worked Example: Run the Numbers

This section works one concrete numeric example end to end. For this illustration, the inputs are as follows: scenario = release of "BetaText" (a text generative AI system) to Californians; planned release date = March 1, 2026; party = Orion Labs, a two-person documentation team. To keep this example fixed, the inventory scope is limited to 3 datasets, with 2 source types per dataset, and 1 collection period per (dataset, source type) pair. By multiplication, that equals 6 required entries that must be represented on a public disclosure page.

As illustration 1 (intake logging), Orion Labs logs each of those 6 entries at the moment each one is added to training selection. For each entry, the action is to assign a version tag and place it on the same public URL. The action count for this illustration is 6 tagging actions. The required check for this illustration is that all 6 tags must remain tied to the same URL version, with no entry left untagged.

As illustration 2 (reconstruction), Orion Labs does not log at intake and instead compiles the same 6 entries at prep for March 1, 2026 by re-checking selection logs. The action count for this illustration is 6 re-check actions. However, the required check for this illustration is different: for each of those 6 entries, the team must confirm the exact selection log exists before it can be listed. Since both illustrations start at 6 actions, the arithmetic is equal on count alone, but the dependency is log existence rather than creation-time tagging.

For this example, the winner is illustration 1 (intake logging), because it produces all 6 entries with version tags at creation without making the listing dependent on finding every log later. The break-even trigger for this example is strictly count-based: the moment the number of entries with missing selection logs becomes greater than or equal to 1 out of those 6, illustration 2 requires at least one extra verification action beyond its 6 re-check actions, while illustration 1 does not gain that extra action from the same missing-log condition. This trigger is the only numeric result declared by this section.

Decision Rules Before January 1, 2026

With a release to Californians on or after January 1, 2026, the decision is not whether to publish, but when to lock the public training-data disclosure page. The gate is strict: if you release a GenAI model to California users after Jan 1, 2026, then publish the disclosure page at or before release — never after. Treating that page as a post-launch patch is not a timing choice, but a failure to treat it as a release artifact.

To make that gate enforceable, the operational rule set must include an audit-cadence rule: assign every dataset intended for the page to a trace slot and run a provenance check against it on a fixed audit pass before build freeze. From that cadence comes the fallback: if you cannot reconstruct a dataset's provenance within two audit-days, then disclose it at category level with 'period unknown' flagged rather than omitting it. The flag is the action, not an excuse to leave the dataset unaccounted for.

Not all datasets demand the same review path. For clarity in this pre-freeze check, use the customer chat logs dataset in the worked example only as the marker: if a dataset contains customer or employee text, then run a personal-data flag review with counsel before the disclosure page ships. This is not a call to expand to every dataset here, but to force a legal check at the exact point where the page would otherwise go live with that class present.

These three if/then moves must be applied in order. The page must be versioned at the moment of first publication, and the URL must be fixed at or before release with the results of those gates attached to it. A missing trace cannot be traded for silence, and a sensitive class cannot be traded for speed.

Before January 1, 2026, the only checklist question that matters is whether all three gates can be passed at freeze. If any gate cannot be passed, the prescribed action is the fallback for that gate, not moving the publication point past release. That is the only way to keep the disclosure page defensible without changing the publication point itself.

What to do next

Frequently Asked Questions

Is AB 2013 a set of industry guidelines or a law?

AB 2013 is a statutory change, not a set of industry guidelines.

Which part of the California Civil Code does AB 2013 add?

According to the Stanford Tech Review, AB 2013 adds Title 15.2 to the California Civil Code.

When is AB 2013 set to take effect?

AB 2013 is set to take effect on January 1, 2026, as reported by PYMNTS (Sept. 24, 2025).

Which developers are subject to this disclosure mandate?

The mandate applies to developers of generative AI models who release their systems to Californians on or after January 1, 2026.

Can a developer rely solely on press coverage to know every required disclosure?

The press coverage alone does not list every element that must be shown, so the statute itself must be treated as the source of truth.

Where must the exact text of AB 2013's requirements be pulled from?

The necessary check is to pull the current text of Civil Code Title 15.2 directly from leginfo.legislature.ca.gov.

Quick answers

Also worth reading: OFCCP 2026 Voluntary Disclosure: 120-Day Trap & 38% Discount: OFCCP 2026 Voluntary Disclosure: 120-Day · 7 Legal Safeguards for Protecting Your AI-Related Intellectual Property Through Non-Disclosure Agreements: 7 Legal Safeguards for Protecting · The Current State of AI in Consumer Disclosure Review: Current State of AI in