New York's RAISE Act: Obligations for Frontier AI Developers

New York's RAISE Act regulates developers of frontier-scale AI models — not the broader population of companies building or deploying AI agents on top of those models. It was signed into law in December 2025, chapter-amended in March 2026, and its obligations take effect on January 1, 2027; no duty under it is live today. Its core duties are publishing a safety framework and reporting qualifying incidents to the Attorney General and the Division of Homeland Security and Emergency Services (DHSES) within 72 hours; the numeric thresholds that trigger coverage exclude nearly every team working from a third-party model API. This post explains who the law actually reaches, what it asks of covered developers, and the control work that matters whether or not you meet the threshold.

For the wider landscape this law sits in, see US state AI laws compared, which lines RAISE up against Texas's TRAIGA, California's SB 53, and Colorado's amended AI Act.

What the RAISE Act regulates

The RAISE Act follows the same structural pattern as California's SB 53: it does not regulate "AI" in general, and it does not regulate deployers who build products on top of someone else's model. It regulates developers of frontier models — organizations that train models above defined compute, cost, and revenue thresholds.

That framing matters for scoping. Two axes decide whether the statute reaches your organization:

• Are you training the model, or calling someone else's API? If your product is an agent built on a commercial foundation model, you are a downstream user of that model, not its developer, for purposes of this statute.
• Do you cross the numeric thresholds? Frontier-developer statutes of this type define coverage by training compute, compute spend, and the developing company's revenue. The thresholds are set deliberately high, at a level only a small number of frontier labs currently reach.

If you are unsure which side of that line your organization sits on, the practical test is simple: are you training foundation models from scratch at large scale, or are you building applications, agents, or products that call a model someone else trained? Almost every engineering team building AI agents falls into the second category.

The obligations on covered developers

For organizations that do meet the thresholds, the RAISE Act imposes disclosure-style obligations rather than a general-purpose risk-management regime:

These obligations take effect on January 1, 2027, following the Act's December 2025 signature and March 2026 chapter amendment. Between now and then, treat the thresholds and mechanics as settled at the level described here, but verify current rulemaking status with counsel before finalizing a compliance program timed to the effective date — a state office retains authority to refine scope and definitions as it implements the statute.

Why this still matters if you are not a frontier developer

Most engineering teams building AI agents will not meet the RAISE Act's thresholds directly. That does not make the law irrelevant to your work, for three reasons.

First, your model vendor's compliance posture is now a procurement question. If the foundation model underneath your agent stack comes from a covered frontier developer, that developer's published safety framework and incident history are inputs you can reasonably ask about during vendor due diligence — the same way you would ask about a subprocessor's SOC 2 report today.

Second, the statute is a preview of the documentation shape regulators expect. Safety-framework publication and incident reporting are becoming the default vocabulary of AI regulation across states. Building the muscle to produce this kind of evidence internally — even voluntarily — puts you ahead of whichever state law eventually does reach your specific product.

Third, New York is not the last state to move. Watching how a frontier-developer statute like this one gets implemented, amended, and enforced is a reasonable proxy for what other states will draft next, particularly if New York's rulemaking office narrows or expands scope after the effective date.

The engineering control stack that applies regardless

Whether or not the RAISE Act reaches your organization directly, the underlying control stack that any frontier-AI or agent-AI statute eventually asks for is the same. Build it once and map it to whichever regime applies:

1. Data minimization before the prompt. Do not send more context to a model than the task requires. An agent answering a scheduling question does not need a customer's full financial history in its context window — trim inputs at the boundary, not after the fact.
2. PII and sensitive-data redaction. Inline inspection of prompts and tool outputs, so that personal or confidential data is caught before it reaches a model provider or a log store, not discovered afterward in an incident review.
3. Per-agent access scoping. Every agent should hold its own credential, scoped to the specific tools and data it needs, not a shared service account. This is what makes it possible to answer "what could this agent have touched" without guessing. See least privilege for AI agents for the implementation pattern.
4. Retention and erasure discipline. Define how long agent inputs, outputs, and logs are kept, and make sure that retention policy is enforced rather than aspirational.
5. A tamper-evident audit trail. Regulators and internal investigators both need to reconstruct what an agent did, when, on whose authority, and with what result. An editable application log does not satisfy that bar; see audit trails that hold up under regulatory scrutiny.
6. Incident-reporting evidence, ready before you need it. If a safety incident or a security incident occurs, you need to be able to answer "which agents were affected, what did they do, and when did we know" quickly. Building that query capability before an incident is materially cheaper than reconstructing it during one.
7. Human review of consequential agent actions. Any agent action with a material effect on a person or a business outcome should have a human review path attached, not just a log entry after the fact. See human-in-the-loop approvals for agents.
8. Vendor and third-party obligations. If you rely on a frontier model provider, your contract with them should specify what safety and incident information they will share with you, mirroring the developer-to-deployer documentation flow this style of statute expects.

Building the evidence trail before enforcement begins

The pattern across every AI statute passed in the US over the past two years — TRAIGA, SB 53, RAISE, Colorado's amended law — is the same: regulators want to see evidence of a working control program, not a policy document written to satisfy a single audit. An AI agent compliance checklist is a reasonable starting inventory exercise: which AI systems you run, which of them touch New York residents or effects, and which state or sectoral regime, if any, actually reaches each one.

Frontier-AI statutes also do not exist in isolation from broader AI governance work. If your organization already runs a program aligned to the NIST AI Risk Management Framework or is building toward EU AI Act readiness, extend that same evidence pipeline to cover RAISE Act exposure rather than standing up a parallel New York-specific process.

What good looks like

A team that has this right can answer each of the following without a scramble:

• Do we know, with the current statutory text in front of us, whether we meet the RAISE Act's developer thresholds — and have we written that determination down with a review date?
• If we do not meet the thresholds directly, do we know which of our model vendors might, and have we asked them for their safety-framework documentation?
• Can we produce, for any agent in production, the specific data it touched, the tools it invoked, and the human who authorized its deployment?
• Is there a human review step attached to every agent action with a consequential effect on a person or a financial outcome?
• Could we assemble an incident timeline for a specific agent within hours, not weeks, if asked?

This is not legal advice; confirm current requirements with counsel before making a compliance determination based on this post.

Common questions

Does the RAISE Act apply to companies outside New York? The trigger for this style of statute is typically tied to where the model's effects land and to the developer's own scale, not to where the company is headquartered. If a covered developer's model is used by New York residents, exposure can follow regardless of where the developer is based — but confirm the current jurisdictional scope with counsel, since this detail is exactly the kind of thing rulemaking can refine.

We fine-tune a third-party model — are we a "developer" under the statute? This is a genuinely fact-specific question that depends on the current statutory definitions and how much modification counts as "developing" a model versus using one. Do not assume either answer; get a specific read for your fine-tuning setup.

What should we do if we are not sure whether we are covered? Build the inventory first: what models you use, whether any are trained in-house at scale, and what your compute and revenue figures actually are relative to the published thresholds. That inventory is useful even if the answer is "not covered," because the same exercise feeds every other state and EU governance obligation you are likely to face. The AI governance guide covers the broader program this inventory work feeds into.

How does this compare to California's approach? Structurally similar — both target frontier-model developers with disclosure and incident-reporting duties rather than a broad deployer risk-management regime, and both include the kind of federal-deference thinking regulators are converging on. See US state AI laws compared for how the major state statutes line up side by side, and the EU AI Act explained for engineering teams for how the disclosure-and-incident-reporting pattern shows up outside the US as well.