Written and maintained by CASRAI Editorial Board
Last updated
A “frontier AI framework” is not a generic term for any AI safety document. It is a specific, named regulatory artifact: a public document that California’s SB 53 and New York’s RAISE Act require certain large AI developers to write, publish on their website, and keep up to date. Both statutes use that exact phrase — but they didn’t always, and their requirements are not identical. This guide explains what each law actually requires, why the two used different terms until a March 2026 amendment, and how a Frontier AI Framework relates to a lab’s own voluntary safety policy, like Anthropic’s Responsible Scaling Policy (RSP).
The short answer
A Frontier AI Framework is the document in which a covered developer describes, in writing, how it identifies and manages catastrophic risk across a frontier AI model’s lifecycle — the thresholds it uses to flag dangerous capabilities, how it tests for them, what mitigations it applies before deployment, and how it governs and audits its own compliance with that process. It is not the same thing as a transparency report (a separate, per-model disclosure both laws also require) and it is not automatically the same thing as a lab’s pre-existing voluntary safety policy, though the two can overlap heavily.
How California’s SB 53 defines it
SB 53, the Transparency in Frontier Artificial Intelligence Act (TFAIA), was signed on September 29, 2025 and took effect January 1, 2026. It is the law that coined the statutory term. Under California Business and Professions Code §22757.11(g), a “frontier AI framework” is defined as the developer’s documented technical and organizational protocols to manage, assess, and mitigate catastrophic risk. Section 22757.12(a) requires a “large frontier developer” — one that, together with its affiliates, had more than $500 million in annual gross revenue in the preceding calendar year — to write, implement, comply with, and clearly and conspicuously publish that framework on its website.
The statute lists what the framework has to address:
- How the developer incorporates national and international standards and industry-consensus best practices
- How it defines and assesses the capability thresholds used to identify catastrophic risk
- The mitigations it applies to address that risk
- How it reviews those assessments and mitigations as part of the decision to deploy
- Its use of third parties to assess catastrophic risk
- How and when it revisits and updates the framework itself
- Cybersecurity practices to secure unreleased model weights
- How it identifies and responds to critical safety incidents
- Internal governance practices that ensure the framework is actually implemented
- How it assesses and manages catastrophic risk from the model’s internal use, not just external deployment
The framework must be reviewed at least annually, and any material modification has to be published, with an explanation, within 30 days. Separately, before deploying a new frontier model, developers must also publish a transparency report covering the release date, intended uses, and a summary of catastrophic-risk assessments — the transparency report is a per-model disclosure; the framework is the standing policy behind it. SB 53 also sets a critical-safety-incident reporting clock: 15 days to notify California’s Office of Emergency Services after a developer discovers an incident, or 24 hours if the incident poses an imminent risk of death or serious physical injury. For the full incident-reporting mechanics, see SB 53 Critical Safety Incident Reporting, and for the rest of the statute’s obligations, see the foundational SB 53 explainer.
How New York’s RAISE Act defines it — and why it used to look different
This is where it’s easy to get the two laws conflated, because the RAISE Act’s terminology actually changed. When Governor Hochul first signed the RAISE Act on December 19, 2025 (as bills S6953-B/A6453-B), the statute did not use the phrase “frontier AI framework” at all. Its defined term was a “safety and security protocol,” and its coverage threshold was compute-based rather than revenue-based — a “large developer” was one that had spent more than $100 million in aggregate compute costs training frontier models (or met related compute/distillation thresholds), not one measured by revenue.
That changed with a chapter amendment (A9449/S8828) that Hochul signed on March 27, 2026, negotiated specifically to align New York’s law more closely with California’s. The amended RAISE Act now also requires large frontier developers to “create, implement, comply with, and clearly and conspicuously publish” a Frontier AI Framework, with a required-topics list that closely tracks SB 53’s — standards incorporation, capability thresholds, mitigations, third-party evaluation, cybersecurity for model weights, incident response, internal governance, and criteria for updating the framework itself. The large-developer threshold was also changed to match: gross annual revenue exceeding $500 million, the same figure SB 53 uses. The amended RAISE Act takes effect January 1, 2027, and, like SB 53, requires a separate transparency report alongside the framework.
The two laws are not identical even now. The most notable remaining difference is the incident-reporting clock: the RAISE Act requires disclosure of a safety incident within 72 hours, versus SB 53’s 15-day (or 24-hour, for imminent risk) window. For the current state of the New York law, see the RAISE Act explainer.
SB 53 vs. the RAISE Act: what a covered developer actually owes
| Requirement | California SB 53 (TFAIA) | New York RAISE Act (as amended) |
|---|---|---|
| Statutory term | Frontier AI Framework | Frontier AI Framework (since the March 2026 chapter amendment; originally “safety and security protocol”) |
| Effective date | January 1, 2026 | January 1, 2027 |
| “Large developer” threshold | >$500M annual gross revenue (with affiliates) | >$500M annual gross revenue (with affiliates), aligned to SB 53 by the amendment |
| Review cycle | At least annually; changes published within 30 days | At least annually; changes published within 30 days |
| Separate transparency report | Required, before deploying each new frontier model | Required, before deploying each new frontier model |
| Critical-incident reporting window | 15 days (24 hours if imminent risk of death/serious injury) | 72 hours |
Is a lab’s own voluntary framework the same thing?
Not automatically, but it can be, and this is the point that trips people up most often. SB 53 itself leaves room for it: Section 22757.12(c)(3) says a developer that publishes the required information as part of a larger existing document is deemed in compliance. In principle, a lab’s own voluntary safety policy — a Responsible Scaling Policy, a Preparedness Framework, a Frontier Safety Framework — can serve as the statutory Frontier AI Framework, provided its content actually covers the statute’s required topics and is published in the way the law requires.
In practice, at least one major lab chose not to take that shortcut. Anthropic’s RSP predates SB 53 by two years, but rather than designating the RSP itself as its legal compliance document, Anthropic published a separate document, the Frontier Compliance Framework (FCF), and designated that as its Frontier AI Framework under SB 53. Anthropic has said the RSP “will remain our voluntary safety policy, reflecting what we believe best practices should be…even when that goes beyond or otherwise differs from current regulatory requirements,” while the FCF is scoped specifically to what the statute requires. Much of the FCF’s substance overlaps with practices the RSP already described, but the two are formally distinct documents serving different purposes: one is a regulatory filing, the other is a standing voluntary commitment that can go further than the law asks.
The practical takeaway: don’t assume a company’s existing voluntary safety document is its statutory Frontier AI Framework, and don’t assume the two are unrelated, either. Check what the developer has specifically designated as its SB 53 or RAISE Act framework — it may be a distinct, narrower document written to satisfy the statute, sitting alongside a broader voluntary one.
Where NIKOLAI fits in
Because SB 53 and the amended RAISE Act now use the same statutory term but developers had already been describing similar concepts — thresholds, mitigations, incident types, governance — inconsistently in their own voluntary documents for years, comparing frameworks across labs is harder than the shared terminology suggests. CASRAI’s NIKOLAI dictionary exists for exactly this problem: its N7 (Incidents) and N9 (Commitments & Governance) tracks give incident types, reporting deadlines, and framework-update obligations a common vocabulary, drawing on SB 53 itself as one of its source documents alongside labs’ published frameworks. NIKOLAI’s crosswalks are independent, unendorsed “shadow mappings” rather than official filings, but they’re a useful way to see where two labs’ frameworks — or a lab’s framework and a statute’s requirements — actually line up.
FAQ
Is a Frontier AI Framework the same as a transparency report?
No. The framework is the standing policy document describing a developer’s risk-management process; the transparency report is a separate, per-model disclosure published before each new frontier model is deployed. Both are required, but they are distinct filings under both SB 53 and the RAISE Act.
Does every AI company need to publish one?
No. Only “large frontier developers” are covered — under both laws as they currently stand, that means developers of frontier models whose annual gross revenue (with affiliates) exceeds $500 million. Smaller developers may owe lighter transparency obligations but not the full framework requirement.
Do SB 53 and the RAISE Act require the same framework?
They require frameworks that are similar in structure and mostly overlapping in required content, but not identical. The clearest remaining difference is the incident-reporting deadline: 15 days (24 hours for imminent risk) under SB 53, versus 72 hours under the RAISE Act. A developer covered by both states will likely need a framework built to satisfy the stricter of the two on any given point.
Did the RAISE Act always use the term “frontier AI framework”?
No. As originally signed in December 2025, it used “safety and security protocol” and a compute-based coverage threshold. A chapter amendment signed in March 2026 changed the term to “Frontier AI Framework” and aligned the coverage threshold with SB 53’s revenue-based test, ahead of the law’s January 1, 2027 effective date.
Can a company just reuse its existing voluntary safety policy?
It can, if that document’s content actually satisfies the statute’s required topics and is published the way the law requires — SB 53’s text explicitly allows publishing the required information as part of a larger document. Whether a given company does that, or instead writes a separate, narrower compliance document, is a company-by-company choice; check what each developer has specifically designated as its statutory framework rather than assuming its best-known voluntary policy fills that role.
