From veto to law: how SB 53 came about

SB 53 is the second attempt by State Senator Scott Wiener to regulate frontier AI. His earlier bill, SB 1047, would have required developers of very large models to adopt safety protocols, test for dangerous capabilities and be able to shut models down, with liability for critical harms. After an intense debate that split the technology industry, Governor Gavin Newsom vetoed it in September 2024, arguing that it focused on model size rather than actual risk and could stifle innovation.

Instead of abandoning the issue, the Governor convened a working group of AI experts, including Stanford's Fei-Fei Li, to develop an evidence-based approach. Its report, published in June 2025, recommended a "trust but verify" framework built on transparency, third-party evaluation, incident reporting and whistleblower protection. SB 53 translated much of that thinking into law. Its lighter, disclosure-based design won a broader coalition than SB 1047; notably, at least one major frontier developer publicly endorsed the bill before it passed.

Who is covered

SB 53 uses two layered definitions:

  • Frontier developer. A person that has trained, or initiated the training of, a "frontier model" — a foundation model trained using a quantity of computing power greater than 10^26 integer or floating-point operations, including compute used in subsequent fine-tuning or modification.
  • Large frontier developer. A frontier developer that, together with its affiliates, had annual gross revenues above USD 500 million in the preceding calendar year.

The compute threshold captures only the most advanced models on the market, and the revenue threshold concentrates the heaviest obligations on the largest companies. Start-ups and academic researchers are largely outside the law's scope. The California Department of Technology is required to review the definitions annually and recommend updates, recognising that fixed compute thresholds can age quickly as training becomes more efficient.

What "catastrophic risk" means

The law is not about everyday harms such as bias or misinformation, which are addressed by other rules. It targets "catastrophic risk": 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 more than USD 1 billion in property damage, arising from a single incident in which the model:

  • provides expert-level assistance in creating or releasing a chemical, biological, radiological or nuclear weapon;
  • engages, without meaningful human oversight, in a cyberattack or in conduct that would constitute murder, assault, extortion or theft if committed by a human; or
  • evades the control of its developer or user.

This narrow definition is deliberate. It focuses regulatory attention on low-probability, high-impact scenarios where the case for public oversight is strongest and where companies' private incentives may be insufficient.

The core obligations

1. A published frontier AI framework

Large frontier developers must write, implement, comply with and publish on their websites a "frontier AI framework." It must explain, among other things, how the company incorporates national and international standards and industry best practices; how it defines and assesses thresholds for catastrophic risk; what mitigations it applies; how it uses third-party evaluations; how it secures unreleased model weights; what internal governance ensures the framework is followed; and how it identifies and responds to critical safety incidents. The framework must be reviewed at least annually, and material changes must be published with a justification.

2. Transparency reports at deployment

Before or at the time of deploying a new frontier model or a substantially modified version, all frontier developers must publish a transparency report with basic information: the release date, supported languages and output modalities, intended uses, and general restrictions or conditions of use. Large frontier developers must additionally summarise their catastrophic-risk assessments, the results, the extent of third-party evaluator involvement and other steps taken under their framework. Companies may redact information to protect trade secrets, cybersecurity or public safety, but must explain the character of and reasons for redactions.

3. Reporting to the state

Large frontier developers must periodically send the California Office of Emergency Services (Cal OES) a summary of their assessments of catastrophic risk arising from internal use of their frontier models — a recognition that some of the most capable systems may be used inside companies long before public release.

4. Critical safety incident reporting

Frontier developers must report "critical safety incidents" to Cal OES within 15 days of discovery. Where an incident poses an imminent risk of death or serious physical injury, it must be disclosed within 24 hours to an appropriate authority, such as law enforcement. Critical safety incidents include unauthorised access to model weights that results in harm, harm resulting from the materialisation of a catastrophic risk, loss of control of a model causing injury, and a model using deceptive techniques to subvert its developer's controls in a way that demonstrates materially increased catastrophic risk. Members of the public can also report incidents. Cal OES will publish anonymised, aggregated annual reports beginning in 2027.

5. Honesty obligations

Frontier developers may not make materially false or misleading statements about catastrophic risk from their models or their management of it, and large frontier developers may not make such statements about their compliance with their own frameworks. This converts voluntary safety commitments into legally enforceable promises.

6. Whistleblower protection

Employees responsible for assessing, managing or addressing the risk of critical safety incidents are protected from retaliation when they disclose information to authorities about dangers to public health or safety resulting from catastrophic risk, or about violations of the law. Large frontier developers must provide an internal anonymous reporting channel and keep whistleblowers updated on the handling of their reports. Contractual clauses that prevent such disclosures are unenforceable.

7. Enforcement and CalCompute

The Attorney General can seek civil penalties of up to USD 1 million per violation. Separately, the law establishes a consortium to design "CalCompute," a public cloud computing cluster intended to give researchers and start-ups access to compute and to foster safe, ethical and equitable AI development.

What one year has shown

The first observable effect of SB 53 has been the standardisation of safety disclosure. Several leading developers already published voluntary safety frameworks before the law — responsible scaling policies, preparedness frameworks and frontier safety frameworks. SB 53 turned those voluntary documents into legal obligations with a minimum content, a review cycle and liability for misleading statements. Industry observers have noted that frameworks have become more structured and more comparable, though they still vary widely in how concretely they define risk thresholds and mitigations.

Second, transparency reports — often published as "system cards" or "model cards" — have become a routine part of major releases, with explicit sections on catastrophic-risk evaluations. Recent releases have included capability assessments in sensitive domains; one Turkish press report in September 2026, for instance, described a newly announced model from a leading developer as being rated at the highest capability level for cybersecurity in the developer's own evaluation. Such disclosures are exactly what the law was designed to make visible, and they give policymakers early warning of where risks are rising.

Third, the incident-reporting system is still maturing. Because Cal OES's first public reports are due only in 2027, it is too early to assess how many incidents have been reported or how the agency responds. The same is true of enforcement: as of this writing, no public enforcement action under SB 53 has come to wide attention.

The federal and interstate context

SB 53 operates amid a contested debate over who should regulate AI in the United States. In 2025, a proposed ten-year federal moratorium on state AI laws was stripped from a federal budget bill by an overwhelming Senate vote. Later in 2025, the federal executive branch signalled its intention to challenge state AI laws considered burdensome, raising questions about potential litigation and pre-emption. Meanwhile, other states have moved in similar directions; New York's RAISE Act, for example, adopted a frontier-model safety and transparency framework that was reportedly aligned more closely with SB 53 before its signature. For a broader view of US developments, see our overview of AI regulation in the United States.

California has also continued to legislate on other AI risks. Its AI Transparency Act on content provenance, which we covered in "CATA is live," and its new rules on companion chatbots and child safety, discussed in our report on "Adam's Law," show a state building a layered AI rulebook: frontier-risk transparency at the top, specific consumer protections below.

SB 53 and the EU AI Act: two routes to the same destination?

The EU AI Act regulates general-purpose AI (GPAI) models with systemic risk — presumed where training compute exceeds 10^25 FLOPs, a threshold ten times lower than SB 53's. Obligations for GPAI providers have applied since August 2025, and the European Commission's powers to enforce them began in August 2026. The EU's General-Purpose AI Code of Practice, published in July 2025, provides a voluntary route to demonstrate compliance, including a detailed safety and security chapter.

The two regimes share important elements: risk assessment and mitigation, serious-incident reporting, cybersecurity and documentation. But they differ in philosophy:

  • Disclosure versus conformity. SB 53 mainly requires companies to publish what they do and to follow their own frameworks. The EU imposes substantive obligations assessed by a regulator, backed by fines of up to 3 per cent of global turnover for GPAI providers.
  • Audience. SB 53's transparency is largely public-facing; much EU documentation goes to the AI Office and downstream providers.
  • Scope. SB 53's thresholds are higher and its definition of catastrophic risk narrower; the EU's systemic-risk concept is broader.
  • Whistleblowers. SB 53 builds in AI-specific whistleblower protection; in the EU, protection comes mainly from the general Whistleblower Directive, which now also covers AI Act breaches.

For global developers, the practical result is convergence: a single well-built frontier safety framework, incident-response process and documentation set can serve both regimes, with jurisdiction-specific adjustments.

Critiques and open questions

  • Transparency is not safety. Critics argue that publishing a framework does not guarantee that it is adequate. A company could comply with SB 53 while setting weak thresholds, provided it describes them honestly.
  • Self-defined standards. Because developers largely define their own risk thresholds, comparability across companies remains limited without independent standards.
  • Compute thresholds. Training-compute thresholds are a crude proxy for capability. Efficient training methods may produce highly capable models below the threshold.
  • Enforcement capacity. Cal OES and the Attorney General need technical expertise to evaluate reports and investigate violations.
  • Pre-emption risk. Federal action against state AI laws could narrow or complicate the law's application.

Supporters respond that transparency is a necessary first step: without visibility into how companies assess catastrophic risks, neither regulators nor the public can judge whether stronger rules are needed.

What SB 53 teaches Turkey

Turkey is not home to frontier developers at SB 53's scale, and a direct transplant of the law would make little sense. But the Californian model offers five lessons that fit Turkey's position as a fast-growing AI adopter and aspiring developer.

1. Start with transparency where capacity is limited

Detailed conformity assessment requires regulatory capacity that takes years to build. Disclosure obligations — published risk frameworks, model documentation, incident reports — can be introduced sooner and create the information base for later rules. Turkey's future AI legislation, whose possible architecture we discussed in our analysis of the draft Turkey Artificial Intelligence Act, could adopt a similar phased approach.

2. Build incident reporting into existing institutions

SB 53 routes incident reports to the state's emergency-management agency rather than creating a new AI regulator. Turkey could similarly leverage existing structures — for example, the institutions established under its 2025 Cybersecurity Law — for reporting serious AI incidents affecting critical infrastructure, public services or large numbers of people.

3. Protect the people who see risks first

Engineers and safety researchers are often the first to notice dangerous behaviour. Turkey lacks a comprehensive whistleblower-protection statute. Targeted protection for employees who report serious AI risks — in both public and private sectors — would be a low-cost, high-value safeguard.

4. Use procurement as leverage

As the public sector adopts AI under the 2026–2030 AI Action Plan, the state can require transparency reports, risk documentation and incident-notification clauses from AI suppliers. Our report on mandatory AI literacy for public servants shows the state is already investing in capacity on the user side; procurement rules would complete the picture on the supplier side.

5. Pair safety with access to compute

CalCompute reflects the idea that safety regulation and innovation policy belong together. Turkey's investments in national computing capacity and domestic models can be tied to responsible-development commitments, ensuring that public support also advances transparency and safety.

A compliance checklist for frontier and near-frontier developers

  • Determine coverage. Track cumulative training compute, including fine-tuning, and group revenues against SB 53's thresholds — and against the EU's lower systemic-risk threshold.
  • Publish and follow a framework. Ensure your frontier AI framework reflects what you actually do; misleading statements are themselves a violation.
  • Prepare transparency reports. Build a release process that produces required disclosures at deployment, with a documented redaction policy.
  • Set up incident response. Define critical safety incidents internally, assign responsibility and prepare 15-day and 24-hour reporting workflows.
  • Protect whistleblowers. Establish an anonymous internal channel, review employment contracts and train managers on anti-retaliation.
  • Secure model weights. Treat unreleased weights as critical assets with documented cybersecurity controls.
  • Harmonise across jurisdictions. Map SB 53, the EU AI Act and other regimes to build one integrated governance system.

What to watch next

The coming year will test SB 53 in several ways. Cal OES's first annual incident reports, due in 2027, will show whether the reporting system works. The Department of Technology's review of definitions may propose updated thresholds. The first enforcement actions, if any, will reveal how the Attorney General interprets "materially false or misleading" statements. Federal litigation or legislation on pre-emption could reshape the landscape. And the CalCompute consortium's report will indicate whether California's public-compute ambition becomes reality.

Frequently asked questions

Does SB 53 apply to companies outside California?

The law applies to frontier developers whose models are deployed in or otherwise subject to California's jurisdiction, which in practice covers the major global developers that offer services in the state.

Does SB 53 require safety testing before release?

Not directly. It requires large frontier developers to publish and follow a framework that describes how they assess and mitigate catastrophic risks, and to summarise those assessments in transparency reports.

What counts as a critical safety incident?

Examples include unauthorised access to model weights resulting in harm, harm from the materialisation of a catastrophic risk, loss of control causing injury, and a model deceptively subverting its developer's controls in a way that materially increases catastrophic risk.

How large are the penalties?

Up to USD 1 million per violation, enforced by the California Attorney General.

How is SB 53 different from the vetoed SB 1047?

SB 1047 imposed more prescriptive safety duties and liability for critical harms. SB 53 focuses on transparency, incident reporting and whistleblower protection.

Does Turkey have a comparable law?

No. Turkey has no frontier-AI-specific legislation. Relevant obligations currently arise from general laws such as the KVKK and cybersecurity rules, and from policy instruments such as the AI Action Plan.

Is SB 53 compatible with the EU AI Act?

Largely yes. The regimes differ in thresholds and philosophy, but a developer can build one governance system that satisfies both with targeted adjustments.

Expert Opinion

This section reflects my personal assessment as the founder of this site and an AI ethics & compliance counsel.

In my view, SB 53's greatest achievement is not any single obligation but a change in the default. Before the law, what frontier developers disclosed about catastrophic risks depended on their goodwill; after it, silence and misleading reassurance carry legal consequences. That is a modest step, and critics are right that transparency is not the same as safety. But in a field where the risks are uncertain and the technology changes monthly, a legally enforced duty to show your work is a sensible foundation. It creates the evidence base that stronger rules — if they prove necessary — will need.

I am more cautious about two points. First, compute thresholds will not age well; the law's annual review mechanism must be used actively, not ceremonially. Second, the value of incident reporting depends entirely on what the state does with the reports. If Cal OES lacks the technical capacity to analyse them, the system risks becoming a filing exercise. The first public reports in 2027 will be the real test.

For Turkey, my advice is to borrow SB 53's logic rather than its thresholds. We do not need to regulate models Turkish companies are not building, but we do need visibility into the powerful systems our institutions and citizens use, a channel for reporting serious AI incidents, and protection for people who speak up about risks. Combined with procurement rules and investment in domestic capacity, a transparency-first approach would allow Turkey to govern frontier AI responsibly today, without waiting for a comprehensive law that may take years to finalise.

This article is for information only and does not constitute legal advice. Descriptions of SB 53 are based on the enacted text and publicly available analyses; developments after publication, including federal action, may affect its application. References to model releases are based on press reports. The analysis and assessments are the author's own.