California AB 2013 explained for companies that supply training data

What is California AB 2013?#

California AB 2013, often called the Generative AI Training Data Transparency Act, is a state law that requires developers of generative AI systems or services made available to Californians to post documentation about their training data on their websites. It is a transparency law: it does not ban any type of training data, and it does not require anyone to hand datasets over.

The law matters to companies that license records because a developer's public documentation is now a place where licensed datasets may be described. A support history, a set of engineering records or an archive of job tickets you license could be summarized on a page that customers, competitors and journalists can read.

The requirement is already in force. It reaches systems released before the law took effect as well as new ones, and documentation is due again before each new covered release or substantial modification. The statute text sets the exact dates and how far back it reaches, so read those provisions with counsel rather than relying on secondary summaries.

Who must comply, and which systems are covered?#

AB 2013 places its duty on the developer, which the law describes broadly as a person or entity that designs, codes, produces or substantially modifies a generative AI system or service for use by members of the public. A company that only licenses records to a developer is usually not a developer for this purpose and has nothing to post.

Two boundary points matter to suppliers. First, the law treats retraining or fine-tuning that materially changes a system as a substantial modification, so a buyer that fine-tunes a public system on your records may still have to post documentation. Second, the duty attaches to systems offered for public use; a model used only inside a buyer's business may fall outside it, though plans can change. The statute also exempts a few narrow categories, such as systems whose sole purpose is security and integrity.

The indirect effect on suppliers is real. To write an accurate summary, a developer needs facts that only you hold, so expect diligence questionnaires and cooperation duties in the license.

What do AB 2013 disclosures cover, and what could each reveal?#

AB 2013 disclosures cover a list of high-level topics about each dataset used in training, and nearly all of them can touch a supplier. The table paraphrases the topics as the statute describes them; counsel should check the exact wording before relying on it.

The supplier's risk is less about trade secrets leaking and more about identification. A narrow description, such as dispatch records from a regional HVAC contractor, can point to one company even without a name, and several topics combined can narrow it further.

What AB 2013 does not require developers to disclose#

AB 2013 does not require developers to disclose the commercial or record-level detail that suppliers usually worry about most. The documentation is a summary of datasets, and its topics stop well short of the deal itself.

Those limits are useful in negotiation. If a developer's draft says the law requires it to publish deal terms or customer details, it is asking for more than the statute's topics, and the license can confine any public statement to what the law actually requires.

• 1The datasets themselves: nothing in the summary requires publishing or sharing records.
• 2Prices, payment terms or other commercial terms; the topic is only whether data was purchased or licensed.
• 3Names of the individual customers, employees or other people who appear in the records.
• 4A supplier's consent before the developer posts; any consent right has to come from the contract.
• 5Any posting by a company that only licensed records and did not develop or modify the system.

How to draft the required-by-law exception#

A confidentiality clause in a data license does not override a developer's legal duty to disclose, so the drafting task is to narrow the required-by-law exception without blocking compliance. Most licenses allow disclosure required by law, and a developer's counsel may decide that the sources-or-owners topic calls for identifying you.

General counsel usually tighten that exception in three ways. Limit any disclosure to the minimum the law requires. Tie it to an approved description of the dataset agreed at signing. And make the developer responsible for the accuracy of its own documentation, with the supplier answering only for the facts it provided. A plain sentence often does the work: any statutory training data summary will describe the licensed records using the approved description, and will not identify the licensor by name unless the licensee's counsel concludes in writing that the law requires it.

Make the clause survive termination and cover later versions. Because documentation is due again for each substantial modification, a model retrained on your records long after delivery can bring the description back into view, and the license should still govern it then.

Facts to have ready when a developer asks#

The facts to have ready are the ones each AB 2013 disclosure topic asks about, kept for each licensed dataset, because a supplier that answers quickly has the most influence over what the developer writes. Vague answers invite a developer to fill gaps with its own assumptions, and those assumptions end up in a public document.

Keep a short factual sheet for each licensed dataset, organized by the disclosure topics, and have counsel review it once. The same sheet answers diligence questionnaires, supports the approved description and gives you a reference point if a published summary later misstates something.

• 1Sources or owners: the legal entity that holds the records and the originating systems, such as Zendesk and Jira for a software company.
• 2Volume: an approximate record count you are comfortable seeing published as a broad range.
• 3Types: record families included and excluded, in plain words.
• 4Personal information: which personal and confidential details preparation removed, and how results were checked.
• 5IP status: known third-party material that was carved out, such as attachments created by other companies.
• 6Collection period: the date range of the records and whether refreshes are planned.
• 7Deal type: licensed, not sold, with the company keeping ownership.

Illustrative: a consulting firm agrees how its records will be described#

Illustrative: a fictional operations consulting firm licenses its proposal library, project review notes and internal playbooks to a developer building a planning assistant that will be offered to the public. The developer's draft documentation schedule names the firm as a dataset owner, gives the exact date range of the records and says the data includes personal information.

The firm's general counsel works through the AB 2013 topics one by one. The parties agree to describe the source as project delivery records from a US management consulting firm, to give the collection period in whole years, and to state that client names and staff details were removed before delivery, so the personal information line reflects the prepared records rather than the raw archive. The developer confirms the data was licensed without stating terms, keeps a right to name the firm only if its counsel concludes in writing that the law requires it, and agrees to give advance notice in that case. The partners approve the license with the schedule attached.

How SourceX prepares suppliers for disclosure questions#

SourceX handles AB 2013 questions in the Rights and Approval steps of the SourceX five-step transaction. The provenance and privacy record in the SourceX Evidence Packet hold most of the facts a developer needs for its summary, such as where records came from, the period they cover and what preparation removed, so the developer starts from documented facts rather than assumptions.

The supplier approves every step, so the description of its records is settled alongside the license rather than discovered later on a developer's website.