From 1 January 2027, developers of the largest AI models that make them available in New York must publish a frontier AI framework, report critical safety incidents within 72 hours and describe how they secure unreleased model weights. The Responsible AI Safety and Education Act (RAISE Act) was signed on 19 December 2025 as Chapter 699 of the Laws of 2025 and then rewritten by a chapter amendment, Senate Bill S8828, signed on 27 March 2026 as Chapter 96. The amended text replaces Article 44-B of the New York General Business Law and, according to the sponsor memo, aligns the law more closely with California's SB 53. This guide sets out who is covered, what the framework must contain, how the incident clocks work and what security and AI governance teams should build before the effective date. It draws on the bill page published by the New York State Senate and two law firm summaries.
Key takeaways
- Scope is narrow. The duties fall on frontier developers that trained a model above 10^26 operations, and the heaviest duties on large frontier developers with more than 500 million US dollars in annual revenue, including affiliates.
- Duties sit with developers. The amended text places its obligations on frontier developers, meaning entities that trained or started training a frontier model. Organisations that only use other developers' models should take advice before assuming they are outside scope.
- Two clocks for incidents. Report a critical safety incident to a new office in the Department of Financial Services (DFS) within 72 hours, and within 24 hours to law enforcement or a public safety agency where there is an imminent risk of death or serious physical injury.
- Model weight security is a written duty. The framework must describe cybersecurity practices that secure unreleased model weights from unauthorised modification or transfer by insiders or outsiders.
- Penalties run to 3 million US dollars. The Attorney General can seek up to 1 million US dollars for a first violation and up to 3 million for later ones, with no private right of action.
Status and timeline
| Date | Event | Source |
|---|---|---|
| 19 December 2025 | Original RAISE Act signed (Chapter 699 of 2025), with an agreement on later clarifications | Wiley; Davis Wright Tremaine |
| 28 January 2026 | Senate passes S8828 | New York State Senate |
| 11 March 2026 | Assembly passes it, substituting companion bill A9449 | New York State Senate; Wiley |
| 27 March 2026 | Chapter amendment signed as Chapter 96 | New York State Senate; Davis Wright Tremaine |
| 1 January 2027 | Core obligations take effect | New York State Senate; Wiley; Davis Wright Tremaine |
| From January 2028 | DFS office begins annual anonymised reports to the Governor and Legislature | Wiley; Davis Wright Tremaine |
Davis Wright Tremaine notes that the New York and California frontier laws could be targets of federal preemption efforts. We do not know how that will play out; check the DFS office's announcements and the bill page before relying on any date here. The US State AI Laws Tracker places RAISE alongside other state laws.
Who is covered
| Term | Meaning in the amended Act | Practical test |
|---|---|---|
| Frontier model | A foundation model trained with more than 10^26 integer or floating point operations | Training compute records for each model |
| Frontier developer | An entity that has trained, or started training, a frontier model | Includes training runs still in progress |
| Large frontier developer | A frontier developer with prior year revenue of more than 500 million US dollars, including affiliates | Group revenue, not the AI unit alone |
| Catastrophic risk | Foreseeable, material risk that a model materially contributes to death or serious injury of more than 50 people, or more than 1 billion US dollars of damage, from one incident | Covers CBRN weapon uplift, unsupervised conduct amounting to a cyberattack or serious crime, and evading developer or user control |
| Critical safety incident | Unauthorised access to, modification or exfiltration of model weights causing death or bodily injury; harm from a catastrophic risk; loss of control causing death or injury; deceptive behaviour against the developer that materially increases catastrophic risk | Weight theft is named explicitly |
Organisations that consume frontier models through an API should confirm their own position with counsel; either way, their suppliers' framework and transparency reports become useful due diligence material. See the Frontier AI Model Risk Frameworks Guide for how developers structure these frameworks.
Duties by developer type
| Duty | All frontier developers | Large frontier developers |
|---|---|---|
| Transparency report at or before release of a new or substantially modified model | Website, contact route, release date, languages and output types, intended uses, use restrictions | Also summaries of catastrophic risk assessments, results, third party evaluator involvement and framework steps |
| Frontier AI framework | Not required | Create, implement, follow and publish; review at least annually; publish material changes with a justification within 30 days |
| Critical safety incident reports | 72 hours to the DFS office; 24 hours to an appropriate authority for imminent risk | Same |
| Internal use risk summaries | Not required | To the DFS office generally every three months |
| Disclosure statement | Not required | File with DFS, renew every two years or on ownership change, and pay a pro rata share of office costs |
| Truthful statements | No materially false or misleading statements about catastrophic risk | Same, including statements about the framework |
Redaction is allowed to protect trade secrets, cybersecurity, public safety or national security, or to comply with law. Davis Wright Tremaine reports a duty to describe the justification where possible and to keep unredacted versions for five years.
What the frontier AI framework must cover
Section 1421 of the amended Article 44-B, as summarised on the Senate bill page, lists the framework topics. Each needs an owner and evidence.
- Risk thresholds and assessment: how the developer decides that a model could pose catastrophic risk, and how it assesses that.
- Mitigations and deployment decisions: what is applied before release and who decides whether to deploy.
- Third party assessments: how external evaluators are used.
- Cybersecurity for unreleased model weights (1421(1)(G)): practices that secure weights from unauthorised modification or transfer by internal or external parties.
- Critical safety incidents: how they are identified and responded to.
- Internal governance and internal use: who is accountable, and how risk from the developer's own use of its models is assessed and managed.
Wiley's summary adds that the framework should describe how national and international standards are incorporated.
Model weight security: what to put in the framework
The Act names the outcome, not the controls. The table below is NHI Mgmt Group's suggested control set for the 1421(1)(G) section; it is our recommendation, not text from the law. Most of it is identity work, because weights are usually reached through service accounts, pipeline tokens and storage keys rather than by people. The Securing AI Model Weights guide covers each control in depth.
| Threat in the Act | Control (our recommendation) | Evidence to keep |
|---|---|---|
| Insider transfer | Named, time bound access to weight stores; no standing human access; two person approval for export | Access reviews, approval records |
| External exfiltration | Workload identity for training and serving jobs instead of long lived keys; egress allow lists on weight storage | NHI inventory, egress logs |
| Unauthorised modification | Signed checkpoints and hash verification before serving | Signing logs, verification failures |
| Credential leakage | Secret scanning on repositories and notebooks; short token lifetimes for pipeline identities | Scan results, rotation records |
| Detection gap | Alert on bulk reads, new principals and unusual destinations for weight objects | Alert tuning notes, response tickets |
Because weight exfiltration that leads to injury is itself a critical safety incident, the detection controls feed the 72 hour clock directly. See the Model Supply Chain Guide for signing and provenance.
Running the incident clocks
The 72 hour clock starts when the developer determines that an incident occurred, or learns facts that reasonably establish one. Amended reports are allowed. DFS may designate federal standards with equivalent or stricter reporting, and a developer that elects to follow them must notify DFS and send copies of the federal reports. We suggest this sequence, which is our recommendation:
- Define triggers in advance. Map each statutory incident type to detection sources: weight store access logs, model behaviour evaluations and red team findings.
- Name a determination owner. One role decides when the facts reasonably establish an incident and records the time.
- Run the imminent risk check first. If there is an imminent risk of death or serious physical injury, notify law enforcement or the relevant public safety agency within 24 hours.
- File the 72 hour report with what you know. Use the amended report route for later facts instead of waiting.
- Align other clocks. Weight theft may also trigger breach or securities disclosure duties elsewhere; the AI Incident Reporting Guide compares regimes.
- Test it. Run a tabletop on a weight exfiltration scenario before 1 January 2027 and fix the gaps.
Decision guidance
- Developer close to 10^26 operations: keep compute accounting per training run now; "started training" counts.
- Frontier developer under the revenue threshold: transparency reports and incident reporting still apply, so build the incident process even without a framework.
- Already covered by California SB 53: reuse the framework and reports, but run the shorter New York incident clock; Wiley and Davis Wright Tremaine both contrast 72 hours in New York with 15 days in California. See the California AI Laws Guide.
- Deployer or API customer: request suppliers' published frameworks and transparency reports and map them to your own third party AI risk process.
Measuring readiness
- Framework coverage: each 1421 topic has an owner and current evidence.
- Weight access: number of identities, human and non-human, with read access to unreleased weights, trending down.
- Determination to report time: measured in exercises against the 72 hour limit.
- Transparency report timeliness: reports published at or before each covered release.
- Framework review: annual review done and material changes published within 30 days.
Common failure patterns
- Framework written by policy staff alone: the weight security section describes intentions that the infrastructure team cannot evidence.
- Counting only human access: pipeline service accounts and storage keys with weight access are left out of reviews.
- Waiting for full facts: the clock starts on reasonable belief, and amended reports exist for later detail.
- Ignoring internal use: large developers must assess and report risk from their own use of models every quarter.
- Inconsistent public statements: marketing claims about safety that contradict the framework can be a separate violation.
Framework mapping
| Framework | Reference | RAISE duty |
|---|---|---|
| NIST CSF 2.0 | GV.OC-03 | Legal requirements understood and managed |
| NIST CSF 2.0 | PR.AA-05 | Access to unreleased weights defined and reviewed |
| NIST CSF 2.0 | RS.CO-02 | Incident notification to external stakeholders |
| NIST SP 800-53 Rev 5 | AC-6, SC-28 | Least privilege and protection of weights at rest |
| NIST SP 800-53 Rev 5 | IR-6, IR-8 | Incident reporting and response plan |
| NIST SP 800-53 Rev 5 | RA-3 | Catastrophic risk assessment |
Practitioner checklist
- Confirm whether you are a frontier or large frontier developer using training compute and group revenue.
- Assign an owner to each framework topic in section 1421.
- Inventory every identity with access to unreleased weights, including service accounts and keys.
- Write the model weight security section from controls you can evidence.
- Map each critical safety incident type to detection sources and a determination owner.
- Build 24 hour and 72 hour notification runbooks and test them.
- Prepare the transparency report template and the redaction log.
- Track the DFS office for rules and designated federal standards.
Standards and references
- New York State Senate: Senate Bill S8828 (2025-2026), Chapter 96 of 2026
- Wiley: New York Finalizes RAISE Act for Frontier AI Models
- Davis Wright Tremaine: NY Overhauls Transparency and Governance Requirements for Frontier AI Developers
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: US State AI Laws Tracker · California AI Laws Guide · Securing AI Model Weights · Frontier AI Model Risk Frameworks Guide. This guide summarises the New York RAISE Act and is not legal advice.