New York RAISE Act (GBL Article 44-B, §§ 1420-1429 — Frontier AI Safety): AI Compliance Requirements

Report each critical safety incident to the oversight office within the NY Department of Financial Services within seventy-two hours. The clock has TWO independent triggers and the earlier one governs: 72 hours "from a determination that a critical safety incident has occurred", OR 72 hours "of the frontier developer learning facts sufficient to establish a reasonable belief that a critical safety incident has occurred" (§ 1422). You cannot defer the clock by declining to conclude an internal investigation. A "critical safety incident" (§ 1420(4)) includes unauthorized access to, modification of, or exfiltration of a frontier model's weights that results in death or bodily injury; a materialized catastrophic risk; loss of control of a model causing death or bodily injury; and a model using deceptive techniques in a way that demonstrates materially increased catastrophic risk. "Catastrophic risk" (§ 1420(3)(a)) is a foreseeable and material risk that the developer's development, storage, use or deployment of a frontier model will materially contribute to the death of, or SERIOUS INJURY TO, MORE THAN FIFTY PEOPLE, or more than $1,000,000,000 in damage to, or loss of, property. The report must state the incident date, why it qualifies, a plain description, and whether it arose from internal use. This duty falls on EVERY frontier developer, not only large ones. The office publishes an annual anonymized incident report beginning January 1, 2028.

This is a SEPARATE, SHORTER clock that runs alongside the 72-hour office report — it does not replace it. Under § 1422, "if a frontier developer discovers that a critical safety incident poses an imminent risk of death or serious physical injury, the frontier developer shall disclose that incident within twenty-four hours" to an appropriate law enforcement or public safety authority. Build the escalation path before January 1, 2027: who inside the company can make the imminent-risk call, which authority is contacted, and how the 24-hour disclosure is evidenced. A developer that files only the 72-hour office report on an imminent-risk incident has missed this duty.

Under § 1421(1) a large frontier developer must "write, implement, comply with, and clearly and conspicuously publish" a frontier AI framework. Note the four verbs: publishing a framework you do not follow is itself a violation, because § 1427 separately penalises failure to comply with your own framework. The framework must address: how national and international standards and industry consensus best practices are incorporated; the developer's catastrophic-risk thresholds, which must be multi-tiered; the mitigations applied at each threshold; how assessments are conducted before deployment; the extent to which third-party evaluators are involved; cybersecurity practices protecting unreleased model weights from unauthorized access, misuse or modification; procedures for responding to critical safety incidents; and how the framework is implemented through internal governance, including assessment of catastrophic risk arising from the developer's own internal use of its models.

Under § 1421(3), "before, or concurrently with, deploying a new frontier model" a frontier developer must publish a transparency report on its internet website. "Deploy" is defined at § 1420(5)(a) as making a frontier model available to a third party for use, modification, copying, or combination with other software — so an internal-only model does not trigger this report, but making weights available to a third party does. The report must identify the developer and give a mechanism for contacting it; state the release date, the languages supported, and the output modalities; and state the intended uses and any restrictions or conditions on use. A LARGE frontier developer must additionally include summaries of its assessments of catastrophic risk, the results of those assessments, and the extent to which third-party evaluators were involved. This duty applies to EVERY frontier developer, which is the practical trap: a developer below the $500M revenue line owes no framework but still owes this report.

Section 1428 is a REGISTRATION gate, and it bites earliest of any duty in this article: "no large frontier developer may develop, deploy, or operate a frontier model, in whole or in part in New York state, without having a current disclosure statement filed" with the office, and it must pay its pro-rata share of an assessment levied to defray the office's operating expenses. Note "develop" — the gate closes before deployment, not at it. The statement must give the developer's identity and any other business names used, its principal place of business and any New York offices, its beneficial ownership (5% or more for a private company, 50% or more for a public one), and primary, secondary and tertiary contact information. It must be renewed every two years, whenever ownership is transferred, or whenever there is a material change — whichever occurs earliest. The office publishes a public list of registered developers, excluding contact details.

Under § 1421(2) the frontier AI framework is not a one-time artefact. Review it at least annually, and where you materially modify it, publish the modified framework within thirty days of the modification together with a justification for the change. Two artefacts must therefore exist on a recurring basis: a dated record that the annual review happened (including a review that concluded no change was needed), and, for each material change, the republished framework plus its written justification inside the 30-day window. Diarise the annual review from the date of first publication rather than from January 1.

Under § 1421(4) a frontier developer must not make materially false or misleading statements about catastrophic risk arising from its frontier models, or about its compliance with its own frontier AI framework. A good-faith exception applies. In practice this converts marketing copy, safety-card claims, model releases and investor materials into regulated statements: the safety representations you make outside the statutory documents are enforceable against you by the Attorney General under § 1427. Route public safety claims through the same review that clears the framework and the transparency report, so the three cannot contradict one another.

Section 1421(5) permits redaction of published material to protect trade secrets, cybersecurity, public safety, or national security — but redaction is conditional, not free. Where you redact, you must describe the character of the redacted information and justify the redaction, and you must retain the unredacted information for five years. Two operational consequences: build the redaction log at publication time rather than reconstructing it later, and treat the unredacted originals of the framework and every transparency report as five-year records under legal hold, because they are the evidence that the published version was a lawful redaction rather than an omission.

Under § 1422(2) a large frontier developer must transmit to the office a summary of any assessment of catastrophic risk resulting from INTERNAL USE of its frontier models every three months (or on an alternate schedule agreed with the office). This is the duty most easily missed, because it is not incident-driven: it fires on a calendar even in a quarter with no incident, and it covers models the developer never deploys to anyone. The office is required to protect the confidentiality of what it receives, with access limited to authorized personnel. Stand up the internal-use risk assessment process itself before January 1, 2027 — you cannot summarise an assessment you never performed.

This requirement described the original Chapter 699 formulation: a written safety and security protocol identifying and mitigating "critical harm", cybersecurity controls, pre- and post-deployment testing regimes, and a designated senior compliance officer. The chapter amendment (L. 2026 ch. 96) restructured these duties into the frontier AI framework at § 1421(1) and its content list, so treat ny_frontier_ai_framework as the operative obligation. Retained here because the underlying practices — cybersecurity for model weights, pre-deployment assessment, incident-response procedures and named internal governance ownership — are each expressly required framework contents under § 1421(1), and a developer that already built them to the Chapter 699 shape has done most of the work.