New York’s RAISE Act tied frontier-model duties to a December 2025 signing

The enacted story is a December signing, not the June vote^{[source 1][source 2]}

New York Senate records show both houses passed S6953B on June 12, 2025, then show delivery to the Governor on December 9 and signature as Chapter 699 on December 19. The Senate sponsor’s press release also identifies December 19 as the signing date. The active bill text calls the measure the Responsible AI Safety and Education Act, or RAISE Act. It states that the law takes effect on the ninetieth day after it becomes law, a March 19, 2026 calendar result from the recorded signing date.

The statute uses model and developer thresholds^{[source 1][source 2]}

The S6953B text defines frontier model, large developer, and critical harm using multiple technical and factual conditions. Those definitions distinguish the bill’s target from AI applications generally, without making a public model name a sufficient scope test. Training lineage, compute history, model control, and deployment facts can each matter to that inquiry. This article therefore reports the legislation as a frontier-model framework and does not convert its defined terms into a conclusion about any provider or product.

Test procedures and change paths become part of the system description^{[source 1][source 2]}

The S6953B text calls for safety and security protocols that describe testing for unreasonable critical-harm risk, including misuse, modification, combination with other software, and creation of another frontier model. That framing points engineers toward traceable model revisions, capability evaluations, weight-access controls, and tests that exercise composition with tools or added resources. An evaluation suite must still state its limits: a red-team result can show behavior under a fixture, while an absent result does not establish that a severe risk is impossible. The article reports the statute’s design; it does not certify any model or protocol.

Publication, incident, and enforcement clauses have distinct functions^{[source 1][source 2]}

Before deploying a covered frontier model, the S6953B text requires a written protocol, a public redacted version, and specified retention and testing information; it separately sets a 72-hour disclosure rule for a defined safety incident. It authorizes attorney-general civil enforcement and expressly provides no private right of action. These are distinct mechanisms, so a public safety statement should not be treated as an incident report, and an incident label should not be inferred from ordinary product failure. Later regulations, enforcement decisions, and court interpretations were not used to rewrite the December 2025 event record.

For operations work, that separation argues for different data objects: a published protocol version, a test-run record, an internal event investigation, and a public status message. Joining them prematurely can make a dashboard appear precise while obscuring who made a classification and what evidence was available at that time. The legislation supplies categories and deadlines; it does not make a product telemetry schema self-validating.

A dated test report can name its model artifact, evaluation version, tool configuration, and retained result without disclosing the contents of a security-sensitive protocol. That distinction supports later comparison when a model update changes a measured capability. It does not by itself establish that the surrounding safeguards were sufficient.