California Transparency in Frontier Artificial Intelligence Act

The California Transparency in Frontier Artificial Intelligence Act (SB 53) is a first‑in‑the‑nation law requiring large developers of frontier‑scale AI models to publicly disclose standardized safety, risk, and capability information. It was signed by Governor Gavin Newsom on September 29, 2025, and takes effect in January 2026, establishing California as the leading U.S. state for frontier‑AI safety regulation. It is part of a rapidly evolving body of state AI legislation targeting the highest‑risk AI development activities.

Below is a clear, structured description based on the law and expert legal analysis.

📘 Overview of the Transparency in Frontier Artificial Intelligence Act (TFAIA)

The TFAIA (SB 53) creates mandatory safety, transparency, and accountability requirements for developers of frontier AI models—the most computationally intensive and potentially high‑risk AI systems.

California enacted it to balance innovation with public safety, following recommendations from a state‑commissioned expert report on frontier AI risks.

🧠 What Models Are Covered?

The Act applies to frontier models, defined as:

  • Foundation models trained with more than 10^{26} FLOPs, including compute used in fine‑tuning or reinforcement learning.
    This threshold mirrors the 2023 U.S. AI Executive Order and exceeds the EU AI Act’s threshold.

Only large developers of such models are covered.

🏢 Who Must Comply?

Large frontier developers, meaning companies that:

  • Develop frontier‑scale foundation models, and
  • Meet the Act’s size and operational criteria (e.g., revenue or development scale).

The law is intentionally narrower than earlier proposals and applies only to developers, not deployers.

🔍 Key Requirements

  1. Frontier AI Framework (Public Disclosure)

Developers must write, implement, and clearly publish a “frontier AI framework” describing:

  • How they incorporate national and international standards
  • How they apply industry best practices
  • Their approach to risk management and safety

 

 

  1. Catastrophic Risk Assessments

Developers must:

  • Conduct internal assessments of catastrophic risks posed by their models
  • Submit a summary of these assessments to the California Office of Emergency Services (Cal OES)
  1. Critical Safety Incident Reporting

Cal OES must establish a mechanism for:

  • Developers and the public to report critical safety incidents
  • Developers must use this mechanism to report incidents involving catastrophic risk
  1. Enforcement
  • Civil penalties of up to $1,000,000 per violation
  • Enforced by the California Attorney General

⚖️ Policy Goals

The Act aims to:

  • Increase public trust in advanced AI
  • Ensure transparency around high‑risk model capabilities
  • Establish accountability for developers of extremely powerful AI systems

 

Frontier AI Framework Requirements Under California’s TFAIA (SB 53)

Large frontier developers must publish an annual “Frontier AI Framework” that explains how they identify, mitigate, and govern catastrophic risks associated with frontier‑scale AI models. This framework must be public (with limited redactions) and aligned with recognized AI safety standards.

📘 1. Purpose of the Frontier AI Framework

The framework is intended to give regulators, researchers, and the public a clear view into how a developer:

  • Assesses catastrophic risks
  • Implements safety governance
  • Ensures cybersecurity and misuse prevention
  • Aligns with national and international AI safety standards

This is the core transparency mechanism of SB 53.

🧩 2. Required Components of the Frontier AI Framework

  1. Governance Structure

The framework must describe:

  • Internal teams responsible for safety, red‑teaming, and risk evaluation
  • Decision‑making processes for model deployment
  • Escalation pathways for high‑risk findings
  1. Catastrophic Risk Identification & Mitigation

Developers must explain:

  • How they detect catastrophic risks (e.g., mass casualty potential, CBRN assistance, autonomous harmful actions)
  • How they mitigate or prevent those risks
  • How they evaluate model behavior under adversarial conditions

This aligns with the law’s definition of “catastrophic risk.”

  1. Cybersecurity Measures

The framework must outline:

  • Technical safeguards to prevent model theft or misuse
  • Access controls and monitoring
  • Protections against exfiltration of model weights
  • Incident response procedures
  1. Alignment With Standards

The framework must show how the developer follows recognized AI safety standards, such as:

  • NIST AI Risk Management Framework
  • ISO/IEC 42001 (AI Management Systems)

SB 53 explicitly requires alignment with “recognized standards.”

  1. Safety Testing & Evaluation Methods

The framework must describe:

  • Red‑team testing methodologies
  • Third‑party evaluations (if used)
  • Capability assessments
  • Limitations and known failure modes
  1. Deployment Controls

Developers must explain:

  • Preconditions for deployment
  • How they determine whether a model is safe to release
  • How they monitor post‑deployment behavior

🔓 3. Public Disclosure Requirements

The Frontier AI Framework must be:

  • Published publicly (e.g., on the developer’s website)
  • Updated annually
  • Redacted only for proprietary or security‑sensitive information

This ensures transparency without forcing disclosure of trade secrets.

 

 

 

Catastrophic Risk Assessments Under California’s TFAIA (SB 53)

Under SB 53, every frontier developer must conduct internal catastrophic risk assessments that evaluate whether a frontier‑scale AI model could cause mass harm, enable high‑risk misuse, or autonomously take dangerous actions. These assessments must be completed before deployment and summarized to the California Office of Emergency Services (Cal OES).

🔍 1. What Is a “Catastrophic Risk”?

SB 53 defines catastrophic risk as a foreseeable risk that a frontier model could:

  • Cause death or serious injury to 50+ people, or
  • Cause more than $1 billion in damages, or
  • Provide expert‑level assistance in creating or deploying chemical, biological, radiological, or nuclear (CBRN) weapons, or
  • Autonomously commit major crimes or cyberattacks, or
  • Evade human control in ways that could lead to major harm.

These are the exact scenarios the assessments must evaluate.

🧪 2. What the Assessments Must Cover

A catastrophic risk assessment must analyze the model’s:

  1. Dangerous Capabilities
  • Ability to generate or assist with CBRN threats
  • Ability to autonomously plan or execute harmful actions
  • Ability to meaningfully assist in large‑scale cyberattacks
  • Ability to evade or disable safety controls
  1. Misuse Potential
  • How malicious actors could exploit the model
  • Whether the model can be jailbroken into high‑risk behavior
  • Whether outputs could materially enable catastrophic wrongdoing
  1. Failure Modes & Alignment Risks
  • Unexpected or emergent behaviors
  • Situations where the model acts without meaningful human oversight
  • Adversarial or stress‑test scenarios
  1. Mitigation Measures
  • Safety guardrails
  • Red‑team testing results
  • Cybersecurity protections
  • Monitoring and post‑deployment controls

These assessments must be rigorous enough to demonstrate that the developer has evaluated all foreseeable catastrophic risks before releasing the model.

📝 3. Reporting Requirements

Developers must:

  • Prepare internal catastrophic risk assessments for each frontier model.
  • Submit a summary of these assessments to Cal OES before deployment.
  • Include:
  • Key findings
  • Identified catastrophic risks
  • Mitigation strategies
  • Whether third‑party evaluators were used

The full internal assessment stays with the developer; only the summary is submitted.

🚫 4. Deployment Restrictions

A frontier model cannot be deployed if the catastrophic risk assessment shows an unreasonable risk of catastrophic harm that has not been mitigated.
This is one of the core safety gates of SB 53. New York’s RAISE Act imposes a comparable deployment restriction with a stricter 72‑hour incident reporting window.

See Also