State AI Transparency Law Requirements: What Illinois's New Law Actually Means for Builders

Illinois became the third state to sign a comprehensive AI safety law in July 2026, following California and New York. If you ship AI products, you now face a growing mesh of state ai transparency law requirements that differ in scope, timing, and enforcement teeth. Most coverage of these laws blurs the line between who is actually covered and who is not. This piece draws that line clearly, walks through the obligations that matter for different kinds of builders, and offers a framework for deciding how to comply when the rules themselves are still shifting underneath you.

Key Takeaways

• Illinois's AISMA only applies to developers training models above roughly 10²⁶ compute operations with $500M+ annual revenue (for most obligations). If you are integrating someone else's model, AISMA does not cover you directly, but other state laws almost certainly do.
• The "big three" (California, New York, Illinois) is already a "big four" with Connecticut adopting comparable rules, and the combined market weight of these states functions as a de facto national standard even without federal legislation.
• A federal executive order created a task force to challenge state AI laws on preemption grounds, but the legal theory is untested, the carve-outs are broad, and courts could take years to resolve the question. Building to the strictest current standard is the safer bet.
• Most AI builders will feel the bite of deployer-side obligations (disclosure, impact assessments, human-review rights) under laws like Colorado's, not the frontier-model rules grabbing headlines.
• Illinois is the first state to mandate independent third-party audits of frontier AI developers, a template other states are likely to copy, which makes privacy-by-architecture and clean audit logs a structural advantage rather than a nice-to-have.

What Did Illinois Actually Pass?

Governor Pritzker signed SB 315, the Artificial Intelligence Safety Measures Act (AISMA), on July 6, 2026. The law creates transparency, safety, and reporting requirements for developers of frontier AI models. Its most notable feature: a first-in-the-nation mandate for annual independent third-party audits of covered developers' compliance.

The law structures its obligations in two tiers. The full framework and audit duties apply only to entities that (a) train a frontier AI model using more than approximately 10²⁶ computing operations and (b) generate more than $500 million in annual gross revenue. A second, narrower set of obligations (incident reporting and whistleblower protections) applies to any developer crossing the compute threshold, regardless of revenue.

If you are a company that uses AI tools but does not train frontier-scale models, AISMA explicitly does not cover you. That matters. Most builders reading headlines about "Illinois's nation-leading AI law" will assume it applies to them. It probably does not. But keep reading, because something else almost certainly does.

Who Is Actually Covered by AISMA?

A very small number of organizations. Right now, only a handful of models exceed the 10²⁶ FLOPs threshold. Analysts project roughly 30 such models will exist by 2027, and over 200 by 2030. So the regulated population will expand, but for the moment this is a law aimed squarely at frontier labs, not at a team fine-tuning a model for customer support or building a retrieval-augmented generation pipeline.

The geographic reach is broader than you might expect, though. The law applies to any developer whose models are accessible to users in Illinois, not just developers headquartered there. The same principle holds for California's TFAIA and New York's RAISE Act. If your frontier model can be accessed by someone in Chicago, Springfield, or Peoria, you are subject to AISMA regardless of where your servers sit.

What Are AISMA's Core Obligations?

For covered developers, the requirements break down into a few categories.

Incident Reporting

Covered developers must report a critical safety incident to the state within 72 hours of discovering it. If the incident poses an imminent risk of death or serious physical injury, that window tightens to 24 hours. This is breach-notification-style urgency applied to AI safety events, a structure familiar to anyone who has dealt with data breach laws but novel in the AI context.

Annual Independent Audits

The audit mandate is the headline feature. No other U.S. state requires this yet. Covered entities must retain independent auditors to assess compliance annually. The audit provisions take effect January 1, 2028, giving covered developers roughly 18 months from the signing date to build audit-ready governance.

Whistleblower Protections

These apply to any frontier developer crossing the compute threshold, regardless of revenue. The protections are separate from Illinois's existing whistleblower statute.

Enforcement

There is no private right of action under AISMA. Enforcement sits exclusively with the Illinois Attorney General's office. That matters for your risk calculus: you are not facing a wave of class-action litigation under this specific law, though an employee could still bring claims under existing Illinois whistleblower statutes.

How Does Illinois Compare to California and New York?

The three laws are close cousins built on similar templates, but they diverge on timing and specifics.

California's TFAIA went into effect on January 1, 2026. Both AISMA and New York's RAISE Act take effect on January 1, 2027, though AISMA's audit provisions lag by another year to January 1, 2028.

The compute threshold is consistent across all three: approximately 10²⁶ operations. This is worth comparing to the EU AI Act, which sets its threshold at 10²⁵ FLOPs for "general-purpose AI models," meaning the U.S. state laws regulate fewer models than the EU framework does, at least for now.

The revenue threshold ($500M for the full framework obligations) appears in Illinois's tiered structure but is not identically replicated in every peer statute. If you are building a compliance matrix, read each law's text for the specific triggers.

Connecticut has also joined the pattern. SB 5, the Connecticut Artificial Intelligence Responsibility and Transparency Act, adopts comparable protections using the same 10²⁶-operation and $500M thresholds, with anti-retaliation effective October 1, 2026, and anonymous reporting channels required by January 1, 2027. The "big three" is already a big four.

Lawmakers estimate these states account for roughly 40% of the U.S. AI market, which is why they frame this cluster as establishing a de facto national standard even in the absence of federal legislation.

What About All the Other State AI Laws?

Here is where the picture gets more complicated and more relevant to most readers. The frontier-model laws get the headlines, but the volume of state AI legislation is much broader.

In January 2024, exactly two states had enacted AI-specific legislation. By March 2026, that number had grown to nineteen, with active bills pending in another fourteen. More than 1,000 AI-related bills were introduced across all U.S. states and territories in 2025 alone, though counts vary depending on methodology.

Most of these laws do not target frontier model developers. They target deployers: companies that use AI systems in consumer-facing or employment-related decisions. If you build a product that uses a frontier model via API to make decisions about people (hiring, lending, insurance, housing), you are almost certainly subject to deployer-side obligations in one or more states, and those obligations exist independently of whether the model developer is covered by AISMA.

Does Colorado's AI Act Apply to My Product?

Probably, if your product uses AI to make or substantially support "consequential decisions" about Colorado residents. Colorado's AI Act took effect June 30, 2026, and it is described as the broadest U.S. state AI law so far. It creates disclosure and appeal requirements for AI systems involved in consequential decisions, which the law defines broadly across employment, financial services, healthcare, housing, insurance, and education.

The key difference from AISMA: Colorado's law does not care about your compute budget. It cares about what your product does and who it affects. A ten-person startup fine-tuning an open-source model to screen job applicants is squarely within scope if it serves Colorado residents.

The federal executive order from December 2025 explicitly calls out Colorado's AI Act as an example of a problematic state law, and analysis suggests testing its legality could be a priority for the DOJ's AI Litigation Task Force. But that challenge has not happened yet, and the law is currently in effect.

Will Federal Preemption Kill These State Laws?

Maybe. Eventually. Or maybe not. This is the hardest question for builders right now, and the honest answer is that nobody knows.

On December 11, 2025, the Trump administration issued Executive Order 14365, "Ensuring a National Policy Framework for Artificial Intelligence", which created an AI Litigation Task Force within DOJ. The task force's job is to challenge state AI laws that are inconsistent with federal policy, including on grounds like interference with interstate commerce, preemption by existing federal regulations, and First Amendment concerns.

But legal analysts note that preemption is not automatic. The most likely theory is implied conflict preemption, under which a state law is preempted only to the extent it actually obstructs federal objectives. That is a fact-intensive, case-by-case determination that courts resolve slowly.

The executive order also carves out certain categories of state law from its preemption push: child safety protections, AI compute and data center infrastructure, state government procurement and use of AI, and "other topics yet to be determined." Those carve-outs are broad enough that significant chunks of state AI regulation may survive even a successful preemption campaign.

For a builder, this means you face a choice. You can bet on preemption, build to a minimal standard, and hope the courts strike down the state laws before enforcement catches up to you. Or you can build to the strictest current standard and treat any future rollback as a windfall rather than a retroactive fix. We take the second approach. Reversing privacy and transparency commitments after they have been made is corrosive to user trust in a way that over-complying never is.

Which Obligations Apply to a Typical AI Startup?

If you are not training models at frontier scale (and if you have to ask, you are not), AISMA and its peer statutes are not your problem. Your problem is the deployer-side layer of state regulation, which is already in effect in multiple jurisdictions and growing fast.

Here is a rough map of the obligation categories that apply to builders who use AI models rather than train them:

• Consumer disclosure. Several states require you to tell users when they are interacting with an AI system, or when AI is materially involved in a decision affecting them. The specific triggers and language vary by state.
• Impact assessments. Colorado and comparable laws require deployers to conduct impact assessments for high-risk AI systems before deploying them. If your product makes or supports consequential decisions, you need a documented assessment of bias risks, data practices, and mitigation steps.
• Human review rights. Some state frameworks require that individuals subject to AI-driven consequential decisions have the right to request human review. This is not a technical nicety. It means your system architecture needs to support a human-in-the-loop escalation path.
• Vendor accountability. State frameworks impose obligations on businesses that deploy or use AI in operations, not only on technology developers. Gaps in your vendor contracts create compliance risk. If your model provider's terms do not cover the disclosures and audit access you need, you hold the bag.

The practical upshot: your compliance responsibility does not pass through to your vendor. If you call a frontier model's API and use its output to deny someone a loan or screen out a job applicant, you own the compliance obligation for that decision in the states where it has consequences.

How Should You Structure Your Compliance Stack?

Start with architecture, not policy documents. A compliance program built on top of a system that was not designed for auditability is expensive to maintain and brittle under scrutiny. A system designed from the start with minimal data retention, clear audit trails, and explainable decision paths is structurally cheaper to certify.

Some concrete steps:

1. Map your jurisdictional exposure. If your product is accessible to users in California, New York, Illinois, Connecticut, or Colorado, assume you are subject to the rules of each. Geographic filtering is fragile and usually not worth the engineering cost relative to just complying.
2. Classify your use cases by risk tier. Not all AI features carry the same regulatory weight. A chatbot answering FAQs is a different animal from a system that scores creditworthiness. Classify first, then scope your compliance effort to the highest-risk features.
3. Audit your vendor contracts now. Check whether your model provider's terms give you the disclosure rights, data handling commitments, and audit access you will need. If they do not, renegotiate before enforcement actions start landing.
4. Build the human-review path before you need it. If any of your features could be classified as making or supporting a consequential decision, the escalation path to a human reviewer should exist in your product today, not as a roadmap item for Q3.
5. Document your impact assessments. Even if you are not sure whether a specific state law requires one for your use case, having a documented assessment of bias risk, data provenance, and mitigation steps is cheap insurance and increasingly expected by enterprise customers regardless of the legal requirement.

Why Does the Audit Mandate Matter Even If You Are Not Covered?

Illinois's independent audit requirement is the first of its kind, but it will not be the last. Connecticut is already on the same trajectory. When audit mandates become common, two things happen. First, the audit firms and standards that emerge from Illinois's implementation will become the template that other states adopt, creating a feedback loop that locks in specific compliance frameworks. Second, enterprise buyers start requiring their vendors to be "audit-ready" even when the vendor is not legally obligated to undergo one, because the buyer's own compliance depends on demonstrating downstream diligence.

If you build your product with clean audit logs, documented model governance, and verifiable data handling practices from the start, you are positioned well for both of those dynamics. If you bolt compliance on later, you pay a retrofit tax that compounds with every new state that adopts the template.

What Is the Real Builder's Dilemma Here?

It is not the text of any single law. It is the uncertainty about which laws will survive and which will be preempted, combined with the certainty that new laws will keep arriving while the preemption question works its way through courts.

The federal preemption strategy is real but untested. The most aggressive reading of the executive order would render most state AI laws vulnerable, but that reading depends on legal theories that have not been adjudicated, and the carve-outs for child safety, procurement, and infrastructure leave a lot of state authority intact. Even if the DOJ brings challenges, the cases will take time. Meanwhile, the state laws are enforceable today (or within months).

A founder has three options:

• Build to the strictest standard. Treat the combined requirements of California, New York, Illinois, Connecticut, and Colorado as your compliance floor. This costs more upfront but eliminates jurisdictional guesswork and positions you as trustworthy to users and enterprise buyers who care about governance.
• Build to a minimum and wait. Hope that preemption arrives before enforcement does. This is cheaper in the short term but creates a credibility problem if preemption fails or takes years.
• Build selectively by jurisdiction. Comply with the laws of states where you have the most users or revenue exposure, and accept the risk elsewhere. This is a viable middle path for resource-constrained teams, but it requires careful jurisdictional mapping.

We chose the first option. Not because we think every state law is perfectly drafted (they are not), but because privacy and transparency commitments are product commitments, not legal checkboxes. Once you tell users their data is handled a certain way, walking that back is worse than the marginal cost of over-compliance. The regulatory patchwork is a hassle, but it also functions as a forcing function for building products that respect users by default rather than by exception.

What Should You Watch Next?

Three things are worth tracking over the next 12 months.

First, whether the DOJ AI Litigation Task Force actually files challenges, and if so, which state laws it targets first. Colorado appears to be a likely early target, given the executive order's explicit mention. A loss for the DOJ in its first challenge would effectively validate the state-law approach and accelerate adoption in other states.

Second, how many models cross the 10²⁶ compute threshold by January 2027, when AISMA's main provisions take effect. The number of regulated entities under these frontier-model laws is currently small, but it is set to grow significantly. If your organization is training increasingly large models, monitor whether your next training run crosses the threshold.

Third, whether more states adopt deployer-side obligations modeled on Colorado's framework. The frontier-model laws affect a handful of labs. The deployer-side laws affect everyone building products with AI. The latter category is where the compliance burden will land for most readers of this piece, and the pace of adoption there is faster than most teams realize.

The patchwork is messy. It will probably stay messy for a while. The builders who treat that messiness as a design constraint rather than a legal annoyance will ship products that are both more compliant and more trusted.

If you want an AI assistant built with these principles from the ground up, start a free 7-day trial, no card required.

Michael C.

Founder & Principal Engineer, Selina Labs

Michael builds Selina, a privacy-first AI that remembers you across conversations. He ships security-sensitive AI in production — real attacks, real fixes, measured in minutes and dollars — and writes about privacy, security, and LLMs from that seat. Top Rated Plus and expert-verified on Upwork.

• www.upwork.com
• x.com
• medium.com
• selinalabs.io