The Colorado AI Act Is Live: What It Requires and What It Doesn’t

What the Law Actually Covers

SB 205 regulates “high-risk artificial intelligence systems,” which the statute defines narrowly and specifically: an AI system that, when deployed, makes or is a substantial factor in making a consequential decision. A consequential decision, in turn, is any decision that has a material legal or similarly significant effect on a Colorado consumer’s access to or terms of education enrollment or opportunity, employment or employment opportunity, financial or lending services, essential government services, healthcare services, housing, insurance, or legal services.

That list is the heart of the statute. If your AI system touches any of those domains in a way that affects who gets access, on what terms, or for what price, you are inside the law’s scope. If it touches none of them—a writing assistant, a marketing copy generator, an internal summarization tool—you are not.

The law’s second important move is to bind both sides of the value chain. Developers are companies that build or substantially modify high-risk AI systems. Deployers are companies that put those systems into operational use. Each has its own obligations, and the deployer obligations are the ones that catch most companies off guard, because deployers tend to think of themselves as customers rather than regulated parties.

The Deployer Obligations

If you are a deployer of a high-risk AI system, the statute requires four things in practice.

First, you must implement a risk management policy and program that governs how high-risk AI systems are used in your organization. The policy must specify how you identify, document, and mitigate the risks of algorithmic discrimination. The statute does not prescribe a specific framework, but it explicitly references the NIST AI Risk Management Framework and ISO/IEC 42001 as acceptable bases. The risk management program is not a one-time artifact. It must be reviewed annually and updated as the system or its use evolves.

Second, you must complete an impact assessment for each high-risk AI system before deploying it, and again annually thereafter, and again whenever the system undergoes an intentional and substantial modification. The impact assessment is a documented analysis of the system’s purpose, intended use, benefits, foreseeable risks of algorithmic discrimination, the mitigation measures in place, the categories of data the system processes, and the metrics used to evaluate its performance. This is not a checkbox exercise; the impact assessment is the document a regulator will ask for first.

Third, you must provide consumer notice when a high-risk AI system is used to make a consequential decision about a Colorado resident. The notice must disclose, in plain language, that an AI system was used, the purpose of the system, the nature of the decision, and the consumer’s right to additional information. If the decision is adverse to the consumer, the deployer must also provide a statement of the principal reasons for the decision and an opportunity to correct any incorrect personal data the system relied on. The consumer also has a right to appeal the decision to a human reviewer where technically feasible.

Fourth, you must report any discovered algorithmic discrimination to the Colorado Attorney General within ninety days of discovery. Discovery here means actual knowledge or constructive knowledge through reasonable diligence. The reporting obligation is one of the law’s sharper edges, because it converts what would otherwise be an internal quality issue into a regulator-facing disclosure event.

What the Law Does Not Require

It is worth being precise about the things SB 205 does not do, because the surrounding commentary often overstates them.

The law does not impose a pre-market approval regime. There is no Colorado equivalent of an AI conformity assessment that a developer must pass before placing a system on the market. The EU AI Act does this; SB 205 does not.

The law does not require source code or model weights to be disclosed. Developers must provide deployers with documentation sufficient to complete an impact assessment—the system’s purpose, intended use, known limitations, and the data categories it relies on—but not the underlying model artifacts.

The law does not prohibit the use of AI in any covered domain. It does not say credit decisions cannot be automated. It says they can be automated, and that if they are, the automation must be documented, assessed, monitored, and explained to the affected consumer when the outcome is adverse.

And the law does not, by its terms, create a private right of action. Enforcement runs through the Colorado Attorney General, with the standard rebuttable presumption of compliance available to deployers and developers who follow the statutory framework in good faith. That framing matters: the law is enforced by an exclusive regulator, but the cost of falling outside the statutory safe harbor is borne directly by the company.

What the Law Actually Asks You to Prove

Strip away the statutory architecture and the law’s real demand becomes clearer. SB 205 asks deployers to demonstrate, on demand, that any specific consequential decision was reached through a process that was documented in advance, monitored in operation, defensible after the fact, and corrigible when challenged.

That is a different burden than “the model is accurate.” A 99% accurate model that produces an unexplainable adverse decision against a Colorado consumer is not in compliance. A 92% accurate model whose every decision can be traced to a documented reasoning process, with the principal reasons surfaced and a path to human review preserved, is in compliance.

This is the architectural pivot the law forces. Compliance is not a property of the model. It is a property of the system around the model: the documented reasoning, the impact assessment, the monitoring, the consumer notice infrastructure, the appeal pathway. The model is one component. The decision process is the regulated artifact.

The Documentation Problem

The hardest of the deployer obligations to satisfy retroactively is the requirement to provide the principal reasons for an adverse decision. With a traditional rules engine or a linear model, this is straightforward: the decision can be explained by reference to the inputs and the rule set. With a contemporary LLM-based decision system, where the model produces a recommendation in a single forward pass with no externalized reasoning, there is often no faithful explanation available. Post-hoc rationalizations exist, but they are not the reasoning the system actually performed; they are a separate generation step that explains the output, not a record of how the output was reached.

This is where the architectural choice begins to bind regulatory choice. A system whose reasoning was performed in an externalized, structured form—captured as a graph of plan, retrieval, verification, critique, and synthesis steps with their inputs and outputs preserved—has a faithful record of how it reached the decision. The principal reasons are recoverable from the trace. The impact assessment can be grounded in observable system behavior rather than developer claims. The appeal pathway has something concrete to review.

A system whose reasoning evaporated at the moment of output generation has none of that. It has logs of inputs and outputs. It does not have a record of reasoning, because the reasoning was never made externally observable in the first place.

The Practical Position for Deployers

For a company that uses AI to make or substantially influence decisions in any of the seven covered domains, the practical position is this. SB 205 has been live since February. The reasonable diligence standard for the algorithmic discrimination reporting obligation is already running. The impact assessment requirement applies to systems already in production, not just to systems newly deployed. The consumer notice obligations attach to every adverse consequential decision made by an in-scope system today.

The work is not optional, and it is not tomorrow’s problem. The work is to inventory which deployed AI systems are in scope, complete impact assessments for each, stand up a risk management program that satisfies the statutory criteria, build the consumer notice and appeal infrastructure into the decision pathway, and—most importantly for any team whose systems were not built with externalized reasoning—decide what to do about the documentation gap that single-pass generation leaves behind.

The companies that will find this transition cheapest are the ones whose AI systems were already built to produce a structured, inspectable record of their reasoning. The companies that will find it most expensive are the ones who treated the model output as the artifact and the reasoning as ephemeral. The law has now made that architectural difference a regulatory difference.