Illinois Attorney General; Illinois Emergency Management Agency and Office of Homeland Security · Illinois (US-IL) · 5 provisions encoded · verified against the official source as of 2026-09-27.
Informational data, not legal advice. Summaries are TwinEthos's own words and rules have not been reviewed by a lawyer: check the official text before relying on any of it. A guard addresses an item; adding it is not a statement that your code meets any law.
Frontier developers must report critical safety incidents to Illinois within 72 hours, or 24 hours if lives are at imminent risk (Illinois SB 315)
IL PA 104-0538, Sec. 15(c) · official text · Enacted, not yet applying: applies from 1 Jan 2027 · Illinois (US-IL)
Section 15(c) of the Illinois AI Safety Measures Act requires every frontier developer, from January 1, 2027, to report a critical safety incident involving its frontier models to the Illinois Emergency Management Agency and Office of Homeland Security and to the Attorney General within 72 hours of learning facts that support a reasonable belief it happened. The report gives the date, why the event qualifies, and a short plain description, and may later be amended. An incident posing an imminent risk of death or serious physical injury must go to an appropriate authority, such as law enforcement, within 24 hours. Qualifying incidents are limited to weight theft or tampering causing death or injury, harm from a catastrophic risk, loss of control causing death or injury, and a model deceptively subverting the developer's controls outside testing. Detect a frontier developer with no incident procedure matching those definitions, clocks, recipients, and report fields.
Who it applies to
Duty falls on: developer
All frontier developers (any revenue). Reporting to foundation models that are not frontier models is encouraged, not required. Applies from 2027-01-01.
Whether it applies depends on facts outside the code; a person has to decide.
The guard to add
Organizational artifact to keep (not verifiable from code); the guard is the record, its owner and its upkeep.
Keep a critical safety incident runbook that classifies the defined incident classes and runs the 72-hour report and 24-hour imminent-risk escalation clocks.
An incident-response runbook section, owned by the frontier safety or security lead and reviewed whenever models, monitoring or the governing statutes change, that defines the critical-safety-incident classes as the statutes word them (model-weight theft or tampering causing death or injury, harm from a catastrophic risk materialising, loss of control causing death or injury, a model deceptively subverting the developer's controls outside testing), names who decides that an event qualifies, and starts the clock when facts support a reasonable belief one occurred. It lists the recipient authority per jurisdiction, the report fields, the 24-hour path to law enforcement or a public-safety agency for imminent risk of death or serious physical injury, and keeps a record of every report and amendment. In code, the severity taxonomy and monitoring that feed it (weight-access alerts, model-behaviour monitors) route a candidate incident to that runbook with the timers attached.
Where it goes: 12 repository artifacts, 10 logs and telemetry.
What this provision adds:
Report to the Illinois Emergency Management Agency and Office of Homeland Security and to the Attorney General within 72 hours of learning facts that support a reasonable belief an incident happened.
The report gives the date, why the event qualifies, and a short plain description, and may later be amended.
Where a frontier developer relies on a designated federal incident-reporting standard, keep the declaration to IEMA-OHS of compliance through that standard.
Rule id il-sb315.critical-safety-incident-reporting · review status: primary source derived
Binding law — not yet in force or stayed
Large frontier developers must publish and follow a frontier AI framework from 2028 (Illinois SB 315)
IL PA 104-0538, Sec. 10(a) · official text · Enacted, not yet applying: applies from 1 Jan 2027 (further phase from 1 Jan 2028) · Illinois (US-IL)
Illinois's Artificial Intelligence Safety Measures Act (Public Act 104-0538) takes effect on January 1, 2027, but gives large frontier developers (those training models with more than 10^26 operations whose group revenue topped $500 million the year before) until January 1, 2028 to write, implement, obey, and conspicuously publish a frontier AI framework. The framework must explain their approach to the same ten topics as New York's RAISE Act: standards, catastrophic-capability thresholds, mitigations, pre-deployment and internal-use review, third-party assessment, update triggers, protection of unreleased weights, critical safety incident response, internal governance, and internal-use risk including oversight evasion. They must review it at least yearly and republish material changes with reasons within 30 days. From the Act's start date they must also send the state emergency-management agency (IEMA-OHS) summaries of internal-use catastrophic-risk assessments every three months or on an agreed schedule. Detect a covered developer with no published framework (from 2028) or no record of those summaries.
Who it applies to
Duty falls on: developer
Large frontier developers. Internal-use risk summaries from 2027-01-01; the published framework and its annual review from 2028-01-01. Binds model developers, not applications that call a hosted model.
Whether it applies depends on facts outside the code; a person has to decide.
The guard to add
Organizational artifact to keep (not verifiable from code); the guard is the record, its owner and its upkeep.
Publish a frontier AI framework covering capability thresholds, mitigations, incident response, and internal-use risk, and gate model releases on it.
A public framework page, linked from the developer's website and owned by the frontier-safety lead, that maps each covered topic to the policy implementing it: standards adopted, catastrophic-capability thresholds and the evaluations that test them, mitigations applied when thresholds are reached, critical safety incident identification and response, and assessment of catastrophic risk from internal use. Show that it is implemented: release checklists cite the threshold evaluation results, a versioned changelog records changes with reasons and dates, and internal-use risk summaries sent to regulators are tracked with receipts. A CI or release gate refuses to promote a frontier model whose release record lacks the evaluations the framework calls for.
Where it goes: 12 repository artifacts, 14 user-facing text, 11 CI/CD pipeline.
What this provision adds:
Cover all ten topics: standards, catastrophic-capability thresholds, mitigations, pre-deployment and internal-use review, third-party assessment, update triggers, unreleased-weight protection, incident response, internal governance, and internal-use risk including oversight evasion.
Publish the framework from January 1, 2028, review it at least yearly, and republish material changes with reasons within 30 days.
From January 1, 2027, send IEMA-OHS summaries of internal-use catastrophic-risk assessments every three months or on an agreed schedule.
Rule id il-sb315.frontier-ai-framework · review status: primary source derived
Binding law — not yet in force or stayed
Large frontier developers must obtain and publish an annual independent compliance audit from 2028 (Illinois SB 315)
IL PA 104-0538, Sec. 10(d) · official text · Enacted, not yet applying: applies from 1 Jan 2028 · Illinois (US-IL)
Section 10(d) of Illinois's Artificial Intelligence Safety Measures Act (Public Act 104-0538) makes every large frontier developer hire an independent third party each year to audit whether it is meeting Section 10: the frontier AI framework, transparency reports, internal-use risk summaries and the related duties. The first audit year starts on January 1, 2028, or 90 days after the developer first qualifies as a large frontier developer if that is later. The auditor must work to generally accepted auditing standards, bring frontier-model safety expertise, and have no financial interest in the developer (or the developer in it), and its fee cannot depend on the findings. The developer must open the materials the audit needs, including unredacted versions of what it published, though it may set security protocols. The auditor's signed report covers substantial compliance, material deviations with recommendations, internal controls and accountable senior staff, audit personnel, conflicts of interest, and methodology. Within 30 days the developer must post a high-level summary and a redacted copy on its website, send the redacted report to IEMA-OHS and the Attorney General, and keep the unredacted report while any frontier model is deployed plus five years. Detect a covered developer with no audit engagement, report, publication, or transmittal record once the duty applies.
Who it applies to
Duty falls on: developer
Large frontier developers only. Annual, starting on the later of 2028-01-01 or 90 days after the developer first qualifies as a large frontier developer. A developer that declared under Sec. 17(b) that it complies through a designated federal standard is deemed in compliance to the extent it meets that standard. Binds model developers, not applications that call a hosted model.
Whether it applies depends on facts outside the code; a person has to decide.
The guard to add
Organizational artifact to keep (not verifiable from code); the guard is the record, its owner and its upkeep.
Engage an independent auditor on non-contingent fees each year to audit frontier-safety obligations, then publish, transmit, and retain the signed report.
A yearly audit cycle owned by the developer's governance or legal lead and tracked as a calendared task with evidence links. It covers: an engagement letter recording the auditor's independence (no financial interest either way) and a fee that does not depend on findings; auditor access to the materials it needs, including unredacted versions, under security protocols; a signed report on obligations met, material deviations with recommendations, internal controls and accountable senior staff, audit personnel, conflicts, and methodology; publication of a summary and redacted report; transmittal to the regulators; and retention of the unredacted copy. This is an organizational record, not a code change; the repository can hold the evidence index for each year.
Where it goes: 12 repository artifacts, 14 user-facing text.
What this provision adds:
Start the first audit year on the later of January 1, 2028 or 90 days after first qualifying as a large frontier developer, then audit every year.
Within 30 days, post a high-level summary and a redacted copy on the website and send the redacted report to IEMA-OHS and the Attorney General.
The auditor works to generally accepted auditing standards with frontier-model safety expertise; keep the unredacted report while any frontier model is deployed plus five years.
Example (Audit evidence index (repo record)), before:
Rule id il-sb315.independent-compliance-audit · review status: primary source derived
Binding law — not yet in force or stayed
Frontier developers must publish a transparency report at deployment, with machine-readable risk summaries (Illinois SB 315)
IL PA 104-0538, Sec. 10(c)(1) · official text · Enacted, not yet applying: applies from 1 Jan 2027 · Illinois (US-IL)
From January 1, 2027, Section 10(c) of Illinois's AI Safety Measures Act requires any frontier developer to post a transparency report on its website before or when it deploys a new or substantially modified frontier model, listing its website, a contact channel for individuals, the release date, supported languages and output modalities, intended uses, and general use restrictions. A large frontier developer must add summaries of its framework-based catastrophic-risk assessments, their results, third-party evaluator involvement, and other framework steps for the model, and, unlike New York's equivalent, must deliver those summaries in a machine-readable format so model claims can be verified. A model or system card containing the information counts. Detect a frontier-model release with no report, missing required fields, or risk summaries available only as prose or PDF.
Who it applies to
Duty falls on: developer
All frontier developers deploying a new or substantially modified frontier model; the machine-readable risk-assessment summaries apply only to large frontier developers (revenue above $500,000,000). Applies from 2027-01-01.
Whether it applies depends on facts outside the code; a person has to decide.
The guard to add
Organizational artifact to keep (not verifiable from code); the guard is the record, its owner and its upkeep.
Publish a transparency report or system card on the developer's website before or at each new or substantially modified frontier-model deployment, and gate release on it.
A transparency report the frontier developer publishes on its website before or when each new or substantially modified frontier model is deployed; a model card or system card can carry it. It lists the developer's website, a contact channel for individuals, the release date, supported languages and output modalities, intended uses, and general use restrictions; for large developers it adds summaries of the catastrophic-risk assessments run under the developer's framework, their results, how far third-party evaluators were involved, and other framework steps taken for that model. The release or safety-policy owner maintains it and revises it for every new or substantially modified model, and the deployment pipeline carries a release gate that blocks rollout until the report is live with its fields present (for example a transparency-report.json validated against a schema in CI).
Where it goes: 12 repository artifacts, 14 user-facing text, 11 CI/CD pipeline.
What this provision adds:
Large frontier developers deliver the risk-assessment summaries in a machine-readable format so model claims can be verified, not only as prose or PDF.
The risk-assessment summaries apply only to large frontier developers (revenue above $500,000,000); every frontier developer posts the base report.
Rule id il-sb315.transparency-report · review status: primary source derived
Binding law — not yet in force or stayed
Frontier developers must not gag or retaliate against AI safety whistleblowers (Illinois SB 315)
IL PA 104-0538, Sec. 20(a) · official text · Enacted, not yet applying: applies from 1 Jan 2027 · Illinois (US-IL)
Section 20 of the Illinois AI Safety Measures Act forbids a frontier developer from making or enforcing any rule, policy, or contract that stops employees responsible for critical-safety-incident risk from telling IEMA-OHS, the Attorney General, a federal authority, a supervisor, or an authorized colleague about activities posing a specific and substantial catastrophic-risk danger or about violations of the Act, and from retaliating against them for doing so. Contracts also may not block disclosures protected by the Illinois Whistleblower Act. Developers must give those employees clear notice of these rights, by continuous posting or a yearly acknowledged written notice, and large frontier developers must run an anonymous internal reporting process with monthly status updates to the reporter and quarterly sharing with officers and directors. Detect employment templates or policies that restrict such disclosures, or the absence of the rights notice and anonymous channel.
Who it applies to
Duty falls on: developer
Frontier developers with covered employees (employees responsible for assessing, managing, or addressing critical-safety-incident risk); the anonymous internal channel applies to large frontier developers. Binds employment policy and contract terms. Applies from 2027-01-01.
Whether it applies depends on facts outside the code; a person has to decide.
The guard to add
Organizational artifact to keep (not verifiable from code); the guard is the record, its owner and its upkeep.
Carve AI-safety and legal-violation disclosures out of every NDA and policy, adopt non-retaliation, and run an internal safety-concern channel for covered employees.
Legal and HR own the employment and confidentiality templates (offer letters, NDAs, separation agreements, codes of conduct) and add an explicit carve-out stating that nothing in them stops a covered employee from reporting catastrophic-risk concerns or violations of the law to the authorities the statute names, or requires company approval first. Pair it with a written non-retaliation policy and an internal reporting channel for safety concerns (anonymous where required) with a documented triage and response procedure. Re-check every template when it is edited; the repository can hold the policy, the clause, and a CI check that each agreement template still contains the carve-out.
Where it goes: 12 repository artifacts, 14 user-facing text.
What this provision adds:
The carve-out covers disclosures to IEMA-OHS, the Attorney General, a federal authority, a supervisor or an authorized colleague, and contracts may not block disclosures protected by the Illinois Whistleblower Act.
Give covered employees clear notice of these rights by continuous posting or by a yearly written notice they acknowledge.
Large frontier developers run an anonymous internal reporting process with monthly status updates to the reporter and quarterly sharing with officers and directors.
Example (Employee NDA template), before:
Employee shall not disclose any Confidential Information to any third party, including any government body, without the Company's prior written consent.
After:
Employee shall not disclose Confidential Information to any third party without the Company's prior written consent.
<!-- SAFETY-DISCLOSURE-CARVE-OUT -->
Nothing in this Agreement prevents Employee, without notice to or approval from the Company, from reporting to a government authority or through the Company's internal safety channel information Employee reasonably believes shows a specific and substantial danger to public health or safety from a catastrophic risk, or a violation of law. The Company will not retaliate against Employee for such a report.