The New York RAISE Act: A Reference for Boards and Compliance Teams

Overview

The New York Responsible AI Safety and Education Act is the first US state law to impose comprehensive safety, transparency, testing, and incident-reporting obligations on developers of frontier artificial-intelligence models. Practitioners refer to it as the "RAISE Act." It takes effect on January 1, 2027.

The Act has a two-step enactment history. Governor Kathy Hochul originally signed Senate Bill 2025-S6953-A and Assembly Bill 2025-A6453-A on December 19, 2025, then signed a chapter amendment (S6953-B / A6453-B) on March 27, 2026 that became the Act's operative form. The chapter amendment narrowed the incident-reporting trigger from a broader "safety incident" to a tighter "critical safety incident" tied to materialization of catastrophic risk, death, or bodily injury; added a 24-hour escalation requirement for events posing imminent risk of death or serious physical injury; and aligned several definitional thresholds more closely with California SB 53. This reference treats the operative S6953-B / A6453-B form throughout. Where obligations differ between the A and B versions, the B version controls.

For boards and compliance teams, the Act is significant for three reasons. First, it establishes the first state-level statutory architecture for what "responsible frontier AI development" looks like in operational terms: a written safety and security framework, redacted public disclosure of that framework, submission of the unredacted version to the state, a 72-hour critical-safety-incident reporting obligation, an annual independent audit, and rulemaking authority in the New York Department of Financial Services. Second, the coverage threshold is narrow — the directly regulated population is a handful of frontier-AI developers with $500 million or more in annual revenue and frontier models trained with more than 10²⁶ floating-point operations — but the indirect effects on deployers, vendor due diligence, D&O underwriting, and multi-jurisdictional compliance planning are broad. Third, Executive Order 14365 — issued December 11, 2025 and titled "Ensuring a National Policy Framework for Artificial Intelligence" — directs the Department of Justice (through an AI Litigation Task Force established January 9, 2026), the Federal Trade Commission, and other federal agencies to challenge state AI laws of this character. The RAISE Act remains enforceable in the absence of a federal injunction, but the preemption trajectory is now part of the planning calculus.

This reference is for US boards, audit committees, GCs, and CCOs. It covers the Act's coverage thresholds, the substantive obligations, the incident-reporting regime, civil penalties, the DFS rulemaking authority, the federal-preemption posture, the indirect effects on companies that are not directly regulated, and practical compliance steps for 2026.

Who the RAISE Act covers

Direct coverage under the RAISE Act is narrower than the practitioner press sometimes implies. Three conditions must be satisfied concurrently. A company is a "large developer" subject to the Act if it (1) has annual revenue of $500 million or more, (2) develops or operates a "frontier model," and (3) does so in New York. The "in New York" prong is read functionally: development, operation, or commercial offering with a substantial New York nexus, not merely incidental contact.

The "frontier model" threshold

A "frontier model" under the Act is an AI model trained using greater than 10²⁶ floating-point operations of compute, with training compute costs exceeding $100 million. Both thresholds must be met. The compute-operations threshold (10²⁶ FLOPs) is the same threshold the EU AI Act uses to designate GPAI models with systemic risk plus one order of magnitude — the EU's threshold is 10²⁵ FLOPs — meaning the RAISE Act is calibrated to a tighter population than the EU's already-narrow systemic-risk tier. The additional $100 million compute-cost threshold further narrows coverage to a population that, as of May 2026, consists of perhaps a dozen developers worldwide and a smaller subset operating in New York.

The $500 million revenue threshold

The revenue threshold excludes university research labs, well-funded startups operating below $500 million in annual revenue, and most non-frontier AI companies even when their technical work touches frontier-scale compute. The threshold is annual revenue, not annual AI revenue, so a diversified company with $500 million in non-AI revenue would meet the threshold if it also develops a frontier model meeting the other criteria.

Why the threshold matters more than the headline coverage

The narrow direct-coverage population produces a misleading impression that the Act is "for a handful of companies." The correct read is that the RAISE Act regulates the upstream layer of the AI value chain — the developers of the foundational frontier models on which thousands of downstream AI products are built — and that downstream effects on vendor due diligence, contract terms, and disclosure norms will reach a much larger population. The "Why it matters" section below treats those downstream effects in detail.

The frontier AI safety framework

Large developers in scope of the Act must implement a written safety and security framework — described in practitioner parlance as the "frontier AI framework" — and operate against it. The Act enumerates several substantive elements the framework must contain and several documentary and submission obligations.

The substantive elements

The framework must address the developer's processes for: assessing the risk of critical harm arising from the frontier model; implementing technical and administrative controls to mitigate those risks; testing the model to verify the controls operate as intended; protecting the model's weights against unauthorized access, theft, and exfiltration; responding to safety incidents; and integrating the framework into the developer's overall governance and management systems.

The Act does not prescribe a particular standards framework. In practice, developers will build the substantive elements from a combination of the NIST AI Risk Management Framework, ISO/IEC 42001 (AI management systems), ISO/IEC 23894 (AI risk management guidance), and the developer's own existing safety practice. For developers that have already implemented EU AI Act systemic-risk obligations or California SB 53 transparency obligations, much of the substantive content of the RAISE Act framework will already exist.

The documentary obligations

A large developer must retain an unredacted copy of its framework and publish a redacted copy. The redaction is for trade-secret, cybersecurity, and national-security purposes; the public-facing version must be substantive enough to be informative. The unredacted version must be transmitted to the New York Attorney General and to the Division of Homeland Security and Emergency Services, and access must be granted to those authorities on request.

The developer must record and maintain information about the tests it has run and the test results it has obtained in assessing the frontier model's safety and security. These records must be retained and produced to authorities on request.

Annual review

The framework must be reviewed at least annually, with the review addressing whether the substantive controls remain adequate to the risks the model presents and whether modifications are required. The annual-review obligation is procedural, not merely documentary: it requires the developer to actually reassess and, where necessary, update the framework.

Incident reporting: 72 hours and 24 hours

The operative S6953-B / A6453-B form of the RAISE Act establishes a two-track incident-reporting regime: a 72-hour reporting obligation for "critical safety incidents," and a separate 24-hour escalation obligation for events posing imminent risk of death or serious physical injury.

The 72-hour critical-safety-incident report

Large developers must report a critical safety incident to the DFS oversight office within 72 hours from the earlier of (a) the developer's determination that a critical safety incident has occurred, or (b) the developer's learning facts sufficient to establish a reasonable belief that one has occurred. The operative trigger is not the underlying incident itself but the developer's epistemic position with respect to it.

The definition of "critical safety incident"

The chapter amendment replaced the original "safety incident" definition — which captured a broader set of operational events including control failures and unauthorized use — with a tighter "critical safety incident" definition keyed to actual harm or materialization of catastrophic risk. Under the operative definition, a critical safety incident is any of the following:

1. unauthorized access to, modification of, or exfiltration of the model weights of a frontier model that results in death or bodily injury;
2. harm resulting from the materialization of a catastrophic risk;
3. loss of control of a frontier model causing death or bodily injury; or
4. a frontier model that uses deceptive techniques against the frontier developer to subvert the controls or monitoring of its developer outside of the context of an evaluation designed to elicit this behavior and in a manner that demonstrates materially increased catastrophic risk.

Two consequences follow from the narrower definition. First, routine operational incidents — model-weight access events that do not result in death or bodily injury, control failures that are caught and contained without harm, ordinary unauthorized uses — fall outside the statutory reporting trigger, though sophisticated developers will still log them in internal incident-management systems. Second, the threshold for reporting is now keyed to the developer's understanding of consequence and causation, not merely to the existence of an operational anomaly. Compliance teams should build the incident-triage process around the new definition and document the determinations that reportable thresholds were or were not met.

The "critical harm" predicate

The "catastrophic risk" referenced in triggers (b) and (d) is operationalized through the Act's separate definition of "critical harm" — the conceptual baseline against which catastrophic risk is measured. Critical harm under the Act is death or serious injury of one hundred or more people, or at least one billion dollars in property damage, caused or materially enabled by a large developer's use, storage, or release of a frontier model. The definition explicitly extends to harm enabled by (i) the creation or use of a chemical, biological, radiological, or nuclear weapon, or (ii) a frontier model engaging in criminal conduct without meaningful human interaction where the crime requires intent, recklessness, or gross negligence, including solicitation or aiding and abetting of such a crime. The "critical harm" predicate sets the substantive risk scale the Act is designed to capture.

The 24-hour imminent-risk escalation

Separately from the 72-hour DFS reporting obligation, a frontier developer that discovers a critical safety incident posing an imminent risk of death or serious physical injury must disclose that risk within 24 hours to an appropriate law enforcement or public safety agency with jurisdiction. The 24-hour clock is the operative timeline for the most consequential incident scenarios. Compliance teams should pre-identify the appropriate jurisdictional contact points and incorporate the 24-hour escalation into incident-response playbooks.

Annual third-party audit

Large developers must retain an independent third party to conduct an annual audit of the developer's safety and security framework. The auditor produces an audit report; the developer must retain the report, publish it with appropriate redactions, and submit it to the Division of Homeland Security and Emergency Services.

As of May 2026, the population of qualified independent auditors for frontier AI safety frameworks is small. Existing AI assurance practice — much of which uses ISO/IEC 42001 audit protocols, the NIST AI RMF generative-AI profile, and practitioner-developed safety-evaluation methodologies — is the natural starting point, but the third-party audit market for frontier AI is still maturing. Compliance teams should expect procurement of qualified auditors to be a constraint during the first audit cycle and should begin scoping the engagement well in advance of the first audit deadline.

Civil penalties and enforcement

The Act establishes a bifurcated penalty structure.

Attorney General enforcement

The New York Attorney General enforces the substantive frontier AI framework obligations and the incident-reporting obligations. A large developer that violates these obligations — or that fails to comply with its own published framework — faces civil penalties of up to $1 million for a first violation and up to $3 million for each subsequent violation.

DFS oversight office enforcement

A separate civil penalty applies to failures of administrative compliance: failure to file a required disclosure statement, failure to pay an assessment fee imposed by the DFS oversight office, or filing a disclosure statement containing false information. The penalty for these failures is $1,000 per day of non-compliance plus the amount of any assessments owed, levied by the DFS oversight office after notice and hearing.

Practical posture

Penalties at $1 million to $3 million per violation are not material to the balance sheets of the frontier-AI developers in scope. The enforcement risk that matters is collateral: a public enforcement action by the New York Attorney General against a covered developer would attract immediate D&O securities litigation risk, regulator scrutiny in adjacent jurisdictions (the EU AI Office, California's regulators under SB 53), and pressure on enterprise customer relationships. The penalty exposure is best understood as the trigger for a cascade of secondary consequences, not as the principal sanction.

DFS rulemaking authority

The Act creates a new oversight office within the New York Department of Financial Services with rulemaking authority over the implementation of the Act's provisions. The office is authorized to adopt rules and regulations, including additional reporting or publication requirements beyond those set out in the statute.

As of May 2026, the DFS office has not yet issued substantive rulemaking. The shape of the implementing regulations — including the granularity of framework-content requirements, the form and detail of incident reports, the scope of permissible redactions, and the qualifications expected of third-party auditors — will materially affect what compliance against the Act actually requires. Compliance teams should monitor DFS rulemaking publications through 2026 and structure their compliance build to be adaptable to the substantive contours that emerge.

The DFS office is also responsible for receiving incident reports, maintaining a list of covered developers, and issuing annual reports on AI safety risks. The annual-report obligation produces a public-record artifact that adjacent regulators (EU AI Office, California regulators) and litigants will read closely.

Federal preemption and the litigation outlook

The RAISE Act was the first state AI safety law to be signed after Executive Order 14365, "Ensuring a National Policy Framework for Artificial Intelligence," issued December 11, 2025. The Executive Order directs the Attorney General to establish an AI Litigation Task Force within the Department of Justice (established January 9, 2026) as the primary vehicle for challenging state AI laws in federal court, and instructs the Federal Trade Commission, the Federal Communications Commission, the Department of Commerce, and other federal agencies to coordinate on related actions. The state-law challenge program targets laws that, in the Administration's view, interfere with interstate commerce, are preempted by federal regulation, or violate constitutional provisions including the First Amendment. The Executive Order also conditions $42 billion in previously appropriated Broadband Equity, Access, and Deployment program funding on states' repeal of AI regulations the Department of Commerce deems onerous; the Colorado AI Act is singled out by name as a target.

Commentators have identified three principal theories the federal government is expected to pursue against state laws of the RAISE Act type:

• Compelled speech. State safety-framework publication and disclosure obligations may be challenged as forms of compelled speech under the First Amendment, on the theory that they require developers to make affirmative statements about their models' risks and capabilities in government-mandated form.
• Dormant Commerce Clause. A patchwork of state AI laws may be challenged as unduly burdening interstate commerce, on the theory that a developer cannot comply with varying state requirements without effectively having to apply the most stringent state's rules to its entire operation.
• Truthful-output theory. The Executive Order directs the FTC to investigate whether state laws governing AI bias or disparate impact force AI models to produce "false results" to avoid liability — a theory more squarely directed at laws like the Colorado AI Act than at the RAISE Act, but potentially relevant where the RAISE Act's framework requirements touch on bias-mitigation processes.

None of these theories has been tested in court against the RAISE Act specifically as of May 2026. The Act remains legally enforceable unless and until a federal court issues a preliminary injunction or final judgment against it; preemption litigation of this character typically takes years to reach a final determination, and even a successful federal challenge may invalidate only specific provisions rather than the Act in its entirety.

The strategic implication for boards: plan for the January 1, 2027 effective date as the binding deadline. The federal-EO challenge is real but is unlikely to produce relief before that date, and an organization that bets compliance work on federal preemption arriving in time will likely find itself out-of-position when the deadline lands.

Why the RAISE Act matters to companies that are not directly covered

Most companies are not large developers under the RAISE Act and will not be directly subject to its obligations. The Act nevertheless reaches a much broader population through four channels.

Vendor due diligence on covered frontier models

Companies that deploy frontier AI from covered developers will increasingly find vendor questionnaires, contracts, and audit rights tracking the RAISE Act's disclosure structure. The redacted framework each covered developer publishes will become part of the public record on which deployers conduct vendor diligence; the developer's incident-reporting history with the New York Attorney General will be a reference point that sophisticated enterprise customers will look to. Deployers in regulated industries — financial services, healthcare, insurance — should expect their own regulators to begin asking about the RAISE Act posture of the frontier models they deploy. Updating vendor questionnaires now to capture RAISE Act coverage status, published framework references, and incident-reporting commitments is the appropriate response.

Multi-jurisdictional convergence

The substantive content of the RAISE Act framework overlaps significantly with parallel requirements under the EU AI Act GPAI systemic-risk obligations, California SB 53's transparency requirements, and the safety-and-security obligations emerging in other jurisdictions. Companies operating multi-jurisdictionally should treat the RAISE Act as one input to a unified frontier-AI compliance program rather than as a standalone compliance project. The companion reference on multi-jurisdictional AI compliance treats the convergence pattern in detail.

D&O underwriting implications

For directors of frontier-AI developers — and for directors of companies with material AI exposure operating in New York — the RAISE Act is rapidly becoming a question on D&O renewal questionnaires. The 2026 renewal cycle is the first cycle in which carriers can plausibly ask "what is your company's posture on the RAISE Act?" and expect a substantive answer. Directors at NY-headquartered companies with AI exposure should anticipate carrier interest and prepare documentation supporting the company's coverage analysis and (if covered) its framework build plan in advance of the renewal conversation. The companion briefing on AI governance and D&O liability treats the broader renewal-cycle dynamics.

Board-level oversight expectations

The Caremark duty of oversight, as applied to mission-critical risks after Marchand v. Barnhill, attaches the board's monitoring obligation to risks that are central to the enterprise's operations and that are subject to specific regulatory regimes. For frontier-AI developers in scope of the RAISE Act, the Act materially raises the floor of what documented board-level oversight of AI risk looks like. For deployers, the Act produces public information about specific risks of specific frontier models that boards are now on notice of — which feeds into the deployer's own Caremark posture under the prevailing oversight doctrine.

Interaction with other frameworks

The RAISE Act does not occupy a regulatory field; it stacks on top of and interacts with several existing regimes.

EU AI Act GPAI systemic-risk obligations

The EU AI Act's GPAI provisions, in force since August 2025, impose obligations on providers of general-purpose AI models with systemic risk — defined as GPAI models trained using more than 10²⁵ FLOPs. The substantive content overlaps materially with the RAISE Act framework requirements: risk assessment, controls testing, incident response, model-weight protection, transparency. The EU's threshold is broader (10²⁵ FLOPs vs. the RAISE Act's 10²⁶ FLOPs), but the RAISE Act adds a $500 million revenue threshold the EU does not use. Most developers in scope of the RAISE Act will be in scope of the EU GPAI systemic-risk regime; building a unified framework that satisfies both is the appropriate posture.

California SB 53

California SB 53 — the Transparency in Frontier Artificial Intelligence Act, signed by Governor Newsom on September 29, 2025 — establishes transparency obligations for developers of frontier models under a California-specific definition, including publication of safety practices, incident reporting, and whistleblower protections. The RAISE Act and SB 53 cover overlapping populations of developers and overlapping substantive ground; the March 27, 2026 chapter amendment to the RAISE Act aligned several definitions and the incident-reporting trigger more closely with SB 53. The RAISE Act still goes further than SB 53 on framework specificity and the annual third-party audit. Developers in scope of both will design a unified compliance posture rather than parallel programs.

NIST AI RMF and ISO/IEC 42001

The NIST AI Risk Management Framework (AI RMF 1.0, published January 2023, with a Generative AI Profile released July 2024) and ISO/IEC 42001 (AI management systems, published December 2023) are the two most widely used standards baselines from which a RAISE Act-compliant framework would be built. Neither standard is statutorily required by the RAISE Act, but both produce documentation, control structures, and audit-readiness that a well-designed RAISE Act framework will rely on. ISO/IEC 23894 (AI risk management guidance) is also a relevant input. Companies operating across the EU AI Act, the RAISE Act, and US federal sectoral expectations will typically build the substantive framework against NIST AI RMF and ISO/IEC 42001 as the underlying standards, then map the resulting documentation to each regulatory regime's specific requirements.

Colorado AI Act, NYC Local Law 144, Illinois HB 3773

These laws regulate downstream AI deployment in specific contexts — consequential decisions (Colorado), automated employment decision tools (NYC), employment-context AI (Illinois) — rather than frontier-model development. They share with the RAISE Act a common direction of travel toward documented, transparent AI governance, but they do not impose framework, audit, or incident-reporting obligations of the RAISE Act type. The multi-jurisdictional convergence point is documentation: a company building a defensible posture against the Colorado AI Act, NYC Local Law 144, or Illinois HB 3773 is producing documentation that, while not RAISE Act compliance, supports the deployer-side vendor diligence that the RAISE Act effectively requires of frontier-AI customers.

Practical compliance steps for 2026

The recommended posture depends on whether the organization is directly covered, indirectly affected through vendor relationships, or operating in New York with material AI exposure.

For directly covered large developers

1. Confirm coverage analysis. The $500 million revenue and 10²⁶ FLOPs / $100 million compute-cost thresholds should be assessed against the developer's specific frontier model program. Document the coverage analysis; if coverage is borderline, the analysis itself becomes a piece of compliance documentation that the New York Attorney General may eventually request.
2. Build the framework against NIST AI RMF and ISO/IEC 42001 as underlying standards. The framework should be substantive enough to be auditable and structured to map cleanly to the EU AI Act GPAI systemic-risk obligations and California SB 53 requirements. Producing one framework that satisfies all is the operative goal.
3. Establish the incident-determination process. The 72-hour clock starts at determination, not at the underlying event. A clearly defined incident-triage process — with named roles, decision criteria, escalation paths, and a documented record of determinations — is the operational predicate for reliable 72-hour reporting. The process should be tested through tabletop exercises before the effective date.
4. Scope the third-party audit engagement. The independent-auditor market for frontier AI is small. Engage well in advance, develop a clear audit scope referencing the framework's substantive elements, and budget for the audit as a recurring annual obligation.
5. Track DFS rulemaking. Substantive rulemaking from the DFS oversight office will materially affect what compliance requires in operational detail. Monitor publications through 2026 and structure the framework build to absorb the rule contours as they emerge.
6. Coordinate with the EU AI Office and California regulators. Developers in scope of multiple regimes should treat regulatory engagement as coordinated rather than siloed. Inconsistencies in disclosures across jurisdictions are themselves a compliance and litigation risk.

For indirectly affected deployers

1. Update vendor due diligence. Add to AI vendor questionnaires: (a) Is the vendor a large developer in scope of the RAISE Act? (b) Has the vendor published its redacted framework? Where? (c) What is the vendor's incident-reporting history with the New York Attorney General? (d) What audit reports has the vendor published, and can the deployer receive them under NDA?
2. Update contract terms. Vendor contracts with covered frontier-AI developers should reflect the developer's compliance status, incident-disclosure commitments to the deployer (parallel to or in addition to statutory disclosure to New York), and audit-rights provisions.
3. Brief the audit committee. The RAISE Act is now part of the AI risk environment that audit committees of deployer companies should understand at a working level, even if the company is not directly regulated. The companion briefing on AI governance and D&O liability provides the board-level framing.

For New York-headquartered companies with material AI exposure

1. Pre-renewal D&O conversation. Discuss RAISE Act posture with the D&O broker 90–180 days before the next renewal. Whether the company is directly covered or indirectly affected, the carrier conversation will go better with documentation in hand.
2. Engage outside counsel on coverage analysis. Borderline coverage — particularly the "in New York" prong — is a legal-judgment question that warrants formal outside counsel involvement. The coverage analysis itself, properly papered, becomes a piece of the contemporaneous record that supports the company's good-faith compliance posture.
3. Map to the company's broader AI governance program. The RAISE Act is one input among several (EU AI Act, California SB 53, federal-sectoral expectations, Caremark duty of oversight) into the company's AI governance build. Map the inputs to the underlying NIST AI RMF / ISO/IEC 42001 / ISO/IEC 23894 substrate and let the substrate carry the compliance work.

A general theme runs through all three postures: the RAISE Act is a forcing function for documentation, not a new substantive legal theory. The compliance-cost optimum is to build the documentation against the underlying standards substrate (NIST AI RMF, ISO/IEC 42001, ISO/IEC 23894) and let one set of documents serve every regulatory regime that requires them. Companies that build the RAISE Act compliance posture as a standalone project will rebuild much of the same work for the EU AI Act, California SB 53, and adjacent regimes within twelve months. The companion reference on multi-jurisdictional AI compliance treats the unified-framework approach.

How to cite this article

Techné AI, The New York RAISE Act: A Reference for Boards and Compliance Teams (May 12, 2026), https://techne.ai/insights/new-york-raise-act-frontier-ai-reference.