On this page · 11 sections
- What changed in 2026: a chapter amendment replaced the original text
- Who is covered
- What every frontier developer must do
- Extra duties for large frontier developers
- Enforcement and the federal backdrop
- RAISE Act compared with California SB 53
- What downstream builders and enterprise buyers should do
- Worked example: the 72-hour clock and a first-year calendar
- Checklist before 1 January 2027
- How eCorpIT can help
- References
Summary. New York's Responsible AI Safety and Education (RAISE) Act, Article 44-B of the General Business Law, takes effect on 1 January 2027. The text that applies is S8828, signed on 27 March 2026 as chapter 96, which replaced the version signed in December 2025 to bring it closer to California's SB 53. The law covers frontier developers: anyone who trained, or began training, a foundation model using more than 10^26 integer or floating-point operations. Every frontier developer must publish a transparency report for each new or substantially modified frontier model and report critical safety incidents to DIGIT, an office inside the Department of Financial Services (DFS), within 72 hours, or within 24 hours to an appropriate authority where there is an imminent risk of death or serious injury. Large frontier developers, with revenue above $500 million including affiliates, must also publish a frontier AI framework, file quarterly internal-use risk summaries and hold a current disclosure statement with DIGIT from 1 January 2027. The Attorney General can seek up to $1 million for a first violation and $3 million for each later one. Few companies are covered directly, but buyers should update their vendor questions now.
About this article. This is for AI product, risk and legal teams at frontier labs, and for engineering and procurement teams that build on frontier models. We checked the enacted bill text, sponsor memo and votes on the New York Senate site, DFS's DIGIT guidance, California's official SB 53 materials and the federal executive order on 12 November 2026. It is general information, not legal advice; confirm your obligations with New York counsel. No vendor paid for inclusion. Researched with AI assistance and reviewed by our editorial team.
What changed in 2026: a chapter amendment replaced the original text
New York used a chapter amendment: the Governor signs a bill after negotiating changes that the Legislature then passes as a follow-up bill. The original RAISE Act (S6953-B and A6453-B) passed both houses in June 2025, and the Governor signed it on 19 December 2025 with approval memo 76. S8828 then repealed that Article 44-B and wrote a new one, and its sponsor memo says the negotiated changes align New York's law more closely with SB 53. The dates below come from the two bill pages and DFS.
| Date | Event |
|---|---|
| 12 June 2025 | S6953-B passes the Senate and the Assembly |
| 19 December 2025 | Governor signs chapter 699 with approval memo 76 |
| 8 January 2026 | S8828 introduced by Senator Gounardes |
| 28 January 2026 | Senate passes S8828, 58 to 1 |
| 25 February 2026 | Assembly substitutes S8828 for its own bill, A9449 |
| 11 March 2026 | Assembly passes S8828 |
| 27 March 2026 | Governor signs S8828 as chapter 96 |
| 21 September 2026 | Governor says registration starts in November and names a RAISE Act deputy director at DIGIT |
| 1 January 2027 | Article 44-B takes effect; large frontier developers need a current disclosure statement |
| 1 January 2028 | Statutory start of DIGIT's annual report; DFS lists 2 January 2028 for the first one |
Why some summaries are out of date. Commentary on the December 2025 text uses different numbers. S6953-B set penalties of up to $10 million for a first violation and $30 million for later ones, and defined critical harm as 100 or more deaths or serious injuries. A February 2026 law-firm note repeated those older figures. The text now in force uses more than 50 deaths or serious injuries, or more than $1 billion in property damage from a single incident, and caps Attorney General penalties at $1 million for a first violation and $3 million for each later one. If a vendor memo quotes the old figures, ask which text it used.
Who is covered
Four definitions in section 1420 decide scope.
- Foundation model: an AI model trained on a broad data set, designed for generality of output and adaptable to a wide range of distinctive tasks.
- Frontier model: a foundation model trained using more than 10^26 integer or floating-point operations. The count includes the original training run and any later fine-tuning, reinforcement learning or other material modifications the developer applies to a preceding foundation model.
- Frontier developer: a person who has trained, or initiated the training of, a frontier model and has used, or intends to use, at least that much computing power to train it.
- Large frontier developer: a frontier developer that, with its affiliates, had annual gross revenues above $500 million in the preceding calendar year.
The article applies only to frontier models developed, deployed or operating in whole or in part in New York State. It does not apply to accredited New York colleges and universities doing academic research on AI models, or to the Empire AI consortium.
The fine-tuning question for downstream builders. Because the compute count includes fine-tuning applied to a preceding foundation model, a company that fine-tunes an open-weight model whose original training exceeded 10^26 operations may ask whether it has become a frontier developer. The frontier developer definition points to the narrower answer: it ties status to compute the person itself has used or intends to use, which DFS's own summary repeats. On that reading, a fine-tune using 10^22 operations (one ten-thousandth of the threshold) does not make you a frontier developer. The text does not say so in terms, though, and DIGIT has rulemaking power under section 1429 but had published no rule as of 12 November 2026. Keep a training-compute ledger for every fine-tune, recording the base model and its published training compute, and get counsel's view before deploying a heavily modified open-weight frontier model in New York.
| You are | Directly covered? | What applies from 1 January 2027 |
|---|---|---|
| A lab that trained a model above 10^26 operations, revenue over $500 million | Yes, large frontier developer | Framework, transparency reports with risk summaries, 72-hour reports, quarterly summaries, disclosure statement and assessments |
| A lab that trained a model above 10^26 operations, revenue under $500 million | Yes, frontier developer | Transparency reports, 72-hour incident reports, no misleading statements about catastrophic risk |
| A company fine-tuning or serving an open-weight frontier model with far less compute | Probably not, but unsettled | Compute ledger, legal view, incident triage ready |
| An enterprise using frontier models through an API | No | Vendor due diligence and contract terms |
| A university lab doing academic research in New York | Excluded | None under Article 44-B |
What every frontier developer must do
Transparency report. Before or at the same time as deploying a new frontier model, or a substantially modified version of one, the developer must publish on its website a report giving its website, a way for a person to contact it, the model's release date, supported languages, output modalities, intended uses and any general restrictions or conditions on use. Publishing this inside a larger system card or model card counts.
Critical safety incident reports. A frontier developer must report a critical safety incident to the Office within 72 hours of determining that one occurred, or within 72 hours of learning facts sufficient for a reasonable belief that one occurred. If the incident poses an imminent risk of death or serious physical injury, it must be disclosed within 24 hours to an appropriate authority, such as a law enforcement or public safety agency. Amended reports are allowed as facts emerge. DFS says reports go through the RAISE Portal, which needs an NY.gov ID, and it urges smaller frontier developers to open accounts early. A report asks for the date and a description, why the event qualifies, whether it involved internal use, whether 24-hour notice went to another authority, and the model name and version.
A critical safety incident is narrower than an outage or a bad output. The statute lists four types:
- Unauthorised access to, modification of or exfiltration of frontier model weights that results in death or bodily injury.
- Harm resulting from a catastrophic risk materialising.
- Loss of control of a frontier model causing death or bodily injury.
- A frontier model using deceptive techniques against its developer to subvert controls or monitoring, outside an evaluation designed to elicit that behaviour, in a way that shows materially increased catastrophic risk.
Catastrophic risk means a foreseeable and material risk that a frontier model will materially contribute to the death of, or serious injury to, more than 50 people, or more than $1 billion in property damage, from a single incident in which the model gives expert-level help with chemical, biological, radiological or nuclear weapons; carries out, without meaningful human oversight, a cyberattack or conduct that would be murder, assault, extortion or theft if done by a person; or evades its developer's or user's control. Publicly available information in similar form, lawful federal government activity and harm the model did not materially contribute to are excluded, and a fall in equity value does not count as property loss. DFS states plainly that these incidents do not cover all AI errors, malfunctions or consumer complaints.
Honesty duty. A frontier developer must not make materially false or misleading statements about catastrophic risk from its frontier models or its management of that risk. A large frontier developer also must not misstate how it implements or complies with its framework. Statements made in good faith that were reasonable at the time are exempt.
Redactions. Published documents may be redacted to protect trade secrets, cybersecurity, public safety or national security, or to comply with law. The developer must describe the character of and reason for each redaction and keep the unredacted information for five years.
Extra duties for large frontier developers
Frontier AI framework. A large frontier developer must write, follow and publish a framework describing how it handles ten areas: national and international standards; capability thresholds; mitigations; reviewing assessments before deployment or extensive internal use; third-party assessors; updating the framework; securing unreleased model weights; identifying and responding to critical safety incidents; internal governance; and risk from internal use, including a model circumventing oversight. It must review the framework at least once a year and publish any material change, with a justification, within 30 days.
Enhanced transparency reports. Its transparency reports must also summarise catastrophic-risk assessments, their results, how far third-party evaluators were involved, and other steps taken under the framework.
Quarterly internal-use summaries. Every three months, or on another schedule agreed with the Office, it must send DIGIT a summary of any assessment of catastrophic risk from internal use of its frontier models. DFS says these are due through the RAISE Portal within 30 days of the end of each calendar quarter. They are exempt from disclosure under New York's freedom of information law.
Disclosure statement and assessments. Under section 1428, a large frontier developer may not develop, deploy or operate a frontier model in New York without a current disclosure statement on file and its share of DIGIT's costs paid. The statement names the company and its trade names, its principal and New York addresses, owners of 5% or more for private companies (50% or more for public ones) plus former 5% owners over five years, and three points of contact. It must be renewed every two years, on transfer of model ownership or after a material change, whichever comes first, and the Office will publish a list of filers without contact details. DFS's September announcement said it would start directing large developers to register from November, and its guidance now sets out the RAISE Portal account and registration steps.
Enforcement and the federal backdrop
Section 1427 lets the Attorney General sue for up to $1 million for a first violation and up to $3 million for each later violation, scaled to severity, where a large frontier developer fails to publish or transmit a compliant document, makes a prohibited statement, fails to report an incident or fails to follow its own framework. As written, that clause names large frontier developers; how it reaches smaller frontier developers' incident duties is a question for counsel. Separately, the Office may, after notice and a hearing, impose $1,000 for each day a developer fails to file a disclosure statement or correct false information in one, plus the assessments owed. There is no private right of action.
The Office may also designate federal laws, regulations or guidance with incident-reporting standards at least as strict as New York's. A developer that declares it will follow a designated federal standard is treated as meeting the 72-hour rule to that extent, but must copy its federal incident reports to the Office. No designation or other DIGIT rule appeared on the DFS regulations page as of 12 November 2026.
On the federal side, Executive Order 14365 of 11 December 2025 told the Attorney General to set up an AI Litigation Task Force to challenge state AI laws that conflict with federal policy. A February 2026 analysis found no public sign that the task force had targeted a specific state statute. In the sources we checked, we found no filed federal challenge to the RAISE Act as of 12 November 2026. The Governor's September announcement said she is exploring ways to build on the law, so further amendments are possible in the 2027 session.
RAISE Act compared with California SB 53
California's Transparency in Frontier Artificial Intelligence Act (SB 53) was signed on 29 September 2025, and a July 2026 law-firm summary reports that it has applied since 1 January 2026. It uses the same compute and revenue thresholds, and its incident reports go to the Office of Emergency Services within 15 days of discovery. Penalties are capped at $1 million per violation. The table summarises these sources and the New York text.
| Item | New York RAISE Act (from 1 January 2027) | California SB 53 (since 1 January 2026) |
|---|---|---|
| Frontier model threshold | More than 10^26 operations, including later fine-tuning and modifications | More than 10^26 operations, including later fine-tuning and modifications |
| Large developer threshold | Over $500 million revenue with affiliates | Over $500 million revenue with affiliates |
| Incident report deadline | 72 hours from determination or reasonable belief | 15 days from discovery |
| Imminent risk of death or serious injury | 24 hours to an appropriate authority | 24 hours to an appropriate authority |
| Receiving body | DIGIT within DFS, via the RAISE Portal | Office of Emergency Services portal |
| Internal-use risk summaries | Every three months, within 30 days of quarter end per DFS | Every three months or another reasonable schedule |
| Registration and fees | Disclosure statement and pro rata assessments | No equivalent registration |
| Civil penalties | Up to $1 million first violation, $3 million each later one | Up to $1 million per violation |
| Enforcer | Attorney General; DIGIT for disclosure-statement penalties | Attorney General |
| Public annual report | DIGIT, from 1 January 2028 | Office of Emergency Services, from 1 January 2027 |
For a lab that already meets SB 53, the New York work is mostly operational: compress incident triage from a 15-day to a 72-hour clock, register with DIGIT and budget for assessments. California's separate AI Transparency Act is a different law with its own 2027 dates, covered in our California AI Transparency Act explainer. Labs that also sell into Europe should add our EU AI Act checklist for older general-purpose models.
What downstream builders and enterprise buyers should do
The law puts no direct duty on a company that only calls a frontier model through an API. It also does not require a frontier developer to tell its customers about an incident; reports go to the state, which may pass them to other agencies. If you build products on frontier models, close that gap by contract.
| Ask your model vendor | Why it matters |
|---|---|
| Is this model a frontier model under New York and California law? | Tells you whether its transparency report and incident duties apply |
| Where are your frontier AI framework and the transparency report or system card for this version? | Both must be published; use them in your own risk assessment |
| Have you filed a disclosure statement with DIGIT? | Large developers cannot operate in New York without one from 1 January 2027 |
| Will you tell us about a critical safety incident affecting our deployment, and how fast? | The statute requires reports to the state, not to customers |
| Have you declared a federal-equivalence route for incident reporting? | Changes where and how incident reports are filed |
| How will you tell us about substantial modifications to the model? | Each substantially modified version needs a new transparency report |
Internally, map your incident categories to the four statutory types so on-call staff know when a vendor-model problem might be reportable by the vendor, and keep logs that would help it investigate. Fold these checks into your wider AI agent governance layers rather than running them as a one-off. If you run or fine-tune open-weight models at scale, add the compute ledger described above.
Worked example: the 72-hour clock and a first-year calendar
A large frontier developer's safety team determines at 4.30 pm Eastern on Friday 15 January 2027 that a critical safety incident has occurred.
- 72-hour report to DIGIT: due by 4.30 pm on Monday 18 January 2027. That Monday is Martin Luther King Jr. Day; the statute counts hours, not business days, so the holiday does not pause the clock.
- 24-hour disclosure if there is imminent risk of death or serious injury: due to the appropriate authority by 4.30 pm on Saturday 16 January 2027.
- Quarterly internal-use summaries, assuming quarters run from 1 January 2027: 30 April, 30 July and 30 October 2027, and 30 January 2028, each 30 days after a quarter ends. 30 October 2027 is a Saturday and 30 January 2028 a Sunday, and DFS has not said whether weekend dates roll forward, so file early.
- Disclosure statement renewal: within two years of filing, sooner on an ownership transfer or material change, so a December 2026 filing renews by December 2028.
Penalty arithmetic. If the Attorney General proved one first violation and two later violations at the maximum, exposure would be $1 million + 2 × $3 million = $7 million. A disclosure statement left unfiled for 45 days would add 45 × $1,000 = $45,000, plus the assessments owed. Actual penalties depend on severity and are set by a court or, for disclosure statements, after an Office hearing.
Checklist before 1 January 2027
There are 50 days from 12 November 2026 to the start date. For other laws landing the same day, see our 2027 compliance calendar for software teams.
For frontier developers:
- Confirm frontier and large frontier developer status for each model and legal entity, including affiliates' revenue.
- Create NY.gov ID and RAISE Portal accounts, and file the disclosure statement if you are a large frontier developer.
- Write a 72-hour incident runbook with named owners, plus a 24-hour law-enforcement path.
- Check that each deployed model's system card contains the seven transparency-report items.
- Reconcile your frontier AI framework against the ten statutory areas and schedule the annual review.
- Set the quarterly internal-use summary calendar and the 30-day framework-change publication rule.
- Keep redaction logs with justifications and five-year retention of unredacted text.
For enterprise buyers and builders:
- List every frontier model you use and its vendor.
- Send the vendor questions above and add incident-notification terms to renewals.
- Map internal incident categories to the four statutory types.
- Keep a training-compute ledger for any fine-tuning of open-weight frontier models.
How eCorpIT can help
eCorpIT is a Gurugram-based technology organisation, founded in 2021, assessed at CMMI Level 5 and MSME certified, with senior-led engineering teams working across AWS, Microsoft and Google platforms. Our AI and machine learning services team builds incident triage runbooks, evidence-preserving logging and evaluation pipelines, and training-compute ledgers that your counsel can map to RAISE Act and SB 53 duties. Talk to us at /contact-us/.
Last updated: 12 November 2026.
