The Colorado AI Act — twice delayed and substantially narrowed — is now scheduled to become enforceable January 1, 2027, making it the first broad US state law to regulate consequential automated decisions about consumers. If your AI agents or models influence decisions about employment, lending, housing, insurance, education, healthcare, legal services, or essential government services for Colorado residents, this law will apply to you, and its obligations are concrete enough to translate directly into engineering work now, ahead of the effective date.

Update, August 2026: the original law (SB24-205, enacted 2024) was set to take effect February 1, 2026. SB 25B-004, signed August 28, 2025, pushed that to June 30, 2026. SB 189, signed by Governor Polis on May 14, 2026, delayed it again to January 1, 2027 — and did more than delay it. SB 189 repeals and reenacts the statute, dropping the original standalone duty of reasonable care against algorithmic discrimination and the deployer risk-management-program and impact-assessment mandates. In their place, the reenacted law centers on "automated decision-making technology" (ADMT) that materially influences a consequential decision: developers owe deployers technical documentation, deployers owe consumers notice and a path to request human review of adverse decisions, and the Attorney General enforces the act as a deceptive trade practice under the Colorado Consumer Protection Act (with a 60-day cure period through January 1, 2030). There is still no private right of action. The sections below describe the fuller 2024 framework for teams that already built toward it; treat the ADMT-centered obligations as the current baseline.

As of August 2026, US teams face regulatory pressure on two timelines: Colorado's narrowed law takes effect January 1, 2027, and the EU AI Act's Article 50 transparency obligations land on 2 August 2026 (with Annex III high-risk obligations following on 2 December 2027 after the Digital Omnibus delay — see what changed in the 2026 Omnibus). The efficient response is one control program that satisfies both, and this post maps the Colorado half.

What the Colorado AI Act regulates

The law regulates "high-risk artificial intelligence systems" — AI that makes, or is a substantial factor in making, a consequential decision about a consumer. A consequential decision is one with material legal or similarly significant effect on a person's access to or cost of things like employment, education enrollment or opportunity, financial or lending services, essential government services, healthcare services, housing, insurance, or legal services.

Two things follow for engineers. First, classification is use-based, not model-based — the same LLM is out of scope drafting marketing copy and in scope scoring loan applications, exactly the pattern the EU AI Act's classification logic follows. Second, "substantial factor" matters: an agent that produces a recommendation a human rubber-stamps is not automatically out of scope. If the system's output meaningfully drives the decision, treat it as in scope.

As originally enacted, the core legal duty was reasonable care to protect consumers from algorithmic discrimination — unlawful differential treatment or impact on the basis of protected characteristics. SB 189 (see the update above) replaced that standalone duty with narrower, ADMT-specific disclosure and human-review obligations; the discrimination-prevention framing below reflects the pre-amendment law but still shapes the role-specific obligations the engineering checklist is built from.

Developer obligations: documentation and disclosure

The obligations below describe the law as originally enacted in 2024. SB 189 (see the update above) kept the core documentation duty but dropped some of the surrounding disclosure requirements — confirm current scope with counsel before treating this list as exhaustive.

If you build or substantially modify a high-risk AI system that others deploy, your duties center on giving deployers what they need to use it responsibly. In engineering terms:

  • System documentation describing intended uses, known limitations, the data used to train the system at a summary level, and known or reasonably foreseeable risks of algorithmic discrimination.
  • Deployment guidance — how the system should be used, monitored, and what human oversight it expects.
  • A public statement summarizing the types of high-risk systems you develop and how you manage discrimination risk.
  • Incident reporting — disclosing to deployers (and the Colorado Attorney General where required) when you learn the system has caused or is reasonably likely to cause algorithmic discrimination.

If your product includes agentic components — systems that act, not just score — this documentation needs to cover the action surface too: what tools the agent can invoke and what boundaries constrain it. Maintaining that answer is an agent inventory problem before it is a legal-drafting problem.

Deployer obligations: the original risk management program

SB 189 removed the standalone risk-management-program and impact-assessment mandates described in this section (see the update above). What remains as the current baseline is consumer notice and a right to request human review. The list below is retained as useful engineering practice and as the requirement set for teams operating under the pre-SB 189 window or a stricter comparable regime (such as the EU AI Act), not as Colorado's current statutory minimum.

If you use a high-risk AI system to make consequential decisions, the obligations as originally enacted were heavier and more operational:

  • A risk management policy and program governing the deployment — iterative, regularly reviewed, and reasonable relative to your size and the system's risk. The statute points to recognized frameworks, notably the NIST AI Risk Management Framework, as the reference for what reasonable looks like; if you have mapped controls to it, that work carries over directly (see applying the NIST AI RMF to agents).
  • Impact assessments — per system, at deployment and on a recurring basis and after substantial modification, covering purpose, discrimination risk analysis, data categories, performance metrics, and post-deployment monitoring.
  • Consumer notices — telling consumers when a high-risk system is involved in a consequential decision about them, and, for adverse decisions, providing the reason, an opportunity to correct inaccurate personal data, and an opportunity to appeal to human review where feasible.
  • AG notification when you discover the system has caused algorithmic discrimination.

The consumer-notice and appeal provisions are product requirements, not policy documents: your decision flow needs a notice surface, a data-correction path, and a human review path wired into the workflow that the agent or model actually runs in.

The engineering control stack, concretely

Strip away the statutory language and the Colorado AI Act asks for the same infrastructure a serious governance program already builds:

  1. Inventory and classification. Know every AI system in use, flag which ones touch consequential decisions for Colorado consumers, and record the reasoning. Classification drives everything else.
  2. Attributable decisions. When a consumer appeals or the AG asks, you must reconstruct what the system did in a specific case. That requires per-decision logging with identity attribution — which agent, which model version, which inputs — in an audit trail that holds up rather than application logs that rotate away.
  3. Bias and performance monitoring. Impact assessments require evidence about outcomes, not intentions: performance metrics, known limitations, and monitoring for discriminatory drift after deployment.
  4. Human oversight paths. The appeal right assumes a human can meaningfully review and override the system's decision — with enough context surfaced to make the review real.
  5. Evidence generation. Risk programs, impact assessments, and incident reports are recurring documents. Producing them from live platform state — actual configurations, actual logs — is dramatically cheaper than reconstructing them by hand each cycle.

This is the same stack the EU AI Act's high-risk obligations demand by 2 December 2027, which is the practical argument for one combined program: classify once, log once, build oversight once, and map the evidence outward to each regulation — including the narrower notice-and-human-review baseline Colorado now sets on its own timeline. The complete AI governance guide covers that combined architecture.

Common questions

When does the Colorado AI Act become enforceable? January 1, 2027. The original February 2026 effective date was pushed to June 30, 2026 by SB 25B-004 (signed August 28, 2025), then pushed again — and the law's scope narrowed — by SB 189 (signed May 14, 2026). Enforcement sits with the Colorado Attorney General under the Colorado Consumer Protection Act, with a 60-day cure period through January 1, 2030; the statute does not create a private right of action.

Does the law apply to companies outside Colorado? Yes, if you do business in Colorado and your high-risk systems make consequential decisions about Colorado residents. Like the GDPR and EU AI Act, the trigger is where the affected people are, not where your company is incorporated.

We only use third-party AI products — are we off the hook? No. Using someone else's high-risk system to make consequential decisions makes you a deployer, with the consumer-notice and human-review obligations that are the current baseline (and the fuller risk-program and impact-assessment practices described above, if you keep operating to that standard). Your vendor's developer documentation is an input to your compliance, not a substitute for it.

How does this relate to our EU AI Act program? The overlap is substantial: use-based classification, risk management referenced to recognized frameworks, human oversight, consumer transparency, and documented evidence. If you run a combined readiness program — see GDPR and EU AI Act readiness for the pattern — add Colorado as a third mapping target rather than building a separate track.

Is there an exemption for small companies? The statute includes narrow carve-outs for entities that already comply with comparable legal obligations, but the ADMT notice and human-review duties are broadly framed. If you make consequential decisions with AI at any scale, assume the law is relevant and get a specific legal read rather than assuming an exemption.