AI Regulation Tracker  /  Effective-date activation

California's AI Training-Data Transparency Duty Is Now Live

As of January 1, 2026, California Assembly Bill 2013 is in force. A developer that makes a generative AI system available to Californians must now publicly post documentation about the data used to train it, across 12 required categories. The law was signed in 2024. The obligation is live today, and it is enforced by the state Attorney General.

By Anthony Guerriero  ·  The Leveraged Years Regulatory Research  ·  Published July 16, 2026  ·  Last updated July 16, 2026

The headline is the date. As of January 1, 2026, California's training-data transparency law is no longer a future obligation on a calendar. It is a duty that applies right now to developers whose generative AI systems reach people in California. The bill was signed into law back in 2024, so nothing about the requirement itself is a surprise. What changed at the start of this year is that the runway ended and the obligation went live.

What the law requires

AB 2013 sits in the California Business and Professions Code at section 3111. It applies to a developer that makes a generative AI system or service available to Californians. Once the law applies to you, it asks for one core thing: you have to publicly post, on your website, documentation about the data you used to train that system.

That documentation is not a vague summary. The statute spells out a set of 12 categories the disclosure has to cover. In plain terms, a developer has to describe the sources or owners of the datasets used, whether the developer purchased or licensed the data, and whether the datasets include any information protected by copyright, trademark, or patent, or whether they are in the public domain. The developer has to say whether the datasets include personal information and whether they include aggregate consumer information, as those terms are defined under California privacy law. It has to describe how the datasets further the intended purpose of the system, the number of data points involved in general terms, the time period during which the data was collected, and whether the collection continued through the system's development. It also has to disclose whether the datasets were cleaned, processed, or modified, and whether the developer used any synthetic data generation in developing the system.

Read those 12 categories together and the point is clear. The law wants a public, structured account of what went into the model. It is a transparency and documentation duty, aimed at the training data, and it is meant to be readable by the people and businesses on the other side of these systems.

What it is, and what it is not

I want to be careful here, because a law about training data is easy to overstate.

AB 2013 is a disclosure duty. It requires a developer to document and publish information about its training data. That is the whole shape of it. It does not ban any model. It does not stop a developer from training on a particular kind of data. It does not restrict what a system is allowed to output. It does not tell a developer to remove copyrighted material or personal information from its training set. It tells the developer to disclose, in the required categories, what the training data was.

So if you hear this framed as California outlawing a class of AI, or as a content restriction on what these systems can say, that is not what the statute does. The obligation is to post documentation. The teeth are in the requirement to be transparent, not in any prohibition on the underlying data or the model's behavior.

There are limits and carve-outs written into the law as well, including exceptions tied to certain systems whose sole purpose is security or the operation of aircraft, and the duty is framed around systems released on or after January 1, 2022. The practical reality for the big consumer and enterprise models most professionals actually use is that they are squarely inside the scope.

How it is enforced

Enforcement runs through the California Attorney General. AB 2013 does not create a private right of action that lets individual users sue. It is a public-enforcement statute, which means the state, through the Attorney General, is the party positioned to pursue a developer that does not post the required documentation or that posts documentation that does not meet the standard the law sets.

That matters for how seriously to take it. A disclosure duty that no one enforces is a suggestion. A disclosure duty backed by the state's chief law officer is a compliance obligation. For a national developer, the exposure is not theoretical, because serving California users is not optional for most of them.

Why this reaches beyond California

This is a California law, but its practical footprint is national. The trigger is making a generative AI system or service available to Californians. The major model developers all serve California. California is one of the largest markets in the country, and no serious general-purpose AI product carves it out. So a developer that wants to keep serving California users has to meet the disclosure duty, and the cheapest way to meet a public-posting requirement is usually to post one set of documentation for everyone rather than build a California-only version.

The result is that AB 2013 now operates as a de facto national training-data transparency baseline. A developer complying for California is, in effect, publishing training-data documentation the rest of the country can read too. If you are a US finance leader, a CPA, or anyone trying to evaluate an AI vendor, this is the practical upshot worth holding onto: as of the start of 2026, the large developers serving the US market have a live legal reason to publish structured documentation about what their systems were trained on.

What this means for you

If you build or ship a generative AI system that reaches California users, the action item is direct. The compliance date has passed. You need public training-data documentation on your site that covers the 12 required categories, and you need it now, not on a future roadmap. If you have not posted it, you are out of step with a duty that is already in force and that the Attorney General can enforce.

If you are on the buying and using side, which is most professionals, the value is different but real. You now have a legal basis to expect this documentation to exist for the major systems you rely on. When you are doing diligence on an AI vendor, you can look for the AB 2013 training-data disclosure and read it. It tells you, in the developer's own words, where the training data came from, whether it included copyrighted or personal information, and how it was assembled. That is exactly the kind of provenance information that governance, risk, and audit conversations have been asking for, and the law now pushes it into public view.

Either way, do not overread it. The disclosure tells you what a developer says went into a model. It is not a certification that the data was clean, licensed, or free of problems. It is a window, not a warranty. Use it as one input into your own governance, alongside your contracts, your own testing, and advice from qualified professionals.

Browse the full AI Regulation News tracker

Informational analysis for working professionals, not legal advice. Confirm how any statute or requirement applies to your situation with qualified professionals in the relevant jurisdiction.