Privacy and preparation
California AB 2013 training data disclosures: what buyers will ask suppliers to document
By SourceX Editorial · Reviewed by Noah Loul ·
Short answer
California AB 2013 requires developers of generative AI systems made publicly available to Californians to post documentation summarizing the data used to train them. Suppliers publish nothing themselves, but buyers will ask them for the facts behind that summary: where records came from, when they were collected, whether they hold personal information and how they were licensed.
Key takeaways
- AB 2013 places the disclosure duty on AI developers, and buyers pass the documentation work to suppliers through license terms.
- A supplier should be able to state source systems, collection periods, personal information status, intellectual property status and licensing basis for every package.
- Whether your company is named in a buyer's public summary is a contract question, so settle it before signing.
- One well-kept documentation set can answer AB 2013 requests and similar requests tied to the EU AI Act.
What does AB 2013 require of AI developers?#
AB 2013, California's training data transparency law for generative AI, requires developers of generative AI systems made publicly available to Californians, including developers that substantially modify a system, to post documentation on their websites describing the data used to train those systems. The documentation is a high-level summary, not a copy of the data, and the statute lists the topics it must address.
Those topics include matters such as the sources or owners of the datasets, the kinds of data points they contain and roughly how many, whether they include personal information or material protected by intellectual property rights, whether the data was purchased or licensed, when it was collected, and whether it was cleaned or otherwise processed. Some topics, such as when the developer first used each dataset, are facts only the developer holds. Read the full list, its exceptions and the law's current status with counsel; this summary is not a substitute.
The law speaks to developers, not suppliers. A company that licenses records to a developer does not post the summary, but it is often the only party that knows the facts the summary needs.
Why buyers pass the questions to suppliers#
Buyers pass AB 2013 questions to suppliers because a developer can only summarize what it can document. For licensed operational records, the source, the dates and the privacy status are facts held by the company that created the records.
Expect the requests in three places: a documentation schedule attached to the license, representations and warranties about provenance and personal information, and a duty to tell the buyer if a documented fact turns out to be wrong. Counsel should read the three together, since an inaccurate documentation answer can become a breach of warranty.
What buyers will ask you to document#
The documentation buyers request maps closely to the summary topics, and each topic points to a record a supplier should already keep.
Where a fact is uncertain, say so in writing rather than guessing. A date range marked as approximate, with the method used to find it, is better documentation than a precise date nobody can support.
| Summary topic | What the buyer will ask you | What to have ready |
|---|---|---|
| Source or owner | Which company and which systems produced the records? | Legal entity name, system names and a provenance note for acquired or migrated data |
| Types of data points | What kinds of records and fields are included? | Record families, field lists and a dataset card |
| Number of data points | Roughly how many records does the package contain? | Record counts per record family, given as ranges where volumes will change |
| Collection period | When were the records created, and will more follow? | Date ranges per system and a statement on future refreshes |
| Personal information | Does the package contain personal information after preparation? | Removal methods, review results and a deidentification statement if claimed |
| Intellectual property | Do records include copyrighted, trademarked or patented material, or third-party content? | Exclusions for client deliverables, customer code and third-party documents |
| Purchased or licensed | On what basis does the buyer hold the data? | The license agreement and its permitted-use terms |
| Cleaning and processing | What was removed, transformed or filtered, and why? | A preparation log listing each step and its purpose |
Will your company be named in a public summary?#
Whether your company is named depends on how the buyer chooses to describe its sources and on what the license allows. Some developers name dataset owners; others describe sources in general terms, such as licensed operational records from US businesses.
Treat naming as a negotiated point. A confidentiality clause can set how the buyer may describe you, require your approval of any public reference, or permit only a generic description. Agree on the wording before signing, because the buyer's publication duty will not wait for a later negotiation.
Contract clauses to negotiate around documentation#
Contract clauses turn AB 2013 documentation from a courtesy into an obligation, so read them as carefully as the price and term. Buyers draft these clauses for their own compliance, and suppliers can usually narrow them without blocking the deal.
The safest position is to warrant only what your records show. Phrases such as to the supplier's knowledge, after reasonable inquiry, and as described in the documentation schedule keep a warranty tied to the work you actually did.
| Clause | What a buyer may propose | What a supplier can ask for |
|---|---|---|
| Documentation schedule | Broad duty to provide any information the buyer needs for disclosures | A fixed list of items, delivered once per version |
| Accuracy warranty | Unqualified warranty that all documentation is complete and correct | Warranty limited to knowledge after reasonable inquiry |
| Update duty | Ongoing duty to correct documentation at any time | Duty to notify if the supplier learns a documented fact was wrong |
| Public description | Freedom to describe the source as the buyer sees fit | Approval right, or an agreed generic description |
| Indemnity | Supplier covers any claim tied to the buyer's disclosures | Indemnity limited to the supplier's own breach, with a cap |
How AB 2013 fits with other documentation requests#
AB 2013 is one of several documentation regimes buyers are preparing for, so a single documentation set saves repeated work. The EU AI Act also expects providers of general-purpose AI models to publish a summary of training content, and buyers selling in both markets ask suppliers for overlapping facts.
Industry standards point the same way. The Data & Trust Alliance's Data Provenance Standards organize dataset metadata into three groups, source, provenance and use, which line up with the facts these summaries draw on. Keeping your documentation in that shape makes it easy for any buyer to reuse. A practical set has five parts.
- A dataset card describing record families, fields, date ranges and preparation.
- A provenance note naming the legal entity, the systems and any migrations or acquisitions.
- A rights summary covering contracts, notices and exclusions.
- A privacy record describing removal methods and review results.
- A signed release authorization for each delivered version.
Illustrative: an engineering firm answers a documentation schedule#
Illustrative: a fictional civil engineering firm licenses RFI logs, submittal reviews and internal design review comments drawn from Procore, Bluebeam and its project archive. The buyer's draft license includes a documentation schedule built around its AB 2013 summary.
The firm's operations lead fills in system names and date ranges per system, noting that records from before an old platform migration are excluded. Counsel confirms that client drawings and stamped deliverables were carved out, so the intellectual property answer covers firm-authored commentary only. The preparation log lists name removal, address generalization and removal of client project names.
On naming, the firm agrees to be described as a US engineering firm, without its name. The schedule, the log and the release authorization become one file the firm can reuse with the next buyer.
How SourceX prepares supplier documentation#
SourceX builds supplier documentation into each transaction through the SourceX Evidence Packet: provenance, licensing rights, permitted use, the privacy record and release authorization. Those parts cover the facts buyers draw on for training data summaries.
The packet is assembled across the SourceX five-step transaction and approved by the supplier before Delivery, so the documentation a buyer receives reflects what the supplier actually reviewed and released.
Frequently asked questions
Does AB 2013 apply to the supplier directly?
The law's disclosure duty falls on developers of generative AI systems. Suppliers are usually affected through contracts that require documentation and accuracy warranties. Whether any obligation reaches a particular supplier depends on its role in the deal, so confirm with counsel.
Can a buyer publish details about our dataset without permission?
That depends on the license. Without a clear confidentiality clause, a buyer may describe its sources in its own words. Agree in the contract on how you may be described, whether you approve public references, and which details stay confidential.
What if we cannot reconstruct exact collection dates?
Give the best supportable range per system and explain how it was found, such as from the earliest exported record. Mark it approximate. Buyers generally prefer an honest range with a stated method over a precise date that cannot be backed up.
Does deidentified data still count as personal information for the summary?
If the data meets the deidentification definition in the laws that may apply, it is generally not personal information. Buyers will still ask how you reached that conclusion, so keep the removal methods and review results ready to share.
Should we prepare documentation before a buyer asks?
Yes, at least in outline. System names, date ranges, exclusions and a preparation plan help in any licensing conversation, and assembling them early exposes rights or privacy gaps while there is still time to address them.
Sources
- The Data & Trust Alliance's Data Provenance Standards define dataset metadata in three groups: Source, Provenance and Use, which the specification says is needed to enable proper dataset selection for AI model training. Source
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.