DEV Community

Multigrid
Multigrid

Posted on • Originally published at multigrid.ai

California SB 53: the Transparency in Frontier AI Act

SB 53 does not regulate AI. It regulates a named set of companies, identified by a compute number and a revenue number, and almost every question about it resolves to whether you are inside those two figures or outside them.

The two thresholds that decide coverage

The Transparency in Frontier Artificial Intelligence Act was signed by Governor Newsom on 29 September 2025 and took effect on 1 January 2026. It adds a new chapter to Division 8 of the California Business and Professions Code beginning at section 22757.10, and it is the statute that took the place of SB 1047, which the same governor vetoed in 2024. The two bills are not the same instrument in a different jacket: SB 1047 would have imposed a duty of care and a shutdown capability, and SB 53 imposes disclosure and reporting.

Coverage runs through three defined terms. A frontier model is a foundation model trained using more than 1026 integer or floating-point operations, counting compute used in fine-tuning and other post-training. A frontier developer is a person who has trained, or initiated the training of, such a model. A large frontier developer is a frontier developer whose annual gross revenues, together with affiliates, exceeded $500,000,000 in the preceding calendar year. Most of the substantive obligations attach only to the third category.

This is not legal advice. Whether your training run crosses 1026 operations, and how affiliate revenue is aggregated, are fact questions with real consequences; take advice on your own numbers rather than on a rule of thumb.

The compute threshold is deliberately high. It is the same order of magnitude used in the EU’s systemic-risk presumption for general-purpose models, which sits at 1025 FLOP — see the GPAI systemic-risk obligations for that comparison — so a company that is out of scope in Sacramento may well be in scope in Brussels. The revenue threshold is the part that keeps startups out: a laboratory can train past 1026 operations and still owe only the transparency report, not the framework.

Read the enacted text at the California Legislative Information site, which carries the chaptered version rather than an introduced draft.

The frontier AI framework

A large frontier developer must write and publish, on its own website, a document the statute calls a frontier AI framework, and must review it at least annually. The required contents are enumerated, and they are worth reading as a checklist rather than as a theme: how the developer incorporates national and international standards and industry consensus; how it defines and assesses thresholds for catastrophic risk; what mitigations it applies when a threshold is met; how it uses third-party assessments; the cybersecurity practices it uses to secure unreleased model weights; how it identifies and responds to critical safety incidents; and how it governs all of that internally.

Catastrophic risk is itself defined, and narrowly. It means a foreseeable and material risk that a frontier model will materially contribute to the death of, or serious injury to, more than 50 people, or to more than $1,000,000,000 in damage to or loss of property, arising from a single incident involving expert-level assistance with a chemical, biological, radiological or nuclear weapon; a cyberattack on critical infrastructure; or a model evading the control of its developer or user. Ordinary product harms — a bad medical answer, a defamatory output, a discriminatory ranking — are not catastrophic risk under this statute. They are governed by other law entirely.

Redactions are contemplated. The framework may be published with trade secrets, cybersecurity-sensitive detail and national-security material removed, provided the redaction is described and an unredacted copy is retained. That is the same structure the New York RAISE Act uses, and it is the design that makes a published safety framework possible at all.

Transparency reports at deployment

Separately, and this duty reaches every frontier developer rather than only the large ones, a transparency report must be published at or before the moment a new or substantially modified frontier model is deployed. The report identifies the developer, the model, its release date, the modalities of input and output it supports, the languages it supports, the intended uses, and any generally applicable restrictions or conditions on use.

“Substantially modified” is the term that will generate argument. A version bump that changes the checkpoint is plainly a new deployment; a change to a system prompt or a safety filter is plainly not. Between those is a large space — continued pre-training, a new post-training recipe, a distillation — where the statute’s text does not resolve the question and no California court has yet been asked to. Treat the boundary as unsettled and document how you drew it.

Critical safety incident reporting

This is the duty most likely to bind in practice, because it has a clock. A frontier developer must report a critical safety incident to the California Office of Emergency Services within 15 days of discovering it, and within 24 hours where the incident poses an imminent risk of death or serious physical injury. The categories are defined and include unauthorised access to model weights, a model providing materially increased catastrophic-risk assistance, loss of control causing death or bodily injury, and a model using deceptive technique against its developer in a way that materially increases catastrophic risk.

A fifteen-day clock runs from discovery, not from confirmation, and not from the end of your incident review. If you are inside scope, the practical consequence is an internal escalation path that reaches counsel in days rather than weeks. Take advice on your own reporting design.

Cal OES is directed to produce an anonymised, aggregated annual report on the incidents it receives, with the first due on 1 January 2027. That report is the thing to watch: it is the only public signal of how many incidents are actually being filed, and it will say more about the statute’s bite than the text does.

Reporting a model-level incident requires knowing which model version served which request, which is an infrastructure question before it is a legal one. A system that logs a provider-side model string per call can answer “what did we ship, and when”; one that logs only “the LLM” cannot.

If requests are spread across several providers, the record that matters for a question like this is the per-request one: which model identifier the provider actually returned, at what time, under which key. A gateway that normalises those fields across providers gives you one place to answer it from, rather than four exports to reconcile.

Penalties, whistleblowers and what is not here

Enforcement belongs to the California Attorney General, who may bring a civil action for penalties of up to $1,000,000 per violation. There is no private right of action. That single design choice separates SB 53 from Illinois BIPA, where the private right of action and per-violation damages are the whole engine of the law, and it means the realistic risk profile here is an AG inquiry rather than a class action.

SB 53 also adds whistleblower protection in the Labor Code for employees responsible for assessing or managing catastrophic risk, and requires large frontier developers to run an internal anonymous reporting channel for such employees. Those provisions are easy to overlook because they sit outside the Business and Professions Code chapter, and they are the part that touches HR rather than the model team.

Two things the statute does not do. It does not require pre-deployment approval from any agency: nothing here is a licensing regime. And it does not create a standard of care that a plaintiff can borrow — the vetoed SB 1047 would have, and this one does not. For the California disclosure duties that do reach ordinary product teams, see AB 2013 on training-data disclosure and SB 942 on content provenance.

The definitions, the compute threshold and the revenue figure are all subject to statutory review — the California Department of Technology is directed to recommend updates annually from 2027. Check the current text before relying on a threshold quoted anywhere, including here.

Related

Top comments (0)