New York RAISE Act Registration: Who Must Comply by January 2027?

New York opened RAISE Act registration on November 10 for large frontier AI developers, ahead of the January 1, 2027 deadline. The useful question is whether you train a covered frontier model, qualify as a large developer, or simply build an application using somebody else's model.

Those distinctions matter because the registration requirement and the broader transparency obligations do not apply to exactly the same group. Treating the law as a rule for every AI startup exaggerates its scope. Treating $500 million in revenue as the only threshold misses how the law defines a frontier developer in the first place.

Start with the model, then the developer

The law's definitions describe a frontier model as a foundation model trained using more than 10^26 integer or floating-point operations. The calculation includes the original training run and subsequent fine-tuning, reinforcement learning or other material modifications the developer applies to a preceding foundation model.

A frontier developer is a person or organization that has trained, or started training, a frontier model using or intending to use the required computing power. A large frontier developer is one whose annual gross revenue, together with its affiliates, exceeded $500 million in the preceding calendar year.

That is a training-compute test followed by a revenue test. Revenue alone does not make a company a frontier developer. Equally, a covered frontier developer below the revenue threshold should not assume that every obligation disappears.

The law's territorial scope covers frontier models developed, deployed or operating wholly or partly in New York. Where a company is incorporated is therefore not the only relevant question. Borderline cases, particularly modified models and distributed corporate groups, need a legal review of the actual facts rather than a conclusion based on a product's marketing category.

Separate registration from transparency duties

The state's November 10 announcement says large frontier developers must register through the new RAISE Portal by January 1, 2027. DIGIT, the Office of Digital Innovation, Governance, Integrity, and Trust within the Department of Financial Services, implements the law.

Beginning in January, large frontier developers must publish safety frameworks. All covered frontier developers have model-transparency and critical-incident reporting duties. This distinction is more useful than a single yes-or-no label saying a company is “subject to RAISE.”

Under the transparency provisions, a covered developer must publish a report before or when it deploys a new frontier model or a substantially modified version. The basic information includes release date, supported languages and output modalities, intended uses, use restrictions, its website and a way for people to communicate with it.

Large frontier developers must add summaries of catastrophic-risk assessments, their results, third-party evaluator involvement and steps taken under their safety framework. The law permits the required information to sit within a larger model card or system card. Teams do not necessarily need another standalone document, but they do need to check whether the existing one contains the required information.

An API application is a different case from a model developer

Consider a hypothetical customer-support startup that calls a third-party frontier API and retrieves answers from its own documentation. Buying inference from a covered lab does not, by itself, mean the startup trained that model or meets the statutory definition of a frontier developer.

Now consider a company developing or materially modifying a foundation model. It should not reuse the first startup's conclusion simply because both products are sold as AI software. The compute definition, development activity, group revenue and New York connection need their own assessment.

This is an overview of the published rules, not a legal determination for a particular company. Application builders still have other privacy, security, contractual and sector-specific responsibilities. Being outside one developer-focused registration requirement is not a general exemption from AI-related law.

For an enterprise buyer, the practical implication is different again. It can ask a covered model supplier where its transparency report and safety framework will be published, and how material model changes will be communicated. Registration is not evidence that a model has been independently certified safe for the buyer's intended use.

Build an incident decision process before the deadline

Effective January 1, 2027, the law's reporting section generally requires a covered frontier developer to report a critical safety incident within 72 hours of determining that it occurred, or learning facts sufficient to establish a reasonable belief that it occurred. For an imminent risk of death or serious physical injury, subsection 3(b) specifies disclosure within 24 hours to an appropriate authority as required by law; the general 72-hour provision is expressly subject to that exception.

“Critical safety incident” is a defined category, not a synonym for every outage, inaccurate response or customer complaint. The definitions address specified serious harms and certain loss-of-control or deceptive behavior. An operational escalation process should route uncertain cases to the people who can assess those definitions promptly.

A useful preparation exercise is to trace a hypothetical alert from the engineer who sees it to the person authorized to make the reporting decision. Record which evidence is preserved, who owns the assessment, who covers that role outside working hours and when the relevant facts became known. This is practical preparation, not an additional checklist prescribed by the statute.

What the new research center does not change

The same announcement expands New York's AI safety research effort through the New York Center for AI Responsibility and Research at Binghamton University. Its planned work includes independent evaluation and reviewing published safety frameworks to inform policy.

That research initiative and the registration portal serve different purposes. The announcement does not turn a registration into a safety certification, nor should proposed future strengthening of the law be described as an obligation already in force.

The immediate work is to establish which obligations apply, assign owners and connect the required disclosures to the actual model-release process. A registration deadline can be handled as a filing task; ongoing transparency cannot. If the next model release changes the evidence but nobody updates the public report, completing the portal once will not solve the underlying problem.

I'm Paras. I work at the intersection of AI, engineering and distribution.

I help technical teams turn complex AI systems, safety work and product decisions into clear technical and executive stories.

Book a 30-minute call.