Know what is on your site before a plaintiff’s firm does.Free website scanScan Your Site
Log in Sign up Book a demo
Home› Editorial› SB 53 and the TDTA: California’s Two AI…
AI

SB 53 and the TDTA: California’s Two AI Transparency Laws Ask Very Different Questions

California now has two AI transparency laws on the books that are often mentioned in the same breath and almost never apply to the same companies in the same way.

Oct 30, 2026 10 min read

Know what’s on your site before a plaintiff’s firm does

A free privacy audit shows which cookies, pixels and trackers are running — and which ones commonly appear in privacy claims.

Get My Free Audit

California now has two AI transparency laws on the books that are often mentioned in the same breath and almost never apply to the same companies in the same way. The Transparency in Frontier Artificial Intelligence Act, enacted as Senate Bill 53, governs a handful of developers training the largest models. The Generative Artificial Intelligence Training Data Transparency Act, enacted as Assembly Bill 2013 and often shortened to the TDTA, reaches a far wider group, including many businesses that would never describe themselves as AI developers. Both took effect on January 1, 2026.

The simplest way to tell them apart is to look at what each law wants published. SB 53 wants a small set of companies to document how they keep their most powerful models from causing a disaster. The TDTA wants a large and loosely defined group to document the ingredients of their models. The first is a risk-management law; the second is a provenance law. For compliance teams, the practical work is figuring out which questions your organization has to answer, and the TDTA is the one more likely to catch companies by surprise.

SB 53: a narrow law about catastrophic risk

SB 53 was signed by Gov. Gavin Newsom in 2025 and added Chapter 25.1 to the Business and Professions Code. Its coverage turns on two thresholds, both defined in the statute’s text.

  • A frontier model is a foundation model trained using more than 10^26 integer or floating-point operations, counting the original training run plus later fine-tuning, reinforcement learning and other material modifications.
  • A frontier developer is anyone who has trained, or started training, such a model.
  • A large frontier developer is a frontier developer that, together with its affiliates, had more than $500 million in annual gross revenue in the preceding calendar year.

Large frontier developers carry the heaviest duties. They must write, implement, follow and publish a “frontier AI framework” describing how they assess and mitigate catastrophic risk. The framework must cover, among other things, capability thresholds, mitigations, third-party assessments, cybersecurity for unreleased model weights, incident response, internal governance and the risks of internal use, including a model circumventing oversight. It must be reviewed at least once a year, and any material change must be published with a justification within 30 days.

All frontier developers, large or not, must publish a transparency report before or at the time they deploy a new or substantially modified frontier model. The basic report lists the developer’s website, a contact mechanism, release date, supported languages and output modalities, intended uses and general use restrictions. Large developers add summaries of their catastrophic-risk assessments, the results, the role of third-party evaluators and other steps taken under their framework. The law lets this information live in a system card or model card.

The statute defines catastrophic risk tightly: a foreseeable and material risk that a frontier model materially contributes to death or serious injury of more than 50 people, or more than $1 billion in property damage, in a single incident involving expert-level help with chemical, biological, radiological or nuclear weapons, a cyberattack or serious crime carried out without meaningful human oversight, or a model evading its developer’s control.

Frontier developers must report critical safety incidents to the California Office of Emergency Services within 15 days of discovery, or within 24 hours to an appropriate authority if there is an imminent risk of death or serious physical injury. Large developers must also send OES summaries of internal-use risk assessments every three months or on another reasonable schedule they set in writing. Penalties for large frontier developers reach up to $1 million per violation and can be recovered only by the attorney general. The law also cross-references new whistleblower protections for covered employees in the Labor Code.

For most organizations, SB 53 is something to understand rather than something to comply with. Its value to a buyer of AI is that covered developers must publish documents a procurement team can read. Our guide to state AI laws places both in the wider landscape.

The TDTA: a broad law about training data

The TDTA, codified at Civil Code sections 3110 and 3111, works very differently. It applies to any developer of a generative AI system or service made publicly available to Californians, whether or not users pay. The statute defines developer to include anyone who “designs, codes, produces, or substantially modifies” an AI system or service for public use, and it defines substantial modification to include “the results of retraining or fine tuning.” Training itself includes testing, validating and fine-tuning.

There is no revenue threshold and no compute threshold. The law reaches back to systems released on or after January 1, 2022, and requires documentation before each new release or substantial modification after that. A company that fine-tuned an open-weight model on its support tickets and put the resulting chatbot on its public website may be a developer under this definition. Whether a given product crosses the line depends on facts, and the statute has no official guidance yet, but the breadth is the point.

Covered developers must post documentation on their website that includes a high-level summary of the training datasets. The statute lists twelve items:

  1. The sources or owners of the datasets.
  2. How the datasets further the system’s intended purpose.
  3. The number of data points, which may be given in ranges, with estimates for dynamic datasets.
  4. The types of data points, meaning label types for labeled data or general characteristics otherwise.
  5. Whether the datasets include material protected by copyright, trademark or patent, or are entirely public domain.
  6. Whether the datasets were purchased or licensed.
  7. Whether they include personal information as defined in the CCPA.
  8. Whether they include aggregate consumer information as defined in the CCPA.
  9. Any cleaning, processing or other modification, and its purpose.
  10. The time period in which the data was collected, with notice if collection is ongoing.
  11. The dates the datasets were first used in development.
  12. Whether the system used or continuously uses synthetic data generation.

Three exemptions exist: systems whose sole purpose is security and integrity, systems whose sole purpose is operating aircraft in the national airspace, and national security, military or defense systems made available only to a federal entity. The TDTA does not contain its own penalty section. Our earlier news coverage called it AI’s nutritional label moment, and the comparison holds: it requires a disclosure, not a particular recipe.

The two laws side by side

SB 53 (frontier AI) AB 2013 (TDTA)
Who is covered Developers training models above 10^26 operations; heavier duties above $500M revenue Any developer, including fine-tuners, of public generative AI available to Californians
Core question How do you manage catastrophic risk? What data did you train on?
Main document Frontier AI framework and transparency report Website training-data summary (12 items)
Reporting to the state Critical safety incidents to OES; internal-use risk summaries None; public posting only
Look-back New or substantially modified frontier models Systems released on or after Jan. 1, 2022
Penalties Up to $1M per violation, attorney general only No penalty section in the title

The TDTA is already being tested in court

xAI sued California’s attorney general to block the TDTA, arguing it forces disclosure of trade secrets and compels speech. On March 4, 2026, U.S. District Judge Jesus Bernal denied a preliminary injunction, finding xAI had not identified any dataset or cleaning approach distinct enough to warrant trade secret protection and had not shown a likelihood of success on its First Amendment claims, as Ars Technica reported. The law stays in force while xAI’s appeal to the Ninth Circuit (No. 26-1591) remains pending; as of late October 2026 that court had not ruled. We examined the constitutional arguments in our analysis of xAI v. Bonta.

The ruling matters for ordinary developers too. Judge Bernal accepted that datasets could in principle be trade secrets but required specifics. A company that plans to redact or generalize its TDTA disclosure on trade secret grounds should be ready to explain exactly what is secret and why, rather than relying on the general value of training data.

What a privacy team should do with this

The TDTA’s personal information question is where privacy and AI governance collide. Item seven asks whether training data includes personal information as the CCPA defines it, and that definition is broad. Customer chats, support tickets, CRM notes and call transcripts almost always contain it. A company that answers “no” without checking takes on a different kind of risk: a public statement that may be inaccurate.

A workable program starts with a few concrete steps.

  • Inventory public-facing generative AI. List every system available to Californians that your organization built, fine-tuned or retrained since January 1, 2022. Include chatbots, writing tools, image generators and embedded features in products.
  • Decide who is the developer for each. If you call a vendor’s model through an API without modification, the vendor is likely the developer. If you fine-tuned or retrained, you may be one too. Write down the reasoning.
  • Trace each dataset to its source. The twelve items assume you know where data came from, when it was collected, whether it was licensed and how it was cleaned. Many teams discover this information was never recorded.
  • Reconcile with your privacy notice. If customer data trained a public model, your privacy notice and any opt-out or consent obligations need to reflect that use. A TDTA disclosure that reveals a use your notice never mentioned is a problem in its own right.
  • Set a release gate. Make documentation a condition of launching each new version or substantial modification, since the obligation repeats with every release.

Training-data provenance problems are not hypothetical. Our piece on the Nvidia YouTube scraping lawsuit shows how quickly the sourcing question turns into litigation, and our AI governance framework guide explains how to fold these duties into a single program rather than one per law. Teams that operate across states should also watch how other attorneys general frame AI obligations, as in Oregon’s guidance for businesses.

Where Captain Compliance fits

Captain Compliance’s AI governance module is designed to inventory the AI an organization builds, buys and allows employees to use, route systems through risk and impact assessments, record vendors and keep the evidence behind each approval. Its data mapping tools connect systems, data categories, purposes and vendors. Together, they can hold the dataset sources, collection dates and personal-information findings that a TDTA disclosure draws on. The disclosure itself, and the legal judgment about who counts as a developer, remain your team’s responsibility.

Frequently asked questions

Does the TDTA apply if we only use a third-party model through an API?

If you do not design, code, produce or substantially modify the system, you are probably not the developer. Fine-tuning or retraining changes that analysis, because the statute treats those as substantial modifications. Get counsel’s view on borderline products.

Is SB 53 relevant to companies that do not train frontier models?

Not as a direct obligation. It is useful as a source of published frameworks and transparency reports from covered developers, which buyers can use in vendor reviews.

When did both laws take effect?

SB 53 took effect on January 1, 2026. The TDTA required its first disclosures on or before January 1, 2026, covering systems released since January 1, 2022.

Has a court blocked the TDTA?

No. A federal district court denied xAI’s request for a preliminary injunction in March 2026, and the law remains in force while the appeal is pending.

Do internal-only AI tools need a TDTA disclosure?

The TDTA covers systems made publicly available to Californians. A tool used only by employees is generally outside that description, though the statute’s definitions should be checked against the specific deployment.

The disclosure is the easy part

Writing a twelve-item summary takes an afternoon. Knowing what to write takes records most organizations never kept: where each dataset came from, when it was gathered, whether anyone had the right to use it and whether it held personal information. California has made that history public business. The companies that struggle will be the ones that fine-tuned a model in 2023 and can no longer say with confidence what they fed it.

Put this into practice

Turn privacy guidance into working controls.

Captain Compliance helps teams discover tracking technologies, enforce consent, manage privacy requests and document the evidence behind every decision.

Book a demo Run a free scan