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, Illinois’ SB 315, 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.

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.

Illinois’ SB 315, the Artificial Intelligence Safety Measures Act, is the third state-level safety regulation covering frontier AI developers. Its most distinctive feature is that it requires each large developer to hire a third party every year to independently audit its compliance, and to publish a high-level summary of the audit findings along with a redacted copy of the auditor’s report. SB 315 takes effect on the first day of 2027, though its frontier AI framework and independent-audit requirements do not apply until January 1, 2028—a full year later, and after both SB 53 and RAISE have taken effect.⁵ Other distinctive provisions to note are large developers may not operate a frontier model in Illinois without a disclosure statement on file with the state⁶; and SB 315 makes the regulation of frontier AI models an exclusive function of the State, preempting local Illinois rules.⁷

SB 315 is otherwise quite similar to the California law; the sections below flag the main points where it goes further. The full text of SB 315 can be found here.

Risks

The U.S. state laws 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

The U.S. state laws require 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 under SB 53, and similar under the other state laws.¹¹

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.¹⁴

Independent audits

SB 315: Beginning January 1, 2028,¹⁵ every large frontier developer must hire an independent third party every year to audit whether the developer has complied with the Act’s framework requirements. This is a procedural compliance audit, meaning it checks whether the developer followed the processes the Act requires—whether it wrote, published, and actually followed its frontier AI framework and published the required transparency reports, including summaries of the catastrophic risk assessments conducted pursuant to its frontier AI framework, but not whether the models are safe.¹⁶

To ensure a fair evaluation, the auditor must be competent in frontier model safety, follow generally accepted auditing standards, and be free of any financial interest in the developer, with its payment not tied to the audit’s findings.¹⁷ The developer, in turn, must provide all materials reasonably necessary for the audit. However, developers may impose security protocols, such as on-premise reviews, copy restrictions, and confidentiality agreements in order to protect trade secrets, cybersecurity, public safety, and national security.¹⁸

The audit report must then state whether the developer has substantially complied with the Act’s framework requirements, explain any material deviations and reasons behind them, provide recommendations on how to correct them, and assess the developer’s internal controls.¹⁹

Further, the developer must keep an unredacted copy for as long as the model is deployed plus five years. Within 30 days of receiving the report, the developer must publish a summary and a redacted copy on its website and send the redacted version to the Illinois Emergency Management Agency and the Attorney General.²⁰

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.²¹

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.²² Under RAISE and SB 315, New York and Illinois will similarly route incident reports to their respective state bodies, and both require critical safety incidents to be reported within 72 hours rather than SB 53’s 15 days.²³

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

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

U.S. state bills: 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.³¹

These disclosed risk assessments and framework compliance measures are then subject to verification under SB 315’s annual independent auditing requirement.

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 are acceptable; 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 permitted redactions.³³

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.

SB 315: Illinois’s whistleblower provisions mirror SB 53’s ban on retaliation and on contracts that suppress disclosure but add Illinois-specific reporting routes. Specifically, an employee responsible for assessing, managing, or addressing the risk of critical safety incidents (“covered employee”) may report to the Attorney General (primarily via the Workplace Rights Hotline), the Illinois Emergency Management Agency and Office of Homeland Security, a federal authority, a person with authority over the covered employee (e.g. their manager), or another covered employee with authority to act on the issue.³⁹ SB 315 also amends the Illinois Whistleblower Act to bar retaliation for good-faith disclosure of any violation of the Act; that provision names no permissible recipient, so it may protect disclosure to the press or the public.⁴⁰ These rights must be made clear to covered employees by workplace posting or annual written notice, with these protections being in addition to, and not limiting, the Illinois Whistleblower Act.⁴¹

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, the AIWI Contact Hub, and the LASST AI Safety Whistleblower Legal Defense Fund are resources for finding counsel. LASST also provides financial support to pay attorney fees and other legal expenses.

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

Post updated on July 28, 2026