1. Check Coverage before Applying the Revenue Threshold
The Act regulates specified frontier models and their developers. An AI product’s name, customer base, or marketing description does not establish coverage. Start with the training history, the company’s role, and where the model operates.
Model Training and the Developer’S Role
A frontier model is a foundation model trained using more than 10²⁶ integer or floating-point operations. The calculation includes the original training run and subsequent fine-tuning, reinforcement learning, or other material modifications.
A frontier developer trains or initiates training using, or intending to use, computing power meeting the statutory specifications. Purchasing access to an existing model does not, by itself, establish that role. Companies that train or modify models should examine their actual activities rather than rely on a vendor’s description.
State Connection and Affiliate Revenue
The Act applies only to frontier models developed, deployed, or operating wholly or partly in New York. A developer’s headquarters location alone does not resolve this question.
A large frontier developer also has preceding-calendar-year gross revenues exceeding $500 million collectively with its affiliates. That threshold determines additional obligations. Falling below it does not eliminate every developer duty.
For an AI legal compliance review, assemble training-compute records, development agreements, affiliate information, and deployment details. These records support a coverage decision more reliably than a general description of the business.
2. Separate Baseline Duties from Large Developer Requirements
The law assigns some obligations to frontier developers generally and others specifically to large frontier developers. Compliance teams should identify the responsible entity and applicable requirements before drafting documents.
| Requirement | Frontier developer below the large-developer threshold | Large frontier developer |
|---|---|---|
| Public deployment transparency report | Required | Required, with additional risk-assessment summaries |
| Public frontier AI framework | No separate framework requirement under this provision | Must write, implement, follow, and publish it |
| Critical safety incident reporting | Required | Required |
| Internal-use catastrophic-risk assessment summaries | No equivalent periodic submission requirement under this provision | Generally every three months, unless the office agrees to another schedule |
Public deployment transparency report
- Frontier developer below the large-developer thresholdRequired
- Large frontier developerRequired, with additional risk-assessment summaries
Public frontier AI framework
- Frontier developer below the large-developer thresholdNo separate framework requirement under this provision
- Large frontier developerMust write, implement, follow, and publish it
Critical safety incident reporting
- Frontier developer below the large-developer thresholdRequired
- Large frontier developerRequired
Internal-use catastrophic-risk assessment summaries
- Frontier developer below the large-developer thresholdNo equivalent periodic submission requirement under this provision
- Large frontier developerGenerally every three months, unless the office agrees to another schedule
Publish the Required Information at Deployment
A developer must publish a transparency report before or when deploying a new frontier model or a substantially modified version. Required information includes the release date, supported languages, output modalities, intended uses, general restrictions, website, and a contact mechanism.
Large developers must also summarize catastrophic-risk assessments, their results, third-party evaluator involvement, and steps taken under their framework.
Keep the Framework Consistent with Practice
A large developer’s framework must explain risk assessment, mitigation, deployment decisions, model-weight security, incident response, and internal governance in detail. It also addresses risks from extensive internal model use.
Review the framework at least annually. Publish material changes and their justification within 30 days.
Compare public safety claims with testing records and actual controls. Unsupported claims can create broader AI washing concerns. A polished policy does not demonstrate that employees follow it.
3. Identify the Incident and Start the Correct Reporting Clock
The reporting rules concern defined critical safety incidents, including incidents involving internal model use. An ordinary outage or inaccurate answer does not automatically qualify. The team must examine the event against the statutory categories.
Different Incident Categories Have Different Conditions
Critical safety incidents include:
- Unauthorized access to, modification of, or extraction of model weights resulting in death or bodily injury.
- Harm resulting from the materialization of a catastrophic risk.
- Loss of model control causing death or bodily injury.
- Specified deceptive behavior that subverts developer controls outside an evaluation and demonstrates materially increased catastrophic risk.
Catastrophic risk has its own definition. It concerns foreseeable, material risks involving specified model conduct and harm to more than 50 people through death or serious injury, or property damage exceeding $1 billion. Those thresholds do not govern every critical incident category.
Distinguish the 72-Hour Report from Urgent Disclosure
A developer must report to the designated office within 72 hours after determining that a critical safety incident occurred or learning sufficient facts to reasonably believe one occurred.
If the developer discovers that an incident poses an imminent risk of death or serious physical injury, it must disclose the incident within 24 hours to an appropriate authority with jurisdiction.
The designated office sits within the Department of Financial Services. The urgent disclosure recipient depends on the incident and may be a law enforcement or public safety agency.
Preserve discovery timestamps and escalation records. A completed technical investigation is not the reporting trigger.
4. Build a Workable Compliance Process before Enforcement Begins
A release checklist and an incident-response plan should identify who makes decisions and what information they need. The following preparation steps are practical recommendations, rather than additional statutory filings.
Assign Owners and Test the Handoffs
Identify who will:
- Maintain training-compute and affiliate-revenue records.
- Decide whether model changes require updated disclosures.
- Approve public documents and permitted redactions.
- Evaluate incidents and authorize timely reports.
Test the reporting process while technical facts remain incomplete. Engineers may still be investigating when legal and compliance staff need to assess a deadline.
Understand Penalties and Other Legal Exposure
The attorney general may seek civil penalties against large frontier developers for specified violations, including deficient disclosures, reporting failures, prohibited statements, and failure to follow their frameworks.
Maximum penalties are $1 million for a first violation and $3 million per subsequent violation, with severity affecting the amount.
The Act creates no private right of action. It also preserves obligations and remedies under other laws. A dispute may therefore require a separate AI litigation analysis.
Businesses researching this New York AI law for 2027 should keep state requirements distinct from federal obligations. Compliance with one framework does not automatically satisfy another.
5. Frequently Asked Questions
The following questions address additional disclosure and exemption issues that may affect implementation.
Yes, if it contains all information required for the applicable developer category. The Act permits disclosures within a larger document, including a model card or system card. The document’s name alone does not establish compliance.
Necessary redactions are permitted for specified reasons, including trade secrets, cybersecurity, public safety, national security, and compliance with law. Developers must explain the character and justification of redactions to the extent permitted by those concerns and retain unredacted information for five years.
Not automatically. The academic-research exception concerns accredited colleges and universities in New York to the extent they conduct qualifying research. The Act also exempts the Empire AI consortium and institute. A commercial participant must assess its own status and activities.
6. Resolve Uncertain Coverage before Approving Disclosures
Legal review is useful when shared training arrangements, model modifications, affiliate relationships, or operations across state boundaries leave the company’s obligations unclear. A scheduled release or a possible critical incident can make those questions time-sensitive.
Bring the model inventory, compute records, corporate structure, release plans, and draft disclosures to the review. An attorney can use those materials to assess coverage, identify applicable duties, and check whether the reporting process reflects the statutory triggers.
05 Oct, 2026
