New York has opened its registration portal for large frontier AI developers, moving implementation of the RAISE Act into a practical preparation phase before January 1, 2027. According to the State University of New York, the state announced the opening on November 10 alongside a new independent AI research and testing initiative.
The immediate distinction for businesses is scope. This is not a registration requirement for every company using a chatbot. New York’s statute separates frontier model developers from the broader population of organizations buying or deploying AI-powered software.
Which developers the law covers
Section 1420 defines a frontier model by training computation exceeding 10 to the power of 26 integer or floating-point operations. The calculation includes the original training run and subsequent fine-tuning, reinforcement learning, or other material modifications applied by the developer.
A large frontier developer is a frontier developer whose annual gross revenue, together with affiliates, exceeded $500 million in the preceding calendar year. These definitions matter because the law assigns additional duties to the large-developer group rather than treating every model builder identically.
For readers assessing exposure, the sensible starting point is therefore the activity and model involved, not whether a product happens to carry an AI label. Companies should obtain legal advice on their specific circumstances rather than infer coverage from a headline.
Transparency goes beyond a registration form
Section 1421 requires large frontier developers to publish and follow a frontier AI framework covering catastrophic-risk assessment, mitigation, third-party evaluation, security for unreleased model weights, and internal governance. The framework must be reviewed at least annually. Material changes require publication and a justification within 30 days.
Frontier developers also face model transparency reporting at or before deployment of a new or substantially modified frontier model. Required information includes release timing, intended uses, supported languages and output types, and generally applicable restrictions. Larger developers must add summaries concerning risk assessments and mitigation work.
Registration consequently should not be mistaken for the entire compliance project. An organization may need coordinated work across engineering, security, legal, and communications teams to keep its published commitments consistent with what actually happens during development and deployment.
Incident reporting and independent testing
The statutory reporting provisions generally require notification within 72 hours after determining that a critical safety incident occurred, or learning sufficient facts to reasonably believe one occurred. Where an incident poses imminent risk of death or serious physical injury, the law specifies disclosure within 24 hours to an appropriate authority.
Separately, the state announced the New York Center for AI Responsibility and Research, based at Binghamton University. Its work will include independent testing and research, with more than 80 scientists participating across the state. The center can help inform government oversight, but its creation is not a blanket certification that participating or registered models are safe.
The next useful milestones are the January requirements and the evidence developers publish about their implementation. For users of AI products, that documentation could offer more concrete material for supplier review than general assurances about responsible development.
A practical preparation checklist
For a potentially covered developer, a useful internal exercise is to map each disclosure requirement to an accountable owner and an existing record. The goal is not to produce impressive language. It is to establish whether the company can substantiate what it says about evaluation, mitigation, and oversight when a release approaches.
Teams should distinguish a standing framework from a report about one particular model. A framework describes the process the organization intends to follow. A model-specific report describes the product and, where required, the relevant assessment work. Keeping the two connected can make inconsistencies easier to identify before publication.
An incident-reporting rehearsal is another sensible preparation step. Engineering and security teams can work through a hypothetical escalation with legal and executive reviewers, checking who collects the facts, who determines the applicable reporting route, and who can act if the usual decision-maker is unavailable. This is practical planning advice, not an additional requirement announced by the state.
What AI customers can ask suppliers
Organizations buying AI services have a different task. They can ask suppliers which model is being provided, whether relevant transparency documentation exists, and how updates or restrictions will be communicated. Those questions can support procurement without assuming the customer inherits the developer’s registration obligations.
Public documentation should be treated as evidence to examine, not a substitute for technical and contractual due diligence. A published framework can explain the intended process, but it does not by itself establish that every application built on a model is suitable for a particular use. The distinction will remain important as implementation moves from announcements to routine oversight.
