Colorado's AI Act: the Rebuttable Presumption and the NIST Defence Are Not the Same Thing

A great many summaries of Colorado’s AI Act say that a developer who follows the NIST AI Risk Management Framework or ISO/IEC 42001 gets a rebuttable presumption of reasonable care. That sentence merges two separate provisions of the statute that have different triggers, different elements and different effects. Getting them apart changes what a compliance programme should actually be aimed at.

Two shields, routinely merged into one

SB 24-205, codified at C.R.S. §§ 6-1-1701 to 6-1-1707, contains both:

• A rebuttable presumption of reasonable care, which appears inside each of the two duty sections — § 6-1-1702 for developers and § 6-1-1703 for deployers — and attaches to compliance with that section and any rules the Attorney General promulgates under it.
• An affirmative defence, which appears in the enforcement section, § 6-1-1706, and is the provision that names the NIST AI Risk Management Framework and ISO/IEC 42001 by name.

They are not alternatives to each other and they do not do the same job. The presumption bears on whether you breached the duty of care. The affirmative defence assumes a violation and gives you a complete answer to it, on conditions. Neither one is available by publishing a policy that mentions a framework.

The rebuttable presumption of reasonable care

The statute imposes on a developer, and separately on a deployer, a duty to use reasonable care to protect consumers from any known or reasonably foreseeable risk of algorithmic discrimination arising from the intended and contracted uses of a high-risk AI system. Reasonable care is a negligence-shaped standard, and negligence standards are decided after the fact by somebody who knows how it turned out. The presumption is the statute’s answer to that: if you did the enumerated things in the section, you are presumed to have used reasonable care, and the burden moves to whoever says otherwise.

The enumerated things are the section’s own obligations. For a deployer that means, in outline, implementing a risk management policy and programme governing the deployment, completing an impact assessment for the system and repeating it annually and within ninety days of an intentional and substantial modification, reviewing the deployment annually to check it is not causing algorithmic discrimination, providing the consumer notices, publishing the public statement, and notifying the Attorney General within ninety days of discovering that the system has caused algorithmic discrimination. For a developer it means the documentation and disclosure package owed to deployers, the public statement about the types of high-risk systems developed, and the same ninety-day notification duty. Those are set out in the developer and deployer duties page and the assessment itself in the impact assessment page.

The presumption is rebuttable, which is the word doing the most work and the one most often skipped. It shifts a burden; it does not decide the case. Evidence that the system in fact produced a discriminatory outcome, that the risk was known and not addressed, or that the impact assessment was a template with the system’s name typed into it, is exactly the evidence that rebuts it. A presumption built on documents you did not really do is worse than no presumption, because the documents become the exhibit.

The affirmative defence, and its second element

The affirmative defence in § 6-1-1706 is the framework provision, and it has two elements that must both be satisfied. The defendant must have discovered and cured the violation as a result of feedback the developer or deployer encourages from users, or as a result of adversarial testing or red-teaming, or as a result of an internal review process. And the defendant must otherwise be in compliance with the latest version of the NIST Artificial Intelligence Risk Management Framework and its generative AI profile, or ISO/IEC 42001, or another nationally or internationally recognised risk management framework for AI systems, or a risk management framework designated by the Attorney General.

The first element is the one that gets lost. The defence is not available to an organisation that has adopted a framework and had no problems; it is available to one that found its own violation through a named discovery mechanism and fixed it. Structurally, the statute is paying for self-detection. A red-team programme that never reports anything, or a feedback channel nobody reads, produces no discovery and therefore no defence, however thorough the framework alignment is.

The second element also carries a trap. “The latest version” of a framework is not a fixed target: NIST can publish a revision or a new profile, and an organisation that aligned once and stopped is no longer aligned to the latest version. Framework alignment under this provision is a maintained state, not a project with an end date.

What adopting a framework actually involves

The two named frameworks are different kinds of object and confusing them leads to the wrong programme.

• The NIST AI RMF is voluntary guidance published by the US National Institute of Standards and Technology, organised around four functions — govern, map, measure and manage — with a companion generative AI profile. There is no certification, no accredited auditor and no certificate to produce, which means “in compliance with” it is a claim you have to be able to evidence yourself. See the four functions page.
• ISO/IEC 42001 is a certifiable management system standard, so there is an accredited certificate available — but certification is against a scope you define, and a certificate whose scope excludes the system in question proves nothing about that system. The scope statement is the part to read, not the logo. See the certification scope page.

Neither framework, on its own, produces the Act’s specific artefacts. The impact assessment content that § 6-1-1703 requires — purpose, intended use, deployment context, benefits, known or reasonably foreseeable risks of algorithmic discrimination and steps taken to mitigate them, categories of data processed as inputs and outputs, metrics used to evaluate performance and limitations, transparency measures and post-deployment monitoring — is a Colorado list. An ISO 42001 management system will tell you to do assessments; it will not tell you to put those fields in them.

What either shield is worth

Both shields sit inside an enforcement structure that is narrower than many people assume, and that changes how much effort either deserves. Enforcement is exclusively by the Attorney General; a violation is a deceptive trade practice under the Colorado Consumer Protection Act; and the Act expressly creates no private right of action. So the presumption and the defence are shields against a state enforcement action, not against a class action.

They are also not shields against everything else that applies to the same system. A hiring model that discriminates still breaches Title VII and the Colorado Anti-Discrimination Act regardless of your NIST alignment, and none of the Act’s provisions touch those claims. If your programme is aimed only at Colorado, it is aimed at the smaller risk.

One last caution about dates. The Act’s application date was delayed from 1 February 2026 to 30 June 2026 by legislation passed in a special session in August 2025, and the statute has been the subject of repeated amendment proposals since enactment. It is entirely possible for the shape of both shields to change before the Act is enforced against anyone. Check the current text of §§ 6-1-1702, 6-1-1703 and 6-1-1706 rather than any description of them, including this one.