New York RAISE Act: A 2027 Readiness Split for Developers and Customers

New York's RAISE Act places registration and safety-framework duties on covered frontier-model developers. It also places catastrophic-risk assessment and disclosure duties on them, along with incident-reporting duties. The state's September 2026 implementation announcement says registration begins in November 2026 and substantive compliance begins in January 2027.

Enterprise API customers need a different file. They should record the provider and model they approved; the evidence they reviewed; how they route requests; how they escalate an incident. They should not claim to have completed the developer's statutory work.

TL;DR

• Covered frontier-model developers need their own registration and safety records, assessment and disclosure records, plus incident records.
• Enterprise customers should retain vendor-diligence decisions and evidence for their configured model use.
• A managed API log can reconstruct customer-side requests and route decisions.
• It cannot establish training-compute thresholds or weight security. It also cannot establish frontier evaluations or the developer's filing with New York.

The law divides responsibility by role

The official S.6953-B legislative text contains the RAISE Act provisions enacted as General Business Law Article 44-B. The Governor's September 2026 implementation announcement describes registration beginning in November, with substantive requirements starting in January 2027.

A developer register should identify the legal entity and covered model; threshold analysis and registration status; safety framework and assessment schedule; disclosure owner and incident process; filing evidence. Each item needs a source record and approval.

An enterprise customer register should identify the provider and model and version; intended use and data classes; approved routes and contract owner; safety evidence reviewed and exceptions; monitoring and exit trigger. The customer's file supports procurement and operations. It does not become the developer's compliance record.

Safety frameworks need versioned evidence

A covered developer should preserve the approved safety framework and evaluation standards; model and checkpoint scope; risk assumptions and review history; publication record. Join each framework requirement to the team and artifact that implements it.

A customer reviewing the framework should record the exact version and date. Keep the relevant provider disclosures and contract terms; evaluation summaries and incident commitments; internal acceptance decision. Set a review expiry so an old framework cannot support a new model indefinitely.

I would not approve a frontier-model route from a browser bookmark and a sales deck. The acceptance file should show the model identifier and approved use; data boundary and current evidence; owner and next review date on one page.

Assessments and disclosures remain developer duties

The state announcement describes quarterly catastrophic-risk assessments and biennial disclosure requirements for covered developers. The developer should preserve methods and model versions; test conditions and findings; approvals and submitted or published materials.

Customers can request relevant evidence and record any limitation. They can also run tests for their own configured use. A customer test of an authenticated support assistant says nothing about the developer's complete catastrophic-risk assessment.

Use the AI vendor risk management guide to connect provider evidence to a procurement decision. Keep missing evidence and compensating controls visible. Keep rejection criteria visible rather than burying them in meeting notes.

Critical incident reporting needs two playbooks

The implementation announcement describes a 72-hour critical-safety-incident reporting requirement for covered developers. The developer needs detection and severity assessment; legal review and preservation; decision and filing; remediation records.

The enterprise customer needs its own incident playbook. Preserve the authenticated user or workload and model route; request and response references; policy decision and application action; affected data and provider notification; internal escalation. A timer should start when the customer discovers its own event, even when the developer's statutory reporting analysis sits elsewhere.

On the incident screen, a red DENY event at 02:14 UTC is useful only when it links to the route and policy version, plus the actor and investigation. The AI incident reporting guide covers that evidence chain.

API controls support customer-side diligence

Before routing production traffic, bind the approved model and provider to the use case and identity class; data classifications and geography; retention setting and policy version. Reject requests whose destination or data class falls outside the acceptance record.

Monitor changes in provider model identifiers and terms; endpoints and safety documentation; incident notices. A new model alias should trigger review instead of silently inheriting the old approval.

The resulting request event can show how the customer used the model. It cannot determine whether the provider crossed the law's coverage threshold or protected model weights. It also cannot determine whether the provider completed required evaluations or filed with New York's Department of Financial Services or Department of State as applicable under the implementation process.

DeepInspect

DeepInspect can enforce customer-side controls on authenticated HTTP requests deliberately routed to LLM endpoints. It can bind application-supplied identity and role to data classification and approved model destination; policy version and outcome; time.

Use that evidence for enterprise route control and vendor diligence, plus monitoring and incident reconstruction. Training thresholds and model weights, frontier evaluations and developer assessments, plus public disclosures and statutory filings remain with the covered developer.

Book a technical deep dive at deepinspect.ai.