Effective Date: January 1, 2026

California has added another piece to its rapidly developing artificial intelligence regulatory framework. This one is aimed not at every business deploying AI, or even every company developing AI models, but at the developers operating at the technological frontier.

The Transparency in Frontier Artificial Intelligence Act (TFAIA), enacted through SB 53 and codified at California Business and Professions Code §§ 22757.10–22757.16, creates a governance and transparency regime for developers of exceptionally compute-intensive foundation models. Among other things, it requires covered developers to publish information about frontier models before deployment, requires the largest developers to maintain and publicly disclose a framework for managing catastrophic AI risks, establishes mandatory reporting for certain critical safety incidents, and authorizes civil penalties of up to $1 million per violation for specified violations by large frontier developers.

The TFAIA also provides a useful example of an important point discussed in our earlier article: California does not have one universal definition of AI that applies across every AI-related law. AB 2885 established a common, technology-neutral definition of artificial intelligence for several specified provisions of California law, defining AI principally at the system level—an engineered or machine-based system that infers from inputs how to generate outputs capable of influencing physical or virtual environments. As we discussed there, that definition focuses on what an AI system does rather than on a particular model, architecture, or amount of computing power. See, California Defines AI: AB 2885 and Its Impact

SB 53 uses substantially similar language to define an “artificial intelligence model,” but the operative question is not simply whether something qualifies as AI. Instead, the TFAIA builds its coverage around foundation models, frontier models, and the developers that train them, with the frontier-model definition ultimately turning on computational scale. It then creates an additional regulatory tier for “large frontier developers” based on annual gross revenue.

For readers familiar with the EU AI Act, there is a useful parallel to general-purpose AI (GPAI) models. The EU AI Act also distinguishes between regulation of AI systems and regulation at the model level, imposing specific obligations on providers of GPAI models. Within that framework, the EU creates a heightened regulatory tier for GPAI models with systemic risk.

California’s frontier-model regime, like the EU AI Act regime, recognizes that powerful general-purpose models may warrant model- and developer-level obligations, not just regulation of specific AI systems or uses.

To understand who must comply, we therefore need to start with what the TFAIA regulates and who it regulates.

Who and What Is Regulated by the TFAIA? Foundation Models, Frontier Models and Frontier Developers

The TFAIA’s coverage begins with foundation AI models and then narrows that category based on the computing power used to train them.

A foundation model is an AI model that is:

1. trained on a broad dataset;
2. designed for generality of output; and
3. adaptable to a wide range of distinctive tasks.

A foundation model becomes a “frontier model” for purposes of the TFAIA when it is trained using more than 10²⁶ integer or floating-point operations.

The critical threshold that differentiates a foundation model from a frontier model is computational power: more than 10²⁶ integer or floating-point operations.

Importantly, that calculation is not limited to the model’s original training run. The statute requires developers to count computing power used for:

• the original training run;
• subsequent fine-tuning;
• reinforcement learning; and
• other material modifications applied to a preceding foundation model.

In other words, the TFAIA uses computational scale to draw the line between foundation models generally and the frontier models subject to its requirements.

That distinction also determines who qualifies as a “frontier developer.” A frontier developer is a person that has trained, or initiated the training of, a frontier model and has used—or intends to use—at least the amount of computing power required to meet the frontier-model threshold.

See Cal. Bus. & Prof. Code § 22757.11.

The result is a deliberately narrow scope.

Unlike California laws that broadly regulate businesses that use AI, the TFAIA targets frontier developers—entities developing exceptionally compute-intensive foundation models.

There Are Really Two Regulatory Tiers: Frontier Developers and Large Frontier Developers

One of the most important features of the TFAIA is the distinction between a frontier developer and a large frontier developer.

A large frontier developer is a frontier developer that, together with its affiliates, had more than $500 million in annual gross revenues during the preceding calendar year.

Practice Tip: Crossing the frontier-model compute threshold triggers California's baseline transparency and incident-reporting regime. Crossing the $500 million revenue threshold triggers an additional layer of formal AI safety governance.

The distinction matters because some requirements apply to all frontier developers, while the law's more substantial governance requirements apply only to large frontier developers.

At a high level:

Being a frontier developer does not automatically trigger every obligation in the statute.

Frontier Developers: The Baseline Obligations

Not every frontier developer is a “large frontier developer.” But falling below that threshold does not place a frontier developer outside the TFAIA. Instead, the statute establishes a baseline set of obligations applicable to frontier developers generally, while reserving its more extensive governance requirements for large frontier developers.

A frontier developer that does not meet the large-developer threshold is still subject to several important requirements

A frontier developer, regardless of whether it qualifies as a large frontier developer, must:

(1) Prepare and publish model transparency reports. Before, or concurrently with, deploying a new frontier model—or a substantially modified version of an existing frontier model—the developer must clearly and conspicuously publish a transparency report on its website. The report must identify the developer's website and a mechanism for individuals to contact the developer, as well as the model's release date, supported languages and output modalities, intended uses, and generally applicable restrictions or conditions on use. The information may be incorporated into a larger document, such as a system card or model card. Cal. Bus. & Prof. Code § 22757.12(c)(1), (3). Large developers must publish additional information on their transparency reports.

(2) Critical safety incident reporting. Frontier developers must report a critical safety incident involving one or more of their frontier models to the California Office of Emergency Services within 15 days after discovering the incident. If the incident presents an imminent risk of death or serious physical injury, disclosure must instead be made within 24 hours to an appropriate authority, including a law enforcement or public safety agency with jurisdiction, as applicable. Reporting of critical safety incidents pertaining to foundation models that are not frontier models is encouraged but not required. Cal. Bus. & Prof. Code § 22757.13(c).

A critical safety incident includes:

• unauthorized access to, modification of, or exfiltration of frontier-model weights resulting in death or bodily injury;
• harm resulting from the materialization of a catastrophic risk;
• loss of control of a frontier model causing death or bodily injury; and
• certain situations in which a frontier model uses deceptive techniques against its developer to subvert the developer's controls or monitoring.

See, Cal. Bus. & Prof. Code § 22757.11.(d)

Practice Tip: Federal Standards May Offer an Alternative Compliance Path For Critical Safety Incident Reporting. Monitor OES for rules regarding federal laws, regulations, or guidance it designates as having critical-safety-incident reporting requirements that are substantially equivalent to or stricter than California’s. A frontier developer may elect to satisfy the critical-safety-incident reporting requirements of § 22757.13 through a designated federal standard. See Cal. Bus. & Prof. Code § 22757.13(h)–(j).

“Model weight” means a numerical parameter in a frontier model that is adjusted through training and that helps determine how inputs are transformed into outputs. Cal. Bus. & Prof. Code § 22757.11.(k)

That final category contains an important limitation. The statute distinguishes between behavior elicited during safety evaluation and a model actually using deceptive techniques outside that evaluation context. The deceptive behavior must occur outside an evaluation designed to elicit that behavior, and it must demonstrate materially increased catastrophic risk.

A developer does not necessarily create a reportable safety incident simply by deliberately testing whether a model is capable of deception

(3) Truthful statements about catastrophic risk. A frontier developer may not make a materially false or misleading statement about catastrophic risk associated with its frontier models or its management of that risk. The prohibition does not apply where the statement was made in good faith and was reasonable under the circumstances. Cal. Bus. & Prof. Code § 22757.12(e).

The statute defines “catastrophic risk” around an extraordinarily high threshold: a foreseeable and material risk that the development, storage, use, or deployment of a frontier model will materially contribute to:

• the death or serious injury of more than 50 people; or
• more than $1 billion in property damage or loss

arising from a single incident involving specified conduct.

That conduct includes three categories.

1. Provide expert-level assistance in creating or releasing a chemical, biological, radiological, or nuclear weapon.
2. Engage, without meaningful human oversight, intervention, or supervision, in a cyberattack or conduct that—if performed by a human—would constitute murder, assault, extortion, or theft, including theft by false pretenses.
3. Evade the control of its developer or user.

See Cal. Bus. & Prof. Code § 22757.11.(c)(1)

The law also contains exclusions. For example, catastrophic risk does not include risk arising merely from information generated by the model if substantially similar information is otherwise publicly accessible from a source other than a foundation model. It also excludes lawful federal government activity and harm involving other software where the frontier model did not materially contribute to the harm. See Cal. Bus. & Prof. Code § 22757.11.(c)(2)

And, lest anyone try to turn an AI-driven stock-market decline into a billion-dollar catastrophic-risk event, the statute separately specifies that loss of equity value does not count as property damage or loss for purposes of the TFAIA. See Cal. Bus. & Prof. Code § 22757.16.

Practice Tip: Treat AI Safety Statements as Compliance Statements. Frontier developers should ensure that public statements about catastrophic risks and how those risks are managed are accurate and supportable. Large frontier developers should apply the same scrutiny to statements about implementation of and compliance with their frontier AI frameworks. Although the Act protects statements made in good faith and reasonable under the circumstances, safety disclosures should not be treated as ordinary marketing claims.

When Transparency Meets Security: Permitted Redactions

The statute also permits frontier developers to redact information from required public disclosures when necessary to protect trade secrets, cybersecurity, public safety, U.S. national security, or to comply with federal or state law. Where information is redacted, the developer generally must describe the character and justification for the redaction to the extent possible and retain the unredacted information for five years. Cal. Bus. & Prof. Code § 22757.12(f).

Practice Tip: Transparency Does Not Require Disclosing Sensitive Information. Required public disclosures may be redacted when necessary to protect trade secrets, cybersecurity, public safety, U.S. national security, or compliance with federal or state law. Developers should document their redaction decisions carefully: to the extent the underlying concern permits, the public document must describe the character and justification for the redaction, and the unredacted information must be retained for five years.

Frontier AI Frameworks: The Core Requirement for Large Developers

The centerpiece of the TFAIA is the “frontier AI framework.”

A frontier AI framework is defined as documented technical and organizational protocols for managing, assessing, and mitigating catastrophic risks.

The framework must describe how the developer approaches ten areas.

(1) Standards and Best Practices: The framework must address how the developer incorporates:

• national standards;
• international standards; and
• industry-consensus best practices.

See Cal. Bus. & Prof. Code § 22757.12.(a)(1)

(2) Catastrophic-Risk Thresholds: The developer must explain how it defines and assesses thresholds for determining whether a frontier model has capabilities that could create catastrophic risk.

Those thresholds may be multi-tiered.

See Cal. Bus. & Prof. Code § 22757.12.(a)(2)

(3) Risk Mitigation: The framework must address how the developer applies mitigations based on the results of those assessments.

See Cal. Bus. & Prof. Code § 22757.12.(a)(3)

(4) Deployment Decisions: Developers must explain how they review risk assessments and the adequacy of mitigations when deciding whether to:

• deploy a frontier model; or
• use the model extensively internally.

That second category is particularly notable. The TFAIA does not treat risk as something that begins only when a model is released to customers.

See Cal. Bus. & Prof. Code § 22757.12.(a)(4)

(5) Third-Party Evaluation: The framework must address the use of third parties to assess both:

• potential catastrophic risks; and
• the effectiveness of mitigations.

See Cal. Bus. & Prof. Code § 22757.12.(a)(5)

(6) Framework Updates: The developer must explain how it revisits and updates its framework, including the criteria triggering an update and how it determines when a model has been sufficiently modified to require new disclosures. See Cal. Bus. & Prof. Code § 22757.12.(a)(6)

(7) Model-Weight Cybersecurity: The framework must address cybersecurity practices for protecting unreleased model weights against unauthorized modification or transfer by internal or external parties. See Cal. Bus. & Prof. Code § 22757.12.(a)(7)

8. Critical Safety Incidents: The developer must describe how it identifies and responds to critical safety incidents. See Cal. Bus. & Prof. Code § 22757.12.(a)(8)

(9) Internal Governance: The framework must include governance practices designed to ensure that these processes are actually implemented. See Cal. Bus. & Prof. Code § 22757.12.(a)(9)

(10) Risks From Internal AI Use: Finally, the framework must address catastrophic risks arising from the developer's own internal use of frontier models—including risks associated with a model circumventing oversight mechanisms. See Cal. Bus. & Prof. Code § 22757.12.(a)(10)

Practice Tip: Do Not Overlook Internal Use. SB 53’s catastrophic-risk obligations are not limited to models released to customers or other third parties. Large frontier developers should incorporate internal uses of frontier models—including risks of models circumventing oversight mechanisms—into their risk-assessment processes and establish procedures for transmitting assessment summaries to California Office of Emergency Services (OES), generally every three months or on another reasonable schedule communicated to OES in writing.

This last requirement is particularly interesting in light of the increasingly agentic capabilities of frontier AI systems.

California is expressly requiring covered developers to consider what happens when a powerful model does not behave as its oversight mechanisms expect.

A large frontier developer must review its frontier AI framework at least annually and update it as appropriate. If the developer makes a material modification, it must clearly and conspicuously publish the revised framework, together with a justification for the change, within 30 days. See Cal. Bus. & Prof. Code § 22757.12.(b)

Every large frontier developer must write, implement, comply with, and clearly and conspicuously publish a framework on its website for managing, assessing, and mitigating catastrophic risks.

This is more than a transparency requirement. The developer must actually comply with the framework it publishes. See Cal. Bus. & Prof. Code § 22757.12.(a)

Other Requirement for Large Developers

In addition to developing, publishing, and complying with a frontier AI framework, large frontier developers are subject to several additional obligations that go beyond the baseline requirements applicable to all frontier developers.

(1) Enhanced Transparency: Assessing, Publishing and Addressing Catastrophic-Risks. When deploying a new frontier model—or a substantially modified version of an existing one—a large frontier developer must supplement the transparency disclosures required of all frontier developers with summaries of:

• the catastrophic-risk assessments conducted under its frontier AI framework;
• the results of those assessments;
• the extent to which third-party evaluators participated; and
• other steps taken to comply with the frontier AI framework with respect to that model.

These disclosures must be published before or concurrently with deployment, although they may be incorporated into a larger document such as a system card or model card. Cal. Bus. & Prof. Code § 22757.12(c)(2)–(3).

(2) Periodic Reporting of Risks From Internal Use. Large frontier developers must also provide the California Office of Emergency Services (OES) with summaries of assessments of catastrophic risks arising from their internal use of frontier models. These assessments must generally be transmitted every three months, although the developer may establish another reasonable reporting schedule and communicate it in writing to OES, with updates as appropriate. Cal. Bus. & Prof. Code § 22757.12(d).

(3) Additional Prohibition: Materially False or Misleading Statements of Catastrophic Risks. Like all frontier developers, large developers may not make materially false or misleading statements about catastrophic risk or their management of that risk. Large frontier developers are subject to an additional prohibition: they may not make materially false or misleading statements about their implementation of, or compliance with, their frontier AI framework. Statements made in good faith and reasonable under the circumstances are excluded from this prohibition. Cal. Bus. & Prof. Code § 22757.12(e).

California Is Building an Ongoing Frontier AI Oversight System

OES gathers information about how frontier-model risks materialize in practice, while the Department of Technology periodically evaluates whether the statutory boundaries identifying the models and developers subject to the Act remain appropriate.

The TFAIA does more than impose obligations on frontier developers. It also creates an ongoing state oversight structure designed to collect information about serious AI safety incidents and adapt the law as frontier technology evolves. Two California agencies play particularly important roles: the Office of Emergency Services (OES) and the Department of Technology.

(1) OES serves as the TFAIA’s safety-reporting hub: It must establish mechanisms through which frontier developers—and members of the public—can report critical safety incidents, as well as a confidential mechanism for large frontier developers to submit assessments of catastrophic risks arising from their internal use of frontier models. Beginning January 1, 2027, OES must also issue annual reports containing anonymized and aggregated information about the critical safety incidents it has reviewed. Those reports must protect information that could compromise trade secrets, developer cybersecurity, public safety, national security, or otherwise violate applicable law. Cal. Bus. & Prof. Code § 22757.13.

• OES has already operationalized this reporting role through the California Cybersecurity Integration Center, which now hosts a dedicated TFAIA reporting page and secure portal. The portal allows both frontier developers and members of the public to confidentially submit reports of critical safety incidents; it also provides the mechanism for submitting the periodic summaries of catastrophic-risk assessments arising from large frontier developers’ internal use of frontier models. The OES webpage provides direct access to the secure portal as well as a QR code for submissions. See the OES Transparency in Frontier AI Act Reporting page.

(2) The Department of Technology, meanwhile, is responsible for helping keep the TFAIA’s coverage aligned with technological developments. Beginning January 1, 2027, it must annually review relevant evidence and developments and recommend whether California should update the definitions of “frontier model,” “frontier developer,” and “large frontier developer.” In doing so, it must consider factors including federal and international standards, stakeholder input, whether developers can determine coverage before training or deployment, the complexity of the definitions, and whether coverage can be independently verified. Cal. Bus. & Prof. Code § 22757.14.

Practice Tip: Treat the Coverage Thresholds as Moving Targets. Do not assume that today’s definitions of frontier model, frontier developer, and large frontier developer will remain fixed. Beginning January 1, 2027, the California Department of Technology must review technological and scientific developments annually and recommend whether those definitions should be updated. Developers operating near the Act’s thresholds should therefore monitor California’s annual recommendations and reassess coverage as the technology and regulatory standards evolve.

Enforcement: Up to $1 Million Per Violation

The Act provides potentially significant enforcement authority.

A large frontier developer may face a civil penalty of up to $1 million per violation, depending on the severity of the violation, if it:

• fails to publish or transmit a compliant document required by the Act;
• makes a prohibited false or misleading statement;
• fails to report a required critical safety incident; or
• fails to comply with its own frontier AI framework.

Civil penalties may be recovered only through an action brought by the California Attorney General.

Cal. Bus. & Prof. Code § 22757.15(a)–(b)

The statute therefore does not create a private right of action under this enforcement provision.

Conclusion: From AI Safety Principles to Legal Compliance

For companies building at the technology frontier, AI safety governance is a compliance function.

California’s TFAIA applies directly to a relatively small universe of developers, but its significance extends beyond the companies currently capable of training models at the statutory frontier.

For organizations that do fall within its scope, compliance requires coordination across legal, engineering, security, and AI governance teams. Developers need to determine coverage before major training runs, identify whether the enhanced requirements for large frontier developers apply, integrate transparency obligations into deployment decisions, establish rapid incident-escalation procedures, and maintain records supporting their risk assessments and public representations.

More broadly, the TFAIA reflects an emerging regulatory model for advanced AI. California does not prescribe precisely how a frontier model must be made safe. Instead, the Act requires developers—and particularly large frontier developers—to formalize how they manage catastrophic risk, provide transparency about those processes, report critical safety incidents, and stand behind the governance commitments they make.

That last point may prove particularly consequential. Under the TFAIA, an AI safety framework is no longer simply an internal engineering document or statement of corporate principles. For a large frontier developer, failure to comply with its own framework can become a violation of California law.

Practice Tip: Treat Your Frontier AI Framework as an Enforceable Compliance Commitment. A large frontier developer’s framework is not merely an aspirational governance document. Failing to comply with the framework it adopted can itself constitute a violation of California law, potentially exposing the developer to enforcement by the Attorney General. Companies should therefore avoid making framework commitments they cannot operationalize and should establish internal controls to document, monitor, and verify ongoing compliance with their own framework.

Relevant Resources

Legal Citations

• California Transparency in Frontier Artificial Intelligence Act — Cal. Bus. & Prof. Code §§ 22757.10–22757.16 — The operative statutory provisions governing frontier models and developers, including definitions, transparency reports, frontier AI frameworks, catastrophic-risk assessment, critical safety incident reporting, state oversight, and enforcement.
• Senate Bill 53 (2025–2026) — California Legislative Information — The enacted legislation, together with bill versions, legislative history, votes, and committee analyses.

Regulatory and Agency Resources

• California OES — Transparency in Frontier AI Act Reporting — The California Office of Emergency Services' dedicated TFAIA page and secure reporting portal. Frontier developers and members of the public can use the portal to confidentially report critical safety incidents, and large frontier developers can submit required periodic summaries concerning catastrophic-risk assessments arising from internal use.
• California Department of Technology — Transparency in Frontier AI Act — Information concerning the Department's responsibilities under SB 53, including its annual review of whether the statutory definitions of frontier model, frontier developer, and large frontier developer should be updated to reflect technological and scientific developments.

Legislative and Historical Context

• Governor Newsom Signs SB 53 — The Governor's September 29, 2025 announcement describing the policy objectives behind SB 53 and highlighting its transparency, safety, accountability, and adaptive-governance provisions.
• Governor Newsom's SB 53 Signing Message — The Governor's formal signing message explaining California's rationale for state-level oversight of advanced AI, the role of public safety, cybersecurity and national security, and the importance of coordination with emerging federal AI safety standards.

Related Articles from The de la Torre Review

• California Defines AI: AB 2885 and Its Impact — Explains California's technology-neutral statutory definition of AI, the distinction between AI systems and AI models, and why California does not have a single universal definition of AI across all of its laws—important context for understanding SB 53's more specialized foundation- and frontier-model definitions.
• California's AI Training Data Transparency Law: What Generative AI Developers Must Disclose — Examines California's separate model-level transparency regime requiring covered generative AI developers to disclose information about the datasets used to develop their systems, illustrating another component of California's growing developer-focused AI regulatory framework.
• Who Is Regulated Under the EU AI Act? Understanding Providers, Deployers, Importers, Distributors and Other Operators — Provides comparative context on how the EU AI Act allocates obligations across the AI value chain, including obligations applicable to providers of general-purpose AI (GPAI) models.
• The EU AI Act Explained: A General Guide to Europe's Risk-Based AI Regulation — An overview of the EU's broader AI regulatory framework, useful for comparing California's targeted approach to frontier AI with the EU AI Act's regulation of AI systems and general-purpose AI models.