Frontier AI safety protocols, mandatory third-party audits, incident reporting, and designated compliance personnel mapped to SWT3 witness procedures.
Who this is for: AI safety teams at frontier model developers, third-party AI auditors, compliance officers at companies building or deploying large-scale AI models, and legal counsel advising on New York AI safety obligations.
Amended March 27, 2026. Governor Hochul signed chapter amendments overhauling the RAISE Act to align with California's TFAIA. Key changes: a new DFS oversight office, 72-hour critical incident reporting (24 hours for imminent death/injury risk), mandatory transparency reports before deploying new frontier models, and annual disclosure statements filed with DFS. The amended law takes effect January 1, 2027. Penalties: up to $1 million for a first violation, $3 million for subsequent violations.
The RAISE Act requires frontier AI developers to create, publish, and annually update a frontier AI framework describing how they assess and mitigate catastrophic risks, secure model weights, use third-party evaluators, and respond to safety incidents. The March 27, 2026 amendments established a new oversight office within the Department of Financial Services (DFS) and strengthened reporting obligations.
The Act defines a "frontier model" by compute threshold and targets developers with more than $500 million in annual gross revenue. As amended, it requires:
The amended RAISE Act closely aligns with California's Transparency in Frontier AI Act (SB 53), creating a bicoastal regulatory corridor. However, the RAISE Act requires disclosure of incidents within 72 hours, compared to TFAIA's 15-day timeline, making New York's reporting obligation significantly more demanding.
| Obligation | Requirement | Timeline |
|---|---|---|
| Frontier AI Framework | Detailed published framework describing risk assessment, mitigation, weight security, third-party evaluators, and incident response | Published on website; annually reviewed and updated; material changes within 30 days |
| Transparency Reports | Public report before deploying new or modified frontier models, including risk assessment summary and third-party evaluator involvement | Before each deployment |
| Critical Incident Reporting | Report critical safety incidents to DFS office | 72 hours (24 hours if imminent death/injury risk) |
| DFS Disclosure Statements | Large frontier developers file disclosure statements with DFS office and pay pro rata assessments | As prescribed by DFS |
| Cybersecurity Protections | Controls against unauthorized access to model weights, training data, and inference infrastructure | Ongoing |
| Testing Procedures | Evaluate whether frontier models pose unreasonable risk of critical harm, with third-party evaluator involvement | Before deployment; ongoing |
| Whistleblower Protections | Internal reporting processes for safety concerns; retaliation prohibited | Ongoing |
Each RAISE Act obligation maps to SWT3 witness procedures that produce cryptographically anchored evidence of compliance.
| RAISE Act Obligation | SWT3 Procedure | What It Witnesses | Evidence Produced |
|---|---|---|---|
| Frontier AI Framework | AI-SAFE.1 | Safety testing and validation | Factor A: test type, Factor B: pass rate, Factor C: coverage |
| Frontier AI Framework | AI-GOV.6 | AI governance scope definition | Factor A: systems in scope, Factor B: risk tolerance, Factor C: review authority |
| Transparency Reports | AI-TRANS.1 | Transparency report generation | Factor A: report type, Factor B: coverage, Factor C: publication status |
| Transparency Reports | AI-REDTEAM.1 | Third-party evaluator involvement | Factor A: test scenario, Factor B: findings count, Factor C: severity distribution |
| Incident Reporting (72h) | AI-INCIDENT.1 | Incident detection and response | Factor A: incident type, Factor B: severity, Factor C: response time |
| Incident Reporting (72h) | AI-IR.1 | AI incident response execution | Factor A: response action, Factor B: containment status, Factor C: escalation level |
| DFS Disclosure | AI-AUDIT.1 | Audit log integrity for regulatory filings | Factor A: audit type, Factor B: completeness, Factor C: filing status |
| Cybersecurity | AI-CYBER.1 | AI system cybersecurity posture | Factor A: control domain, Factor B: assessment result, Factor C: remediation status |
| Testing Procedures | AI-REDTEAM.1 | Red team and adversarial testing | Factor A: test scenario, Factor B: findings count, Factor C: severity distribution |
| Testing Procedures | AI-ROBUST.1 | Robustness and resilience testing | Factor A: test scenario, Factor B: degradation metric, Factor C: threshold |
RAISE Act requires: Safety and security protocols must describe "testing procedures to evaluate whether the covered frontier model poses an unreasonable risk of critical harm." Testing must be conducted before deployment and at regular intervals during operation.
How SWT3 addresses it: The witness_safety() call records the test type conducted (adversarial, boundary, stress, regression), the pass rate, and the coverage achieved. Each test produces an anchored record proving the test was performed, when it was performed, and what the outcome was.
Filter the witness ledger for AI-SAFE.1 anchors. Pre-deployment anchors must predate the first AI-INF.1 anchor for the same model. Ongoing anchors at regular intervals prove continuous testing. Factor A identifies the test type. Factor B records the pass rate. Gaps in AI-SAFE.1 anchors indicate periods without safety testing.
RAISE Act requires: Developers must evaluate whether frontier models pose "unreasonable risk of critical harm," which in practice requires adversarial testing and red team exercises targeting model failure modes, jailbreaks, and harmful output generation.
How SWT3 addresses it: The witness_redteam() call records the test scenario, the number of findings, and the severity distribution. Each red team exercise produces an anchor that documents both the testing methodology and the results, creating a continuous record of adversarial validation.
AI-REDTEAM.1 anchors prove adversarial testing occurred. Factor A identifies the scenario (jailbreak, prompt injection, harmful content, data exfiltration). Factor B records findings count. Factor C shows severity distribution. Cross-reference with AI-SAFE.1 to show that red team findings feed into the safety protocol update cycle.
RAISE Act requires: Developers must report critical safety incidents to the Attorney General within prescribed timeframes. This requires incident detection capability, severity classification, and documented response procedures.
How SWT3 addresses it: The witness_incident() call records the incident type, severity, and response time. The anchor timestamp provides independently verifiable proof of when the incident was detected, supporting the AG reporting timeline. Cross-reference with AI-IR.1 anchors to show the response actions taken.
AI-INCIDENT.1 anchors prove incident detection capability exists and is operational. Factor B records severity classification. Factor C records response time. The time between AI-INCIDENT.1 (detection) and AI-IR.1 (response) anchors shows response latency. For AG reporting: the AI-INCIDENT.1 anchor timestamp is the independently verifiable "discovery" timestamp.
RAISE Act requires: Designated senior personnel responsible for ensuring compliance with safety protocols. The scope of AI systems covered, risk tolerances, and oversight authority must be documented.
How SWT3 addresses it: The witness_governance_scope() call records the systems in scope, the risk tolerance framework, and the designated review authority. This creates an immutable record of governance assignments that can be verified independently.
AI-GOV.6 anchors prove governance structure exists. Factor A identifies the systems covered. Factor C identifies the designated compliance personnel. Regular AI-GOV.6 anchors at annual intervals demonstrate the protocol is "annually updated" as required. Cross-reference with AI-SAFE.1 and AI-REDTEAM.1 to show that governance scope drives testing coverage.
RAISE Act requires: Cybersecurity protections against unauthorized access to model weights, training data, and inference infrastructure. The safety protocol must describe these protections.
How SWT3 addresses it: The witness_cybersecurity() call records the control domain assessed, the assessment result, and the remediation status. This creates evidence that cybersecurity controls were evaluated and maintained for the AI system infrastructure.
AI-CYBER.1 anchors prove cybersecurity assessments were conducted. Factor A identifies the domain (model weights, training data, inference API, access controls). Factor B records the assessment result. Factor C shows remediation status for any findings. Regular intervals demonstrate continuous security monitoring.
| Dimension | New York RAISE Act | California SB 53 (TFAIA) |
|---|---|---|
| Effective Date | January 1, 2027 (amended) | January 1, 2026 |
| Revenue Threshold | $500M annual gross revenue | $500M annual gross revenue |
| Scope | Frontier AI developers (compute threshold) | Large frontier AI developers (compute threshold) |
| Framework/Protocols | Frontier AI Framework, published, annually updated, "in detail" | Safety protocols, published, annually updated |
| Transparency Reports | Required before each new model deployment | Not required |
| Incident Reporting | To DFS office, 72 hours (24h if imminent risk) | To Frontier Model Division, 15 days |
| Regulatory Oversight | New DFS office with rulemaking authority | Frontier Model Division |
| Whistleblower | Protected | Protected |
| Penalties | $1M first, $3M subsequent | Civil penalties (AG enforcement) |
| Developer Assessments | Pro rata fees to fund DFS office | Not required |
Key insight: The March 2026 amendments make New York's reporting timeline significantly more demanding than California's (72 hours vs 15 days). The new DFS office with rulemaking authority and mandatory transparency reports before model deployment go beyond California's requirements. Companies must comply with New York's stricter timeline while maintaining California evidence. SWT3 witness anchors satisfy both jurisdictions from the same evidence stream -- the anchor timestamp provides independently verifiable proof of when incidents were detected, supporting both the 72-hour and 15-day windows.
| Examiner Question | Where to Look |
|---|---|
| Do you have published safety protocols? | AI-GOV.6 anchors define governance scope. AI-SAFE.1 anchors demonstrate testing procedures are operational. Annual AI-GOV.6 anchors prove protocols are updated yearly. |
| Who is your designated compliance officer? | AI-GOV.6 Factor C identifies the review authority. Cross-reference with organizational records to verify the individual has appropriate seniority. |
| How do you test for catastrophic risk? | AI-REDTEAM.1 and AI-SAFE.1 anchors. Factor A identifies test types. Pre-deployment anchors prove testing before release. Ongoing anchors prove continuous evaluation. |
| How do you detect and report safety incidents? | AI-INCIDENT.1 anchors prove detection capability. Factor C records response time. The anchor timestamp is the verifiable "discovery" timestamp for AG reporting timelines. |
| What cybersecurity controls protect your model? | AI-CYBER.1 anchors with Factor A identifying the domain (weights, training data, API access). Factor B records assessment results. Factor C tracks remediation. |
| Do you comply with both NY and CA requirements? | The same anchors satisfy both jurisdictions. AI-SAFE.1 + AI-REDTEAM.1 + AI-INCIDENT.1 + AI-GOV.6 cover the overlapping requirements. Filter by procedure to show jurisdiction-specific evidence. |
Full SDK documentation: sovereign.tenova.io/docs
Create a free account: sovereign.tenova.io/signup