View as PDF

Frontier AI developers such as OpenAI, Google, Anthropic, xAI, and others are governed by safety and security obligations under California’s SB 53, New York’s RAISE Act, and the frontier AI part of the EU’s AI Act. These laws establish incident reporting requirements, model evaluation standards, safety and security mitigations, internal governance practices, and whistleblower protections. This document summarizes key provisions from these laws, though it is not a substitute for the official legal text.

Law	Target	Risks	Obligations	Timeline
CA SB 53	Companies that train a model with >10^26 FLOPs and (for most obligations) >$500m annual revenue	Death or injury of >50 people or >$1b damage via: - CBRN weapons - Autonomous cyberattacks, murder, assault, extortion or theft - Loss of control	Public framework, public report with model release, internal use reports every three months, incident reports, whistleblower protections	1 January 2026: entry into effect
EU AI Act, details in CoP	Companies that train a model with >10^25 FLOPs (with exceptions above & below this threshold)	"significant impact" via: - CBRN weapons - Loss of control - Cyber offense - Harmful manipulation	Risk assessment and mitigation, including evals, security, and incident tracking and reporting (CoP: also frameworks and reports with model release, and internal governance)	2 August 2025: companies must comply 2 August 2026: EU AI Office can enforce
NY RAISE Act	Same as CA SB 53	Same as CA SB 53	Same as CA SB 53, but more detailed framework and more rapid incident reporting	1 January 2027: entry into effect

Overview

California’s SB 53 applies to developers who have trained or begun training at least one model using ≥10^26 FLOPs, with a stricter tier of requirements applying to “large” developers who also had gross annual revenue greater than $500M in the previous calendar year.¹ It establishes incident reporting requirements, transparency standards, and whistleblower protections. The full text of SB 53 can be found here.²

The EU’s Code of Practice for General-Purpose AI is an elaboration on the EU AI Act, explaining what steps a developer of a general-purpose AI model³ can take to comply with the Act. The Safety and Security chapter of the Code contains requirements for developers of frontier AI models, and its signatories include OpenAI, Anthropic, Google, and xAI. It covers model evaluation, safety and security mitigations, internal governance, and incident tracking and reporting. Signatories have been expected to comply with the Code since August 2025, and the European AI Office will begin enforcement in August 2026. The text of the EU AI Act can be found here and the Code of Practice is here.

Every frontier AI company that has used or expects to use >10^25 FLOPs of compute to train a model that is or will be deployed in the EU is bound by the EU AI Act’s safety and security requirements. However, the European AI Office has discretion to exempt a model above the compute threshold from the requirements, or to determine that a model is covered even though it is below the threshold. Frontier AI companies that decline to sign the Code (such as Meta) must demonstrate compliance through alternative adequate means.⁴

New York’s RAISE Act is another state-level safety regulation covering frontier AI developers. It will come into effect on the first day of 2027. RAISE requires more rapid incident reporting than SB 53—72 hours as opposed to 15 days—and it requires developers’ frontier AI frameworks to be more detailed than SB 53 requires. It is otherwise quite similar to the California law. Because of its similarity to SB 53, this document will not discuss RAISE separately. The full text of the RAISE Act can be found here.

Risks

SB 53 and the Code of Practice both cover catastrophic risks from AI, but the risks in scope are somewhat different. SB 53 requires large frontier AI developers to assess and mitigate risks related to:⁵

• Chemical, biological, radiological, and nuclear (CBRN) weapons
• AI systems autonomously conducting cyberattacks
• AI systems autonomously committing murder, assault, extortion, or theft, and
• AI systems evading the control of their developers or users.

The Code of Practice requires signatories to assess and mitigate risks related to:⁶

• CBRN weapons
• Loss of control
• Cyber offense, and
• Harmful manipulation.

Frameworks

SB 53 requires every large frontier AI developer to publish a “frontier AI framework” on its website. This document must describe the developer’s approach to catastrophic risk assessment, engagement with third parties, model weight security, and more.⁷ The commitments a developer makes in its frontier AI framework are legally binding. If a developer fails to comply with its own framework, it can be fined up to one million dollars per violation.⁸

The Code of Practice requires a signatory to write a “safety and security framework” and to share it with the European AI Office. The framework must describe how the signatory will assess and mitigate systemic risks, how they determine whether systemic risk is acceptable, how they allocate responsibility for risk assessment and mitigation internally, and more.⁹ The signatory must then implement their framework and update it as appropriate.¹⁰ A signatory is required to publish a summary of the framework if and insofar as necessary to assess or mitigate systemic risk and encouraged (but not required) to clearly communicate the framework to their own staff.¹¹

Incident reporting

SB 53: Frontier developers must report critical safety incidents to the California Office of Emergency Services. Once they discover the incident, the developer has a limited time to make their report.¹²

Incident type	Reporting window
Death/injury from loss of control, materialization of a catastrophic risk, unauthorized access to model weights leading to death/injury, or deceptive subversion by a model of its developer’s controls13	15 days
Incidents posing imminent risk of death or serious injury	24 hours

Additionally, large frontier developers are required to share their assessments of catastrophic risk from internal AI use with the Office of Emergency Services by submitting quarterly summaries.¹⁴

Code of Practice: Signatories must track, document, and report serious incidents to the European AI Office.¹⁵ Reporting timelines depend on the type of harm:

Incident type	Reporting Window
Serious disruption to critical infrastructure	2 days
Serious cybersecurity breach, including model weight exfiltration	5 days
Death of a person	10 days
Serious harm to health, fundamental rights, property, or environment	15 days

For unresolved incidents, signatories must submit intermediate reports at least every four weeks and a final report within 60 days of resolution. Reports must include root cause analysis, a description of the chain of events, any patterns detected in post-market monitoring, and corrective measures taken or recommended. Signatories must also facilitate incident reporting by downstream deployers and users by informing them of available reporting channels. Documentation must be retained for at least five years.

Security

SB 53: Every large frontier developer must describe their cybersecurity practices in their published frontier AI framework, explaining how they prevent unauthorized modification or transfer of frontier model weights.¹⁶ A developer is legally bound to follow their announced security practices and can face fines if they don’t.

Code of Practice: Signatories commit to define a security goal saying what kinds of threat actors they will prevent from accessing or stealing their frontier models. At a minimum, the security goal must include defending against non-state external threats and insider threats (including model self-exfiltration).¹⁷

A signatory must then implement measures adequate to meet their security goal, possibly including stricter security measures for models further along in the development lifecycle.¹⁸

Model evaluation

The Code of Practice says a signatory’s evaluation team must have appropriate and adequate resources to assess the risks posed by the signatory’s models. As appropriate for systemic risk assessment, evaluators should have:¹⁹

• Adequate model access, which may include activations, logits, CoTs, and minimally guardrailed (sometimes called “helpful only”) versions if they exist, insofar as such extensive access is compatible with model security,
• Adequate information, which may include the model spec, system prompt, training data, and prior results,
• Adequate access time before model release, with at least twenty business days of access recommended, and
• Adequate compute, staff, and engineering resources.

A developer should engage independent external evaluators for each new frontier model, and at least every six months thereafter for their most capable models,²⁰ and the external evaluators should be given adequate resources as in the list above.²¹

Model reports

SB 53: Before or concurrently with deploying a new frontier model or a substantially updated version of an existing model, a large frontier developer must publish a “transparency report” about that model. This report must summarize the catastrophic risk assessments the developer conducted to follow their frontier AI framework, the results of those assessments, the extent to which third party evaluators were involved in assessing the model, and any other steps the developer took to follow their framework.²²

Code of Practice: Before placing a GPAI model with systemic risk on the EU market, a signatory must submit a “safety and security model report” to the AI Office.²³ This report must describe the model’s architecture, capabilities, and intended operation; justify why the systemic risks stemming from the model are acceptable (including safety margins incorporated); document the signatory’s systemic risk identification, analysis, and mitigation processes; describe any involvement of independent external evaluators; and detail the safety and security mitigations implemented. If and insofar as it is necessary to assess or mitigate systemic risk, a signatory must also publish a summarized version of the report, with redactions permitted to protect the effectiveness of mitigations and sensitive commercial information.²⁴

Internal governance

SB 53: A frontier developer must facilitate internal reporting of evidence that the developer’s activities pose a specific and substantial risk to public health or safety from a catastrophic risk, or that the developer has violated SB 53. There must be a reasonable process by which risk management staff can make such reports anonymously and have them brought to company leaders’ attention.²⁵

Code of Practice: Signatories are required to provide appropriate human, financial, and computational resources as well as appropriate access to information to those who have responsibility for systemic risk oversight, ownership, support, monitoring, and assurance.²⁶ Furthermore, signatories committed to promote a healthy internal risk culture, for example, by:²⁷

• Allowing open internal communication and challenge of risk decisions,
• Maintaining channels for reporting concerns, and
• Keeping risk management staff independent and incentivized to correctly estimate risk.

Whistleblower protections

SB 53: California-based employees with responsibility for risk assessment or management have special whistleblower protections. They are protected from retaliation if they report information that they have reasonable cause to believe shows their employer’s actions pose a specific and substantial danger to public health or safety via catastrophic risk. The employee may report this information to the California Attorney General, federal authorities, supervisors, or colleagues with risk management authority. Every frontier developer must give the relevant employees a clear notice of their whistleblower protections.²⁸

Moreover, all California-based employees are protected from retaliation if they report information that they have reasonable cause to believe shows their employer has failed to comply with SB 53 (or any other federal or state statute).²⁹ Examples of SB 53 noncompliance could include false or misleading statements about catastrophic risk made by a developer or violations of the developer’s published safety policy. Employees may report evidence of such noncompliance to a government or law enforcement agency, a supervisor, or a colleague with authority to investigate or correct the issue.

Code of Practice: Signatories committed to promote a healthy internal risk culture, for example, by not retaliating against employees who report systemic risk information to competent authorities.³⁰ And employees whose contracts are governed by EU law will have enforceable protections against retaliation under the EU Whistleblowing Directive.³¹ Signatories commit to inform their workers annually of the signatory’s whistleblower protection policy.³²

Whistleblowers seeking to contact the European AI Office can send reports through their online whistleblower tool.

Before making a disclosure

Consulting a lawyer before making a disclosure to external authorities or using internal reporting channels can help ensure the disclosure is legally protected. Many whistleblowing attorneys offer pro bono consultations. The House Whistleblower Support Organizations and the AIWI Contact Hub are two resources for finding counsel.

---

For full regulatory text: SB 53 · Code of Practice · RAISE Act

Post updated on February 6, 2026