Binding law — not yet in force or stayed
Frontier developers must report critical safety incidents within 72 hours, or 24 hours if lives are at imminent risk (New York RAISE Act)
GBL 1422(3) requires a frontier developer to notify the DFS office of any critical safety incident involving its frontier models within 72 hours of determining that one occurred or of learning facts that support a reasonable belief that one did. The statute defines these incidents narrowly: unauthorized access to or tampering with model weights that causes death or bodily injury, harm from a catastrophic risk materializing, loss of control that causes death or injury, or a model deceiving its developer to get around controls or monitoring outside an evaluation in a way that shows materially higher catastrophic risk. When an incident poses an imminent risk of death or serious physical injury, the developer must tell an appropriate authority, such as law enforcement or a public safety agency, within 24 hours. A developer may instead meet a federal standard the office designates after declaring that intent. Detect a frontier developer with no incident procedure that classifies these incidents and meets the 72-hour and 24-hour clocks.
ny-raise-act.critical-safety-incident-reporting · N.Y. Gen. Bus. Law 1422(3)(a)-(b) · official source · applies from 2027-01-01 · jurisdictions: US-NY
Binding law — not yet in force or stayed
Large frontier developers must publish and follow a frontier AI framework (New York RAISE Act)
New York's RAISE Act, as rewritten by chapter 96 of 2026, requires a large frontier developer (one training models with more than 10^26 operations whose group revenue exceeded $500 million the prior year) to write, put into practice, abide by, and conspicuously post on its website a frontier AI framework explaining in detail how it handles ten topics: adopting recognized standards, capability thresholds for catastrophic risk, mitigations, deployment and internal-use review, third-party assessment, framework updates and what counts as a substantial modification, security of unreleased weights, critical safety incident response, internal governance, and internal-use risk including models evading oversight. It must revisit the framework yearly, repost any material change with its reasons within thirty days, and send the DFS office summaries of internal-use catastrophic-risk assessments every three months or on an agreed schedule. Detect a covered developer with no current published framework covering those topics or no record of the internal-use summaries.
ny-raise-act.frontier-ai-framework · N.Y. Gen. Bus. Law 1421(1) · official source · applies from 2027-01-01 · jurisdictions: US-NY
Binding law — not yet in force or stayed
Frontier developers must publish a transparency report when deploying a new or substantially modified frontier model (New York RAISE Act)
Before or at the time a frontier developer deploys a new frontier model, or a substantially modified one, GBL 1421(3) requires it to post a transparency report on its website giving its website, a way for a person to contact it, the model's release date, supported languages and output modalities, intended uses, and any general use restrictions. Large frontier developers must add summaries of the catastrophic-risk assessments run under their framework, the results, how far third-party evaluators were involved, and other framework steps taken for that model. Publishing the information inside a system card or model card satisfies the duty. Detect a frontier-model release process with no transparency report or model card carrying these fields.
ny-raise-act.transparency-report · N.Y. Gen. Bus. Law 1421(3)(a) · official source · applies from 2027-01-01 · jurisdictions: US-NY