The Colorado AI Act stopped being a future problem on June 30, 2026. As enacted, SB 24-205 wrote its operative duties to apply "on and after February 1, 2026." A 2025 amendment, SB 25-004, pushed the applicability date to June 30, 2026, which is the date to put on your compliance calendar. The statutory obligations did not soften in the delay. They are the same duties, now enforceable.
Most coverage of the Colorado AI Act has treated it as a lighter cousin of the EU AI Act. That framing is comfortable and slightly wrong. The Act imposes an affirmative, ongoing duty of reasonable care on both sides of the AI supply chain, requires documented impact assessments, and hands enforcement to a single actor with broad remedies. If your organization touches consequential decisions about Colorado residents, the question is not whether the Act reaches you. It is whether you can produce the paperwork that proves you met the duty.
What is the Colorado AI Act (SB 24-205), and why did it take effect on June 30, 2026?
SB 24-205 is the first comprehensive US state law aimed squarely at algorithmic discrimination in high-risk AI systems. As enacted, every core duty in the statute is framed "on and after February 1, 2026." The June 30, 2026 applicability date comes from the 2025 delay amendment, SB 25-004, not from the enacted text itself, so treat that date as legislative context rather than statutory language.
The distinction matters because auditors trace claims. When someone tells you the Act requires reasonable care "as of June 30," the statutory hook they are relying on is the "on and after February 1, 2026" clause in sections 6-1-1702 through 6-1-1704, moved by later amendment. The duty is real. The date it attaches was adjusted by a separate instrument.
This is exactly the kind of provenance problem that Aegis GRC is built around. Every obligation is traced to a verbatim quote from the legal text, so when your CCO asks where the "reasonable care" duty actually lives, the answer is a citation, not a memory. No AI hallucinations.
Who counts as a 'developer' versus a 'deployer' of a high-risk AI system?
The Act splits obligations across two roles, and most organizations are one, the other, or increasingly both.
A developer, under section 6-1-1701, is a person doing business in Colorado that develops or intentionally and substantially modifies an AI system. A deployer is a person doing business in the state that deploys a high-risk AI system, where "deploy" simply means to use one. The trigger for both is "doing business in this state," and the protected population is the "consumer," defined narrowly as an individual who is a Colorado resident.
The developer-deployer line is not academic. If you fine-tune or substantially modify a vendor model before putting it into a hiring or lending workflow, you have likely stepped into developer duties on top of your deployer duties. The Act treats intentional and substantial modification as a developer act, which pulls documentation and public-disclosure obligations onto organizations that think of themselves as pure buyers.
Mapping which of your systems and vendors fall on each side of that line is the first inventory exercise. Our regulatory intelligence tracking treats developer and deployer duties as distinct obligation sets so the same system can carry both without collapsing them into one checklist.
What triggers the classification of a high-risk AI system under the Act?
Everything in SB 24-205 hangs on one classification. A high-risk artificial intelligence system is any AI system that, when deployed, makes or is a substantial factor in making a consequential decision. Get this wrong in either direction and you either over-comply on tooling that does not matter or miss the systems that do.
A consequential decision is defined as a decision with a material legal or similarly significant effect on the provision, denial, cost, or terms of education, employment, a financial or lending service, an essential government service, health-care services, housing, insurance, or a legal service. That list is the perimeter. If your system does not touch one of those domains, it is not high-risk under this Act.
A substantial factor is a factor that assists in making, and is capable of altering the outcome of, a consequential decision, and is generated by an AI system. The "capable of altering the outcome" language is the operative test. An AI that produces a score a human rubber-stamps is still a substantial factor.
The Act also carves out exclusions. Systems that perform a narrow procedural task are not high-risk, and a long list of enumerated technologies is excluded, including anti-fraud tools without facial recognition, anti-malware, anti-virus, calculators, cybersecurity, databases, firewalls, networking, spam filtering, spell-checking, spreadsheets, and web hosting. The catch is the tail of that clause: those exclusions fall away the moment the technology itself makes a consequential decision. A spreadsheet is exempt until it becomes the loan-approval engine.
What does the duty of reasonable care to avoid algorithmic discrimination actually demand?
This is the spine of the statute. On and after the operative date, both developers (section 6-1-1702) and deployers (section 6-1-1703) shall use reasonable care to protect consumers from any known or reasonably foreseeable risks of algorithmic discrimination arising from the system.
Algorithmic discrimination is defined as any condition in which the use of an AI system results in unlawful differential treatment or impact that disfavors an individual or group on the basis of age, color, disability, ethnicity, genetic information, limited proficiency in English, national origin, race, religion, reproductive health, sex, veteran status, or other protected classification. The Act explicitly excludes two activities from that definition: self-testing to identify and mitigate discrimination, and expanding an applicant pool to increase diversity. In plain terms, testing your model for bias is not itself a violation, which removes a perverse incentive not to look.
The duty of reasonable care is backed by a rebuttable presumption. If a developer or deployer complied with the relevant section and any rules the Attorney General issues, the Act grants a rebuttable presumption that reasonable care was used. Compliance does not guarantee you win. It shifts the burden. That is a meaningful design choice: the statute rewards documented process, and the party that cannot show its work is the party defending without a presumption.
The developer side of the duty is concrete. A developer must make available to deployers a general statement of reasonably foreseeable uses and known harmful or inappropriate uses, documentation disclosing high-level summaries of training data, known limitations and risks of algorithmic discrimination, the system's purpose and intended benefits, and documentation on how the system was evaluated, its data governance measures, intended outputs, mitigation measures, and how it should be used and monitored. Developers must also publish a public statement summarizing the high-risk systems they have developed and how they manage discrimination risk, updated within 90 days of an intentional and substantial modification, and must disclose any known or reasonably foreseeable risk of algorithmic discrimination to the Attorney General and known deployers within 90 days of discovery or a credible report. Trade secrets are exempt from these disclosures.
Mapping these documentation duties to concrete controls is where a control mapping layer earns its keep, because each of those disclosure items becomes an artifact someone has to own and refresh.
What must an AI impact assessment contain, and how often must it be redone?
Deployers carry the heaviest operational load, and it has two parts.
First, a deployer shall implement a risk management policy and program that specifies the principles, processes, and personnel used to identify, document, and mitigate risks of algorithmic discrimination. The Act is explicit that this is an iterative process, regularly and systematically reviewed and updated over the system's life cycle. It also tells you how "reasonable" will be judged: against the NIST AI Risk Management Framework, ISO/IEC 42001, or another recognized framework, the size and complexity of the deployer, the nature and scope of the systems deployed, and the sensitivity and volume of the data processed. NIST and ISO/IEC 42001 are named in the statute, so they are not optional reference points. They are the yardstick.
Second, a deployer, or a third party contracted by it, that deploys a high-risk AI system shall complete an AI impact assessment. Under the Act's impact-assessment provisions this must be done on an ongoing basis, refreshed annually and within 90 days after any intentional and substantial modification. An impact assessment is not a one-time gate. It is a recurring obligation with a hard clock attached to every material change you make.
That recurrence is the trap. Organizations complete a first assessment, file it, and move on, then modify the model. The 90-day window on modification means your assessment cadence is driven by your release cadence, not the calendar. Treating impact assessments as a standing risk management workflow, rather than an annual project, is the difference between a defensible record and a stale PDF.
What consumer-notice and disclosure obligations now apply, and when does the AG enforce them?
Section 6-1-1704 adds a consumer notice requirement that reaches further than the high-risk duties. A deployer or developer that deploys an AI system intended to interact with consumers shall ensure disclosure to each consumer that they are interacting with an AI system, except where that would be obvious to a reasonable person. Note the scope: this disclosure duty attaches to consumer-facing AI generally, not only high-risk systems.
Enforcement is centralized and pointed. Section 6-1-1706 gives the Attorney General exclusive authority to enforce this part, and a violation constitutes an unfair trade practice under the Colorado Consumer Protection Act. There is no private right of action, so the risk vector is the AG, not the plaintiffs' bar, at least under this statute.
The Act does provide an affirmative defense. A developer or deployer that discovers and cures a violation through feedback, adversarial testing or red teaming consistent with NIST guidance, or internal review, and is otherwise in compliance with the NIST AI Risk Management Framework and ISO/IEC 42001 or a substantially equivalent or AG-designated framework, may raise that as a defense. The person bears the burden of demonstrating it. Between the rebuttable presumption and this affirmative defense, the statute repeatedly rewards one thing: a documented, framework-aligned program you can produce on demand. The audit pack is a query, not a project.
Finally, section 6-1-1707 authorizes the Attorney General to promulgate rules covering documentation, impact assessments, the risk management program, notice, and disclosures. Expect the operational detail to arrive through rulemaking, which means your program has to be built to absorb new specifics without a rebuild.
How does the Colorado AI Act line up against the EU AI Act's high-risk regime?
Framed as comparison rather than cross-citation, the two regimes share a skeleton and differ in muscle. Both organize obligations around a "high-risk" tier and both split duties between those who build systems and those who deploy them, with the heavier documentation load on the developer or provider and the operational duties on the deployer.
The differences are where planning happens. Colorado's Act is anchored specifically on algorithmic discrimination in consequential decisions and enforced solely through a state Attorney General as an unfair trade practice, with no private right of action and an explicit affirmative defense for framework-aligned cure. The EU regime is broader in the harms it addresses and carries its own conformity and market-surveillance machinery. For a multinational, the practical takeaway is that a NIST- and ISO/IEC 42001-aligned program built for Colorado is a strong foundation for EU obligations, but the two are not interchangeable. Treat Colorado as a subset of controls you can extend, not a substitute.
This is why we track regulatory intelligence across 245+ regulations and 28 jurisdictions with every obligation traced to a verbatim quote from the legal text. The overlap between Colorado and the EU is real, but only visible when both are mapped to the same control catalog rather than read as separate PDFs.
FAQ: enforcement, safe harbors, exemptions, and what to operationalize first
Who enforces the Colorado AI Act, and can consumers sue? The Attorney General has exclusive authority to enforce the Act, and a violation is an unfair trade practice under the Colorado Consumer Protection Act. The statute expressly states it does not provide a private right of action, so individual consumers cannot bring their own claims under it.
Is there a safe harbor? There are two protections. Compliance with the relevant section plus AG rules creates a rebuttable presumption of reasonable care. Separately, an affirmative defense exists where you discover and cure a violation via feedback, adversarial testing consistent with NIST, or internal review, and are otherwise in compliance with the NIST AI Risk Management Framework and ISO/IEC 42001 or an equivalent framework. You carry the burden of proving the defense.
What is exempt from the high-risk definition? Systems performing a narrow procedural task, and a list of enumerated technologies including anti-fraud without facial recognition, anti-malware, anti-virus, calculators, cybersecurity, databases, firewalls, networking, spam filtering, spell-checking, spreadsheets, and web hosting. Each exclusion evaporates the moment that technology makes a consequential decision.
What should we operationalize first? Inventory. Identify which systems make or are a substantial factor in consequential decisions about Colorado residents, then split them into developer and deployer duties. From there, stand up the risk management program against NIST and ISO/IEC 42001, schedule impact assessments annually and on every substantial modification, and wire the consumer-interaction disclosure into affected products.
If you want the Colorado AI Act mapped to concrete controls with every obligation source-grounded to the statute, agrc.ai turns SB 24-205 into a live obligation set rather than a reading assignment.
