US AI compliance dates move in both directions

California's AI Transparency Act becomes operative today. SB 942 was signed in September 2024 with a January 1, 2026 date; AB 853 moved it to August 2, 2026. Generative AI providers with more than a million monthly users must now ship a free AI-detection tool, and hosting-platform obligations follow on January 1, 2027.

Two months ago Colorado moved in the opposite direction. SB 189, signed May 14, pushed the Colorado AI Act from June 30, 2026 to January 1, 2027 — and in the same bill eliminated the duty of care against algorithmic discrimination, deployer impact assessments, and attorney-general reporting.

Meanwhile Illinois HB 3773 has simply been live since January 1, requiring employer notice wherever AI touches hiring, promotion, discipline, or discharge.

Three states, three trajectories, inside one summer.

A delay is not a pause

The commentary I keep reading treats Colorado's postponement as breathing room — don't read that as a pass, one newsletter warned its small-business audience.

I think that advice is right for the wrong reason, and the difference matters if you are allocating engineering time. For the framework as originally passed, the delay largely was a pass. The duty of care is gone. The impact assessments are gone. A team that spent the first half of 2026 building toward Colorado's original obligations built for a statute that no longer exists.

Which is the actual lesson, and it is not the reassuring one:

A delay window is not a grace period. It is the period during which the law's substance gets renegotiated. Postponement and amendment travel together, because the same pressure that wins a later date is still applying while the clock is stopped. Colorado's delay removed obligations. California's delay added them — AB 853 extended duties to hosting platforms and explicitly cited alignment with EU AI Act Article 50 provenance timelines.

So the direction of movement is genuinely unpredictable. What is predictable is that a statute under postponement is a statute being edited.

The rule I would put on the launch checklist

Treat statutes the way you already treat model deprecations.

Maintain a statute calendar with version numbers. Not a list of dates — a list of dates and the specific version of the obligation attached to each, re-checked at every delay announcement. When a date moves, the correct engineering response is not to relax; it is to diff the text. What survived, what was struck, what was added. That diff is the actual input to your roadmap, and it is available publicly, and almost nobody reads it because the headline says "delayed."

This is unglamorous work and it is cheap. An hour per state per quarter, kept by someone with a name against it, is enough to stop a team from either over-building toward removed obligations or getting surprised by added ones. Compared to the cost of shipping a feature into the wrong regime, it is nothing.

Where this lands for a product team

Any feature that screens résumés, converses with customers, or generates public-facing content is already inside this patchwork. Not eventually — now, in at least one state.

At Trigent the version of this that bites is subtler than "are we compliant." A client builds an AI feature, does the diligence against the statute as it reads during the build, and ships six months later into a text that changed while they were building. The compliance memo in the repository is accurate as of a date nobody wrote down. When someone asks whether the feature meets the current obligation, reconstructing which version was assessed takes longer than the original assessment did.

What has helped is embarrassingly small: stamping the statute version and assessment date directly into the feature's own documentation, so the artifact carries its own expiry. It makes the re-check trivial and it makes staleness visible instead of assumed. It is the same instinct as pinning a dependency — you are not preventing change, you are making change detectable.

Two things I could not pin down

I want to be honest about the edges, because both bear on who is actually in scope.

SB 942's threshold is more than one million monthly users, and I could not establish how that counts API consumers or enterprise seats. The statute text addresses visitors or users of publicly accessible systems; I found no regulator guidance resolving the enterprise case. If your product sits near that line, that ambiguity is your problem to raise with counsel, not one to resolve from a blog post.

And Illinois's proposed IDHR rules were withdrawn, which appears to leave the mechanics of the notice requirement underspecified even though the requirement itself is live. I could not confirm what fills that gap.

Both uncertainties point the same way: the obligation is real, the operational detail is not settled, and the honest posture is to build for the requirement while tracking the guidance.

Dates move in both directions and the text moves with them — so version your statute calendar and diff it every time a deadline slips.