Colorado Rewrote Its AI Law. Here’s What Governance Practitioners Need to Do Before January 2027.

Colorado’s SB 26-189 passed both chambers on May 9, 2026, and is heading to the governor’s desk. Most coverage frames this as a lighter-touch replacement for the state’s first-in-the-nation AI antidiscrimination law. That framing isn’t wrong, but it’s incomplete in ways that matter a great deal if you’re the one who has to actually build and operate AI governance systems. Below is a practitioner-level breakdown of what changed, five implications, and what this means operationally for your governance stack.

In 2024, Colorado passed SB 24-205 — the first state law in the US to require mandatory algorithmic bias audits and risk impact assessments for AI systems used in high-stakes decisions. The business and tech communities pushed back, arguing the requirements were technically unworkable. After a failed 2025 legislative session, a federal court TRO, and a governor-convened working group, the legislature agreed to scrap the original and start fresh.

SB 26-189, sponsored by Senator Rodriguez, takes a fundamentally different approach. The mandatory audit and risk assessment requirements are gone. What replaces them is a transparency-and-notice framework built around a new concept: the “covered ADMT.”

The law covers “Automated Decision-Making Technology” (ADMT) that “materially influences” a “consequential decision” (meaning decisions about employment, education, housing, financial services, insurance, healthcare, or essential government services). If your AI tool touches any of those domains and affects outcomes, you’re in scope. The law takes effect January 1, 2027, with the attorney general required to complete rulemaking before then.

SB 24-205 (repealed):

• Mandatory bias audits before deployment
• Algorithmic impact assessments
• Broad developer obligations regardless of use case
• No fault allocation framework between developers and deployers
• Effective February 2026 (later delayed, then blocked by TRO)

SB 26-189 (new law, headed to the governor for signature):

• Transparency and notice framework
• Post-adverse-outcome disclosure rights within 30 days
• Developer-deployer fault split based on documented intended use
• Consumer right to meaningful human review
• Effective January 1, 2027

The original law was built on a preventive theory: audit before you deploy, assess the risks, and fix the problems first. The new law is built on a reactive theory: deploy, then explain when things go wrong. This is the difference between a pre-flight checklist and a crash investigation protocol. Both are safety systems. They produce entirely different organizational behaviors.

The new law doesn’t require you to prove your AI is safe before deployment. It requires you to explain what it did after it has already affected someone adversely. If you’ve been building your governance program around bias audits and pre-deployment assessments, that work still protects you under the discrimination law that this act explicitly does not replace, but the compliance floor just changed underneath you.

This is the one most practitioners haven’t flagged yet. It states that any contract provision that “purports to indemnify, defend, or hold harmless” a party from liability for their own ADMT-related discrimination under Colorado anti-discrimination law is “contrary to public policy and void.”

Most enterprise AI vendor contracts include exactly these kinds of indemnification and hold-harmless clauses. If those contracts cover consequential decisions affecting Colorado consumers or employees, those specific clauses may now be unenforceable. This is not legal advice, and you should get qualified counsel to review your specific contracts. But this provision is likely to be missed on first read because the overall law is being described as “lighter regulation.”

“Any provision of a contract that purports to indemnify, defend, or hold harmless… from or against any liability for damages resulting from the developer’s or deployer’s own acts or omissions… is contrary to public policy and void.” — SB 26-189, Section 6-1-1707(7)

The liability framework works like this: if a deployer uses an AI system in a way that’s consistent with how the developer documented and marketed it, the developer shares liability for discrimination outcomes. If the deployer goes off-script using the system outside its documented intended use, the developer is off the hook, and the deployer owns it entirely.

This creates a powerful incentive around documentation. Developers who ship thorough, specific documentation of intended uses, known limitations, and human review guidance are protecting themselves. Deployers who verify that their actual use cases match the documented scope are protecting themselves. Anyone treating documentation as a box-checking exercise is creating a liability gap. The governance implication is direct: you need a system that can produce an auditable record of which ADMT version was in use, what its documented intended use was, and whether your deployment matched it.

The law defines meaningful human review as review by someone who: (a) considers relevant primary evidence, (b) is trained to conduct the review, (c) does not default to the system output, and (d) has access to the ADMT’s intended use, material limitations, categories of inputs, and principal factors used to generate the output — without requiring disclosure of trade secrets.

At organizations processing thousands of AI-influenced decisions per day, you need a systematic mechanism that gives human reviewers enough information to override a system recommendation, without that mechanism becoming a documentation wrapper for rubber-stamping AI decisions. The “does not default to the system output” requirement is where this gets operationally hard. How do you design and audit for that at scale? This is where the attorney general’s rulemaking process will matter a great deal. The window between now and the January 2027 deadline is when to engage if you want to influence what those rules look like.

When a covered ADMT materially influences a consequential decision that results in an adverse outcome, you have 30 days to provide the consumer with a plain-language description of the ADMT’s role, the types and sources of data used, and an explanation of their rights, including the right to request human review.

To hit that window reliably, you need to know three things in real time: (1) which decisions were materially influenced by which ADMT, (2) which of those decisions constituted an “adverse outcome” as defined by the law, and (3) enough detail about the specific decision to produce the disclosure. Most organizations cannot currently answer all three of those questions consistently across their AI deployments. Critically, the 30-day clock doesn’t start from when you realize there was an adverse outcome — it starts from when the decision was made.

To hit that window reliably, you need to know three things in real time: (1) which decisions were materially influenced by which ADMT, (2) which of those decisions constituted an “adverse outcome” as defined by the law, and (3) enough detail about the specific decision to produce the disclosure. Most organizations cannot currently answer all three of those questions consistently across their AI deployments. Critically, the 30-day clock doesn’t start from when you realize there was an adverse outcome — it starts from when the decision was made.

The law defines “materially influence” as when an ADMT output is a non-de minimis factor that affects the outcome of a consequential decision — constraining, ranking, scoring, recommending, classifying, or meaningfully altering how the decision gets made. Incidental, trivial, or clerical uses don’t count.

That middle ground will be a litigation battleground. Every company with a hiring tool or loan underwriting system is going to try to characterize their AI as “informing” rather than “influencing.” The attorney general gets to adopt rules clarifying this definition with “presumptions, illustrative examples, and objective indicators.” Those rules don’t have to exist until January 2027. The space between now and then is where you want to build a paper trail showing how your systems actually function.

The compliance requirements in SB 26-189 are not achievable with spreadsheets, manual documentation practices, or ad-hoc vendor questionnaires. The law creates obligations that require real-time tracking, version-linked audit trails, and systematic human oversight workflows. Here is how the specific obligations map to operational capabilities:

Covered ADMT identification (Sec. 6-1-1701)
You need a live inventory of every deployed model, agent, and workflow, tagged by domain (employment, healthcare, housing, etc.) and risk tier. Without this inventory, you don’t know what you owe disclosures for, and you can’t determine which systems qualify as “covered ADMTs” under the consequential decision test.

3-year recordkeeping (Sec. 6-1-1702 & 6-1-1703)
Immutable, version-linked audit logs satisfy both the developer documentation requirements and the deployer compliance recordkeeping requirements. Every material update notification from a vendor needs to be captured and linked to the deployment record, so you know which ADMT version was active when each consequential decision was made.

30-day adverse outcome disclosure (Sec. 6-1-1704)
You need real-time decision tracking tied to outcome data so you can identify adverse outcomes as they occur. Automated disclosure generation using documentation linked to the specific ADMT version that influenced the decision makes the 30-day window operationally achievable.

Meaningful human review (Sec. 6-1-1705)
This is the hardest one to operationalize. You need a workflow where reviewers have authority to override, access to the ADMT’s limitations and input categories, and a structured process that prevents rubber-stamping the AI output. Human-in-the-loop approval workflows with override logging create an auditable record that real review actually happened.

Developer-deployer liability split (Sec. 6-1-1707)
Maintain documented records of your vendor’s stated intended use for each ADMT, alongside your internal use case documentation. If your deployment ever deviates from documented scope, that deviation needs to be flagged and resolved before it creates a liability gap. Governance at runtime is what matters here.

Bias and discrimination evidence
The new law doesn’t require bias audits. Proactive fairness monitoring is still your protection against discrimination claims under existing law. The absence of a bias audit mandate does not mean the absence of discrimination risk.

Colorado’s rewrite is genuinely more workable than what it replaced. The mandatory bias audit requirements were creating a compliance environment that was hard to meet even for well-resourced organizations. The new transparency-and-notice framework is operationally more tractable.

But “more workable” is different from “easy.” The law creates real obligations around documentation, adverse outcome tracking, and human review workflow design. Organizations that treat this as a documentation checkbox exercise will be surprised. Organizations that build real governance infrastructure will have compliance as a byproduct of operating their AI systems responsibly.

And regardless of what this law requires, the Colorado Anti-Discrimination Act is still fully intact. Using AI in ways that produce discriminatory outcomes in employment, housing, or financial services remains a legal problem. The governance work you do to comply with SB 26-189 is the same work that protects you under the law that this act explicitly does not limit or replace.

This post is for informational purposes only and does not constitute legal advice. Consult qualified legal counsel for advice specific to your situation.

• SB 26-189 — Official Colorado General Assembly bill page
• SB 26-189 — Fiscal Note, Colorado Legislative Council Staff (PDF)