What Compliance Requirements Does New York's RAISE Act Impose on AI Model Developers?

New York enacted the Responsible AI Safety and Education Act in December 2025, establishing the state as the nation's first comprehensive reporting and safety governance regime for frontier AI developers. The law emerged amid significant federal-state tension, following President Trump's December 2025 Executive Order directing federal agencies to challenge state AI laws that deviate from a minimally burdensome national standard.

The law applies to large frontier developers—companies with annual revenue exceeding $500 million that have trained frontier AI models using more than 10 to the 26th power computational operations with compute costs exceeding $100 million. The law's scope is geographic and operational, covering models developed, deployed, or operating in whole or in part in New York, creating compliance obligations even for companies with partial operational presence in the state.

Who Must Comply and the Thresholds That Trigger Obligations

The RAISE Act targets large frontier developers—entities with annual revenue exceeding $500 million that have trained frontier AI models. Models created through knowledge distillation are also covered if their compute costs exceed $5 million.

The law's application is broad and extends beyond traditional headquarters-based jurisdiction. It covers models developed, deployed, or operating in whole or in part in New York, creating compliance obligations even for companies with partial operational presence in the state. Developers running inference servers, model deployment infrastructure, or offering models to New York users fall under these requirements. Academic institutions and state agencies are exempt for pure research purposes, but this exemption does not extend to commercialized research or models operated by private sector partners.

The $100 million compute cost threshold is calculated as aggregate spending across the model's development, not a per-transaction cost. Companies must assess whether their total training investment—including hardware, cloud computing resources, and supporting infrastructure—exceeds this figure. The 10²⁶ computational operations threshold, measured in floating-point operations, represents a technical floor designed to capture only the largest, most capable models, not smaller specialized systems or fine-tuned variants below the cost threshold.

Safety Protocols: What They Must Address

The foundation of compliance is a written safety and security protocol implemented before model deployment. These protocols must specify reasonable protections and procedures to reduce the risk of critical harm, defined with specificity that guides developers in practice. Critical harm means death or serious injury to 100 or more people, or $1 billion or more in property damages. This includes harm resulting from chemical, biological, radiological, or nuclear weapons creation, or autonomous criminal conduct by AI systems with limited human intervention.

Developers must describe in detail the testing procedures to evaluate unreasonable risk of critical harm. This includes potential misuse, unauthorized modification, execution with increased computational resources, evasion of developer or user control, combination with other software, or use to create another frontier model. The protocols must include administrative, technical, and physical cybersecurity protections to prevent unauthorized access or misuse. Companies must maintain detailed test results with sufficient information for third-party replication, creating an audit trail that regulators and external reviewers can examine.

Protocols must designate senior personnel responsible for compliance, state requirements with sufficient specificity to allow ready determination of adherence, and describe how the developer will fulfill all obligations. Unredacted copies must be retained for the model's deployment duration plus five years. This multi-year retention requirement creates a compliance infrastructure that persists beyond a model's active operation, allowing investigation of historical incidents and regulatory examination of how safety frameworks evolved.

Documentation, Testing, and Third-Party Accountability

Safety protocols must detail cybersecurity measures preventing unauthorized access to model weights, parameters, or inference infrastructure. The law requires developers to address not only external threats but also insider risks, accidental misconfiguration, and the emergence of vulnerabilities as model capabilities evolve. Testing procedures must be reproducible; companies cannot rely on internal documentation alone but must provide sufficient detail that external auditors or regulators can independently verify that testing occurred and was conducted appropriately.

Annual reviews are mandatory, requiring developers to reassess protocols in light of capability changes and industry best practices. As models are used in production, developers may discover new risks or capabilities not apparent during initial testing. A model's behavior can shift through fine-tuning, instruction prompting, or interaction with other systems. The law requires that annual reviews translate these operational insights back into protocol updates.

Beyond written protocols, developers must prepare to document their testing regimen comprehensively. The law specifies that testing procedures must describe methodologies for evaluating risk of critical harm, including adversarial testing, stress testing under unusual conditions, and evaluation of potential harmful uses. Companies should consider working with independent third-party auditors to verify that testing is rigorous and that safety frameworks meet regulatory expectations, particularly given the uncertainties around how regulators will evaluate compliance in the law's early years.

Transparency to Markets and Regulators

Large developers must publish appropriately redacted copies of safety protocols to the public, with trade secrets and competitively sensitive information permitted to be withheld. At the same time, unredacted copies must be submitted to New York's Attorney General and Division of Homeland Security and Emergency Services. This dual-track system creates partial market transparency alongside full regulatory access, allowing public scrutiny of safety commitments while protecting proprietary technical details.

Before deployment, developers must publish reports including contact information for responsible parties, release dates, supported languages, intended uses and usage restrictions, and assessments of catastrophic risk. These transparency requirements create an audit trail and allow regulators to monitor frontier model deployment at scale. The advance disclosure of intended uses and usage restrictions is particularly significant; it requires developers to identify high-risk applications before deployment and commit publicly to restricting access to those use cases.

The publication requirement is not optional or conditional on market conditions. Companies cannot delay disclosure to manage competitive position or market timing. Redacted protocols must be published, with unredacted copies submitted to the New York Attorney General and Division of Homeland Security and Emergency Services.

Incident Reporting: Speed and Scope

Developers must report critical safety incidents within 72 hours of learning of the incident. This timeline is significantly faster than California's 15-day requirement and creates a compressed decision window for companies. The 72-hour clock starts when the developer determines an incident occurred, not when regulators inquire or when the incident becomes public. This distinction creates an incentive for companies to establish rapid internal incident classification procedures and decision-making frameworks.

Critical incidents include unauthorized access to model weights causing injury, materialized risks of critical harm, loss of control causing harm, or unexpected autonomous behavior indicating increased critical harm risk. Imminent threats to public safety require 24-hour law enforcement notification, creating a separate, faster reporting requirement for time-sensitive scenarios. Companies must establish internal processes to distinguish technical bugs and model degradation from safety incidents that trigger the 72-hour reporting requirement.

The incident reporting requirement extends to incidents that materialize and cause harm, but also to near-miss or near-failure scenarios where loss of control or harmful behavior became possible. A model behaving unexpectedly in ways that increase catastrophic risk—even if the unexpected behavior did not itself cause harm—must be reported. This creates compliance burden around internal monitoring and incident classification; companies must track and document not only actual harms but also technical failures and capability surprises that indicate elevated risk.

Ongoing Compliance and Quarterly Assessments

Beyond incident reporting, developers must conduct annual reviews of safety and security protocols, accounting for changes to model capabilities and industry best practices. Material modifications to protocols must be publicly disclosed, creating a continuous cycle of assessment and adaptation. Large developers must also submit catastrophic risk assessments to regulators every three months. These quarterly submissions prevent stale assessments; regulators receive updated risk evaluations at three-month intervals, capturing how models' capabilities and risk profiles evolve over time.

The quarterly reporting requirement creates an ongoing compliance obligation that extends indefinitely for any frontier model in deployment. Companies must maintain internal monitoring infrastructure to identify material capability changes, security incidents, or shifts in how the model is used in production. Quarterly assessments must be dated and documented, creating a regulatory record that can later be examined to determine whether companies accurately assessed risks contemporaneously or only after harm occurred.

Large developers must also file and renew disclosure statements identifying ownership structures. This requirement addresses concerns about accountability and liability; regulators want to know who controls frontier models and who bears responsibility for compliance. The renewal requirement ensures that ownership information remains current as companies merge, restructure, or are acquired.

Enforcement, Penalties, and Federal Preemption Risk

New York's Attorney General is the sole enforcement authority; the law creates no private right of action, meaning only state regulators can pursue compliance through civil actions. Penalties reach $1 million for initial violations and $3 million for subsequent violations, and courts may issue injunctive or declaratory relief. The escalating penalty structure incentivizes compliance; a company that violates requirements multiple times faces penalties that multiply rapidly.

The law's long-term viability remains uncertain due to pending federal challenges. President Trump's December 2025 Executive Order directed federal agencies to challenge state AI laws that deviate from a minimally burdensome national standard. Federal agencies including the Federal Trade Commission, Federal Communications Commission, Department of Justice, and Department of Commerce are expected to evaluate state AI laws as part of efforts to establish a minimally burdensome national standard. Legal experts expect litigation over preemption, with developers potentially facing conflicting state requirements while federal courts determine whether New York's law survives constitutional scrutiny.

Companies should monitor federal actions and litigation closely. If New York's law is struck down on preemption grounds, companies that invested in compliance infrastructure would not recover those costs. Conversely, the law's requirements may persist and strengthen if federal challenges fail. Until litigation resolves, prudent companies should plan for compliance while hedging by monitoring federal developments.

Timeline and Preparation Steps for Companies

The law takes effect on January 1, 2027, giving developers one year from enactment to establish compliance frameworks. As of January 2026, some final regulatory amendments had not yet been incorporated into official text. Companies should monitor the New York State Legislature's sources and regulatory agency guidance for the complete framework as implementation approaches.

Developers should take specific steps now: assess whether your frontier models meet the 10²⁶ compute and $100 million spending thresholds; determine whether your models are deployed or operating in New York; develop comprehensive written safety frameworks addressing identified risks; create testing regimens and incident disclosure processes; designate senior personnel responsible for compliance monitoring; and prepare publication and reporting mechanisms.

Companies should also consider engaging independent third-party auditors to evaluate safety protocols and testing rigor. Early adoption of robust safety practices may demonstrate good-faith compliance effort if regulators later scrutinize companies' initial submissions. Documentation of how and why companies designed safety protocols particular ways creates a record that supports defense against regulatory claims of inadequate effort or intentional non-compliance.