Colorado's Proposed AI Rules Are About Instrumentation

Disclosure Is the Easy Part of Colorado's ADMT Rules

Most compliance conversations about Colorado's Automated Decision-Making Technology Act start and end with disclosure: tell consumers AI is involved, tell them why they got the outcome they got. That is necessary but it is the easy part.

The Colorado Attorney General's proposed implementing rules, 4 CCR 904-6, spend far more of their text on something harder to budget for — the operational systems a covered business has to build and keep running. If your team is treating this as a copywriting exercise for a new disclosure banner, the rules as proposed will catch you short.

What follows is a walkthrough of what the rule actually asks for, section by section, for any business whose AI touches a "consequential decision" as the Act defines it.

Notices Must Be Accessible, and Disclosure Must Explain

Rule 3.2 requires accessible notices, not merely present ones. The rule requires that required notices be provided in a manner that is readily accessible and understandable — plain language, not buried in a terms-of-service document, not written at a reading level that defeats the purpose of disclosure. This sounds obvious until you try to satisfy it inside an existing app's information architecture. A notice that technically exists three taps deep in a settings menu is not what Rule 3.2 has in mind.

Rules 6.2 and 6.4 push disclosure past notification into explanation. A covered business has to be able to tell an affected consumer, in specific terms, what factors the automated system considered and how those factors related to the outcome — not a generic statement that "many factors" went into the result. That requires the underlying system to be able to produce that explanation in the first place, which is a model-design and logging requirement wearing a disclosure rule's clothing. If your system cannot trace which inputs drove a given output, Rule 6.4 is not a document you write after the fact — it is an architecture decision you needed to make earlier.

Rule 6.6 adds a further specific: named data sources. Generic disclosure that a system used "consumer data" does not satisfy the rule; the business has to be able to identify, by name or category with real specificity, where the data came from.

Consumer Rights and Human Review Carry Hard Clocks

Rules 7.2 and 7.6 attach deadlines to consumer requests. A business must offer at least two methods for a consumer to submit a request — to opt out of the automated processing, to appeal a decision, to request the information above — and must substantively respond within 45 days. Two intake channels sounds minor operationally, but it means the request cannot route to a single overloaded inbox with no SLA; it has to hit a workflow with a tracked deadline and an owner.

Rule 7.7 is where a lot of the real engineering cost lives. A consumer who appeals an adverse automated decision is entitled to meaningful human review — and the rule is specific that this has to be a genuine human determination, not a rubber stamp. The reviewer has to have the authority to overturn the automated outcome, has to be someone other than the person or system that made the original decision, and — critically — "the ADMT may not assist" in that specific review. You cannot satisfy Rule 7.7 by having a human click "approve" on the AI's own recommended resolution.

The rule also puts the outcome on hold: the adverse decision has to be stayed pending the review where the rule requires it, the business has to acknowledge the request within 10 days, and complete the review within 45. All of that has to be documented — who reviewed it, what they considered, what they decided, and why — in a form that survives an examination or an enforcement inquiry months later. If your current "human in the loop" is a support agent glancing at a dashboard before confirming the system's own suggestion, that process does not clear Rule 7.7 as proposed.

Chatbot Disclaimers and Annual Reporting Are Data Problems

The chatbot-disclosure mechanics get specific too. For any covered business layered on top of a consumer-facing conversational AI, Rule 10.2 sets out the mechanics of the persistent AI-use disclaimer required under the companion Chatbot Safety Act (C.R.S. § 6-1-1708) — minimum font-size and placement requirements for text interfaces, and comparable audible-disclosure requirements where the interaction is voice-based. This is a rule about pixels and decibels, not concepts, and it is easy to satisfy accidentally-wrong: a disclosure that is technically present but rendered below the specified size, or spoken too quietly or too briefly to register, will not hold up as compliant even though "AI disclosure" appears somewhere in the product.

Annual reporting needs a data pipeline before it needs a template. Rules 13.3 and 13.4 require covered businesses to produce an annual report with specific quantitative content:

• The volume of consequential decisions the ADMT was involved in
• Accuracy or referral-rate metrics
• The age distribution of affected users where the system interacts with minors
• The time it took to resolve reports involving a suspected minor user

None of that is a figure most teams currently have sitting in a dashboard. It requires the underlying system to log, from day one of operation, the denominators these metrics are calculated against — total conversations, total decisions, total referrals — not just the numerator events someone happens to have flagged.

One more thing worth flagging for anyone working from the current proposed text closely: Rule 13.5(A) appears to contain a date that does not line up with the rest of the rule's effective-date structure. Whether that gets corrected in the September 23 revised draft is worth checking rather than assuming.