Colorado's AI Act Was Repealed Before It Took Effect

Correction and update — 1 August 2026. This post was published on 15 March 2026 as a countdown to the Colorado AI Act’s 30 June 2026 effective date. That deadline never arrived. Colorado repealed SB 24-205 before it took effect and replaced it with SB 26-189, effective 1 January 2027. The original analysis is preserved below as the superseded baseline, clearly marked. We have not deleted it, because the difference between the two statutes is the useful part.

Second correction — 2 August 2026. The 1 August rewrite stated that the NIST safe-harbour architecture had survived into the successor statute, and that impact assessments and algorithmic-discrimination documentation were likely to carry forward. Both statements were wrong. They were written before we had read the signed text of SB 26-189, on an assumption of continuity that the text does not support: the successor contains no reasonable-care duty, no impact assessment requirement, no risk management mandate, no algorithmic discrimination provisions and no rebuttable presumption. The sections below have been rewritten against the signed act. We are leaving this note visible because a post arguing that you should not assume continuity had no business assuming it.

Colorado spent two years as the reference point for US AI regulation. Every state-law roundup led with it. Every consultant’s 2026 roadmap had a June 30 milestone on it.

Then it was repealed.

Not struck down, not enjoined, not delayed again — repealed and replaced by its own legislature, before a single obligation ever bound a single deployer. SB 26-189 takes its place on 1 January 2027.

If you built a Colorado workstream against SB 24-205, this is what you need to know about what you’re holding.

What Is Actually True Right Now

Three statements, and only three, are safe to make without qualification:

1. SB 24-205 never took effect. No deployer or developer was ever bound by it. There is no enforcement history, no AG guidance built on it, and no case law interpreting it.
2. SB 26-189 replaces it, effective 1 January 2027. That is the date that matters now.
3. Any obligation set decomposed from SB 24-205 is superseded, not current. That includes the 24 obligations catalogued in the original version of this post.

Everything beyond those three points required reading the successor statute against the original, clause by clause. We have now done that against the signed act, and the answer is more drastic than “some provisions moved.”

What Carries Forward: Much Less Than You Would Expect

The instinct after a repeal is to keep the workstream and re-point it at the new section numbers. Here that instinct is wrong, because SB 26-189 is not an amended version of the AI Act. It is a repeal and reenactment of the whole of part 17 — a different statute wearing the same address.

Gone entirely. The signed text contains no “reasonable care” duty, no “impact assessment” requirement, no “risk management” programme mandate, and no “algorithmic discrimination” provisions at all. The three obligations that generated most of the compliance spend under SB 24-205 were not narrowed. They were deleted.

Gone with them: the NIST safe harbour. There is no rebuttable presumption in the successor statute, and no reference to a nationally or internationally recognised risk management framework. The provision that made NIST AI RMF legally load-bearing in Colorado no longer exists. (An earlier version of this post said the safe-harbour architecture had survived the swap. That was wrong, and it was wrong because we asserted continuity before reading the successor text — see the correction note below.)

What the new statute actually requires, organised as nine sections that reuse the old numbers for new content:

• 6-1-1701 — Definitions. Reframed around “automated decision-making technology” (ADMT) rather than “high-risk artificial intelligence system.”
• 6-1-1702 — Developer responsibilities: documentation.
• 6-1-1703 — Deployer record keeping.
• 6-1-1704 — Deployer disclosures, including a point-of-interaction notice.
• 6-1-1705 — Consumer rights: correction of factually incorrect data, and the right to request meaningful human review and reconsideration after an adverse consequential decision.
• 6-1-1706 — Enforcement by the Attorney General, as a deceptive trade practice.
• 6-1-1707 — Liability, fault and allocation, expressly with no joint and several liability.
• 6-1-1708 — Interaction with other legal obligations, including carve-outs for insurers.
• 6-1-1709 — No new private right of action, and the application of other law.

Note the shape of the back half. Four of the nine sections — a third of the statute by section count — are about liability allocation, enforcement channel and interaction with existing law rather than about anything a deployer must do. That is the signature of a bill written to reduce exposure rather than to create a compliance programme, and it is the clearest signal of what changed between the two Acts.

The section-number trap. Because part 17 was reenacted rather than amended, the old citations still resolve — to different provisions. Section 6-1-1703 was the developer duties and safe harbour clause; it is now deployer record keeping. Any document, control mapping or policy citing a 6-1-17xx section from the old Act is now pointing at text that says something else. Search for those citations specifically; they will not announce themselves as broken.

The practical test: for every artefact in your Colorado folder, ask whether it exists because of a genuine control need or because a Colorado section number told you to make it. Impact assessments and discrimination testing may still be worth doing — under the EU AI Act, under NIST, or on their own merits — but as of 1 January 2027 Colorado is no longer the reason.

The Safe Harbour Is Gone, and That Is the Real Story

The most consequential thing about Colorado’s original Act was never the 24 obligations. It was Section 6-1-1703(1) — the rebuttable presumption of reasonable care for organisations following “a nationally or internationally recognised risk management framework.” That single clause is what made NIST AI RMF legally load-bearing in the United States rather than merely advisable.

It did not survive. The signed text of SB 26-189 contains no rebuttable presumption and no reference to a recognised risk management framework.

The consequence is easy to state and awkward to absorb: in Colorado, NIST AI RMF alignment no longer buys you a legal position. It remains good practice, it remains the reference framework for federal procurement, and it still maps onto EU AI Act Article 9 and ISO 42001. But the specific argument — “we followed NIST, so the burden is on the regulator to show that was inadequate” — no longer has a Colorado statute behind it.

If you sold NIST alignment to a board on the strength of the Colorado safe harbour, that business case needs rewriting before 1 January 2027. The work is still defensible on its merits. The legal shield it was bought for is not there any more.

This is also a caution about the pattern-spotting that dominated 2025 commentary, including ours. “The NIST safe harbour is spreading” was a reasonable read of the evidence at the time. It described a trend that then reversed in its origin state within two years. Frameworks are durable; the statutory hooks into them are not, and a compliance programme should not depend on one holding still.

The Superseded Baseline: SB 24-205’s 24 Obligations

Retained for reference and for delta comparison against SB 26-189. These are not current obligations. Do not build a compliance programme against this list.

Colorado’s original Act grouped into five categories:

Risk management (5) — implement a risk management policy and programme for high-risk systems; complete an impact assessment before deployment; review and update it after material change; identify and document foreseeable risks of algorithmic discrimination; map the data inputs and outputs used in consequential decisions.

Transparency and disclosure (8) — notify consumers that AI is being used in a consequential decision about them; provide a plain-language description of the system’s purpose and role; inform consumers of opt-out and appeal rights; publish a website statement describing deployed high-risk systems; developer disclosure of known limitations, intended uses and foreseeable misuses; developer documentation sufficient for deployer impact assessments; developer website statement; explanation of the principal reasons for a decision.

Governance and accountability (5) — reasonable care by deployers against algorithmic discrimination; reasonable care by developers; records sufficient to demonstrate compliance; human oversight of consequential decisions; developer disclosure to deployers and the AG of information needed to understand system outputs.

Consumer rights (3) — correction of inaccurate personal data; a process to appeal a consequential decision; opt-out where technically feasible.

Incident response (3) — deployer report to the AG within 90 days of discovering algorithmic discrimination; developer report to the AG and known deployers within 90 days; cooperation with AG investigations.

The original post also covered who was in scope — financial services, insurance, employment screening, healthcare, and the developer obligations that reached SaaS vendors whose customers deployed into Colorado. That scope analysis is a reasonable starting hypothesis for the successor statute. It is not a finding.

The Bigger Picture Changed Too

Colorado was supposed to be first. Instead it became the first state to reverse itself — and that is the more instructive precedent.

Texas TRAIGA, Illinois AIVIA, NYC Local Law 144, and the Oregon and California AI companion safety laws all remain on the board, each with different scope, definitions, and enforcement mechanisms. An AI system deployed across several states still faces overlapping and occasionally contradictory requirements. What Colorado added to that picture is volatility: the assumption that an enacted law will take effect as written is no longer safe.

That is the actual lesson for a compliance programme. Anchor to frameworks, which move slowly and deliberately. Track statutes, which now move quickly and sometimes backwards. Keep a dated record of which version of which law you assessed against, because “we were compliant” is a claim about a moment in time, and the moments are getting shorter.

The EU made the same point from the other direction: the Digital Omnibus pushed the AI Act’s high-risk regime from 2 August 2026 out to 2 December 2027 for Annex III systems and 2 August 2028 for Annex I. Two major regimes, two reschedules, one year.

Browse the current obligation database — including which entries are flagged superseded and why — at regulume.com/compliance. No account required.

ReguLume decomposes AI and data regulations to the article level and tracks what changes between versions. Superseded obligations are flagged, not deleted, so you can always see what moved.