What Replaced SB 1047? California SB 53 (TFAIA) Explained — A 2026 Compliance Guide

SB 53, the Transparency in Frontier Artificial Intelligence Act (TFAIA), is the law that replaced the vetoed SB 1047. Governor Newsom signed it on September 29, 2025; key provisions took effect January 1, 2026; and the California Attorney General can impose civil penalties of up to $1 million per violation. If you train a frontier model — a foundation model above the 10^26 FLOP threshold — or deploy one in California, this is the safety statute you are now operating under. This guide walks through what SB 53 actually requires, who is covered, the real deadlines, and how it sits alongside the rest of California's 2026 AI regime.

The SB 1047 to SB 53 transition, in one paragraph

The history matters because it explains the shape of the current law. SB 1047 — the "Safe and Secure Innovation for Frontier Artificial Intelligence Models Act," also authored by Senator Scott Wiener — passed the legislature in August 2024 and was vetoed by Governor Newsom on September 29, 2024. Newsom's veto message argued that SB 1047 was overbroad, captured models that did not pose catastrophic risk, and could discourage open-source development. He simultaneously commissioned a working group of AI experts (including Stanford's Fei-Fei Li and former California Supreme Court Justice Tino Cuéllar) to recommend a more targeted approach. SB 53 is the legislative product of that report. The bill is narrower than SB 1047, focuses on transparency and reporting rather than direct liability for harms, and lengthens incident-reporting timelines from 72 hours to 15 days. It is, in practice, the law SB 1047 was always trying to be.

What SB 53 actually requires (the four duties)

The TFAIA imposes four core obligations, plus a fifth that applies only to large developers. The first is the transparency report: before deploying a new or substantially modified frontier model, every frontier developer (large or not) must publish a report that describes the model's release date, supported languages and modalities, intended uses, restrictions, and the steps taken to fulfill the developer's frontier AI framework. The report must summarize catastrophic-risk assessments and disclose the involvement of third-party evaluators. Practically, a well-written model card can satisfy most of this if its content overlaps the statutory list, but the publication has to happen at or before launch.

The second duty is the frontier AI framework, which applies to large frontier developers — those whose annual gross revenue (including affiliates) exceeded $500 million in the preceding calendar year. The framework is a written, conspicuously published document on the developer's website that explains how the company incorporates national standards (NIST AI RMF), international standards (ISO/IEC 42001), and industry-consensus best practices into its safety program. It must describe how the developer assesses whether its frontier models have capabilities that could pose catastrophic risk, how it mitigates those risks, how it measures the effectiveness of those mitigations (including via third parties), and what cybersecurity practices secure unreleased model weights from unauthorized modification or transfer. The framework must be reviewed and, where appropriate, updated at least annually; material changes require a justification published within 30 days.

The third duty is critical safety incident reporting. All frontier developers must report critical safety incidents to the California Office of Emergency Services (OES) within 15 days of discovery, shortened to 24 hours if the incident poses imminent risk of death or serious physical injury. Critical incidents include unauthorized access to or exfiltration of model weights resulting in serious harm; the materialization of a catastrophic risk; loss of control of a frontier model causing death or bodily injury; and — the provision that has gotten the most attention from AI safety researchers — a frontier model using deceptive techniques against its own developer to subvert the developer's controls or monitoring, outside an evaluation context, in a manner showing materially increased catastrophic risk. That last clause was clearly drafted with scheming-behavior and alignment-evaluation research in mind.

The fourth duty is whistleblower protection. Covered employees — those with responsibilities for risk assessment, evaluation, or compliance, among others — cannot be retaliated against for disclosing reasonable-cause concerns about catastrophic risks or TFAIA violations. Large frontier developers must provide an internal anonymous reporting channel. Successful whistleblower plaintiffs can recover attorneys' fees. The fifth, and quietest, duty applies only to large developers: every three months, they must transmit a confidential summary of catastrophic-risk assessments resulting from internal use of their frontier models to OES. That includes red-teaming results, internal testing of dangerous capabilities, and similar work that never gets published externally.

Who is actually covered: the 10^26 FLOP threshold and the $500M revenue line

SB 53 draws two thresholds, and both matter. The model threshold is 10^26 integer or floating-point operations of training compute, including all subsequent fine-tuning, reinforcement learning, and material modifications. That mirrors the threshold from the 2023 federal AI Executive Order and exceeds the EU AI Act's 10^25 figure. As of early 2026, only a handful of companies have publicly disclosed crossing 10^26 FLOPs — but more are expected to cross it during 2026 and 2027 as compute continues to scale. The developer threshold is the $500 million prior-year gross revenue line, which separates "frontier developers" (subject to transparency reports, incident reporting, and whistleblower duties) from "large frontier developers" (subject to those plus the published frontier AI framework and the quarterly internal-use risk summaries).

Two design choices in those definitions deserve attention. First, the California Department of Technology is required to assess the thresholds annually and recommend updates. That makes SB 53 an explicitly evolving statute — what is out of scope today may be in scope in 2027 or 2028. Second, the FLOP count is cumulative across fine-tuning and material modifications, not just initial pretraining. A company that buys a frontier base model and aggressively fine-tunes it can find itself counted as a frontier developer of the resulting model, even though it didn't do the original 10^26 run. That is a meaningful trap for sophisticated downstream developers and worth modeling carefully against your own training budgets.

SB 53 vs SB 1047: what changed and why it matters

For teams that built SB 1047 compliance plans last year and now need to repurpose them, the key differences are these. SB 1047 imposed a liability regime: developers could be held liable for downstream catastrophic harms caused by their models, with rulemaking authority centered on a new Frontier Model Division. SB 53 imposes a transparency regime: the duty is to publish, report, and document, not to guarantee absence of harm. SB 1047 required pre-deployment safety testing certifications signed under penalty of perjury; SB 53 requires publication of a transparency report and a framework that describes testing, but does not require pre-deployment certification. SB 1047's incident reporting was 72 hours; SB 53's is 15 days (with the 24-hour fast track for imminent-injury cases). SB 1047 included a "full shutdown" capability requirement; SB 53 does not, although the framework requirement nudges developers in that direction by asking how they manage loss-of-control scenarios. And SB 1047's civil penalties scaled with damage caused; SB 53's cap at $1 million per violation, scaled by severity. The net effect is a narrower, more administrable, less litigation-prone regime — but one with sharper anti-fraud teeth, since false statements about your own framework are independently actionable.

SB 53 compliance checklist: a working plan for 2026

For teams that need to act, the practical sequence looks something like this. First, confirm scope by computing your training compute, including post-training modifications, against the 10^26 threshold; if you are anywhere close, document the calculation and revisit it after every major training run. Second, if you are above the threshold and ship to California users, identify the senior owner — typically a head of policy, head of trust and safety, or general counsel — who will sign the transparency report and (if applicable) the frontier AI framework. Third, draft the framework using the NIST AI RMF or ISO/IEC 42001 as anchor structure; SB 53 explicitly invites this and the federal-equivalence clause means alignment with NIST or a designated federal standard can satisfy the framework requirement to that extent. Fourth, stand up an OES-compatible critical-incident reporting workflow with named on-call personnel, a 15-day clock, and a 24-hour fast track. Fifth, implement an internal anonymous whistleblower channel and revise NDAs, employment agreements, and severance templates to remove any provisions that could chill protected disclosure. Sixth, if you are a large frontier developer, build the quarterly internal-use risk summary into your existing red-teaming and dangerous-capabilities-evaluation cadence so the report writes itself.

Documentation is the through-line. SB 53 retains the unredacted version of any redacted disclosure for five years. Combine that with the four-year FEHA records retention and the five-year CCPA risk-assessment retention obligations and you should plan around a five-year minimum retention floor for anything safety-related.

How SB 53 interacts with the rest of California's 2026 AI regime

SB 53 does not exist in isolation. The 2026 California AI compliance environment includes AB 2013 (training data transparency, also effective January 1, 2026), SB 942 (AI watermarking and provenance), the CCPA/ADMT regulations from the California Privacy Protection Agency (effective January 1, 2026; ADMT-specific obligations begin January 1, 2027), and the FEHA Automated-Decision System regulations (effective October 1, 2025). For frontier developers shipping to consumers, the practical reality is that AB 2013 and SB 53 together cover the same model from two angles: AB 2013 asks where the data came from, and SB 53 asks how you are managing the resulting capabilities. For healthcare-adjacent frontier models, layer in AB 489 (clinical impersonation) and AB 3030 (patient-facing disclosure). A single deployment can trigger four or five statutes simultaneously. Our 2026 California AI Compliance Roadmap walks through the combined sequencing.

Why this matters even if you're below the threshold

Most companies reading this are nowhere near 10^26 FLOPs and never will be. So why care? Three reasons. First, SB 53 sets the de facto national norm for AI safety governance because most major AI developers are headquartered in California and won't maintain different practices in different states — the same dynamic that turned the CCPA into a nationwide privacy floor. Investors, customers, and procurement teams will start asking smaller vendors for "SB 53-style" documentation. Second, the statute is dynamic by design: definitions are reviewed annually by the Department of Technology, so today's out-of-scope developer can become tomorrow's in-scope one. Third, SB 53's anti-fraud provision — making materially false statements about your own safety framework actionable — is increasingly being incorporated by reference into customer contracts and AI assurance programs. If you sell to enterprises, expect to see "has not made materially false or misleading statements about its safety practices" show up in MSAs the way SOC 2 did a decade ago. For the operational analog from the engineering side, see our CTO's guide to the 2026 California AI safety framework; for the healthcare-specific implications, see post-SB 1047 MedTech AI safety.

Sources

The primary statute and related materials worth bookmarking are the SB 53 bill text on the California Legislative Information site, the Governor's Office signing announcement, and the explanatory analyses from the Brookings Institution, White & Case, and the Future of Privacy Forum. Industry response has been mixed: Anthropic publicly endorsed the final bill, OpenAI and Google declined to oppose it but emphasized federal preemption concerns, and Andreessen Horowitz objected on burden grounds. The Department of Technology will issue its first annual threshold-review recommendations during the 2026 legislative cycle, which is the next milestone to watch.