From Statute to Practice: Colorado's AI Accountability Regime
Colorado's central AI-governance question is no longer simply whether a system is called artificial intelligence. It is how a legal duty becomes an operating practice when software helps decide who receives housing, credit, education, employment, insurance, health care, or public benefits—or when a conversational service shapes a user's behavior and safety. This series examines Colorado's enacted automated-decision and chatbot statutes alongside the Department of Law's operational rulemaking. The practical judgment it supports is straightforward: can an organization show what its system did, why it mattered, who was responsible, and what happens when the system or its result causes harm?
The subject is a pair of laws becoming an operational field
The first part of this subject is Colorado Senate Bill 26-189, the Automated Decision-Making Technology in Consequential Decisions Act. The signed act regulates a chain: technology processes personal data, computation produces an output, and that output materially influences a consequential decision about an individual. Its duties reach beyond the model itself. Developers must give deployers information about intended uses, known harmful or inappropriate uses, training-data categories, limitations, risks, and appropriate monitoring. Deployers must give consumers notice and, after an adverse outcome, a path to additional information and review.
The second part is the Chatbot Safety Act, addressed in the supplied rulemaking material together with the ADMT Act. Its object is different. A conversational service may never make a housing or lending decision, yet its design can still matter if it presents itself as human, encourages a minor to stay engaged, simulates an exclusive relationship, produces sexual content, or mishandles indications of self-harm. The relevant controls therefore include age assurance, disclosure, safeguards, crisis protocols, testing, and reporting.
The connection between the two laws is not that all AI risks are the same. It is that both require institutions to make behavior inspectable. For an ADMT, inspectability means being able to connect an output to a decision, its inputs, the responsible organizations, and a consumer's remedy. For a chatbot, it means being able to explain the service's boundaries, the signals used to protect minors, the safeguards tested, and the response when those safeguards fail.
Colorado's Department of Law is the institutional bridge between broad statutory language and those operating details. The August 2026 rules document identifies 4 CCR 904-6 as covering both automated decision-making technology and conversational artificial intelligence services. It states that the rules would become effective January 1, 2027, while the signed SB26-189 generally takes effect on that date and applies to consequential decisions made on or after it. The statutory provisions directing or authorizing rulemaking also show why the rules matter: the legislature expected the Attorney General to clarify post-adverse-outcome disclosures, consumer rights, and the meaning of material influence.
That timing needs careful interpretation. The Future of Privacy Forum's July 2026 letter describes its submission as part of pre-rulemaking, and the supplied rules document is a rulemaking artifact rather than proof that every operational detail has become an immutable final rule. The enacted statute is therefore the strongest authority for what Colorado has legislated. The rulemaking document shows how the Department proposes to make those duties concrete. Keeping those levels separate is not a technicality; it is part of reading the regime accurately.
Two kinds of AI risk, one question about observability
Consider a housing provider that uses a score to set a security deposit or decide whether to renew a lease. The important legal question is not whether the provider purchased a machine-learning product. It is whether the system's output is a non-trivial factor that affects the result of a consequential decision. If it is, the provider needs a record of the relevant system and version, information about the data and factors used, a notice that makes the role of the system understandable, and a process through which the consumer can seek information, correct inaccurate facts, or request meaningful human review.
Now compare a billing chatbot that only reports an order status with a service that remembers a user's personal history, gives itself a name and backstory, and encourages the user to return for emotional reassurance. Both are conversational. Their regulatory questions are not identical. The first may fit a narrow, bounded task. The second raises questions about whether a narrow-topic exemption is credible, whether design features encourage emotionally dependent interaction, whether the service recognizes minors, and whether its safeguards remain effective after a model or product update.
The contrast reveals the regime's core theme. Colorado is moving from category words to observable relationships. “ADMT” is not the conclusion; it is the beginning of a chain that asks what data was processed, what output was generated, what decision it influenced, and what happened to the person. “Chatbot” is not the conclusion either; the relevant chain asks what the service was designed and marketed to do, how it interacts, what signals it receives, and how it responds to risk.
The diagram's feedback loop is important. A system is not made accountable once an organization writes a policy. The organization must preserve evidence, respond to a person or user, test whether controls work, and revise operations when updates or incidents expose a weakness. That is why the rules speak about version identifiers, changelogs, monitoring instructions, repeated age signals, real-world safety incidents, and annual reports. They treat governance as something that must continue after deployment.
Why broad statutes need operational rules
Statutes can define a consequential decision and require a meaningful explanation without specifying what a consumer should actually receive. The rulemaking document fills that gap for ADMT disclosures by moving from a general promise of transparency to details that affect usability. A post-adverse-outcome disclosure should identify the decision, describe the system's role and any human role, state specific principal reasons, and identify relevant scores, inferences, automatic-denial factors, or missing information. A request route should make it possible to obtain the system's name, version when applicable, developer, data categories, and named data sources.
Those details answer a practical failure mode: an organization can truthfully say that “an automated system was used” while telling the affected person almost nothing. A reason such as “our internal standards” does not show what mattered. A statement about a credit score, employment history, or incomplete rental history gives the person a starting point for deciding whether the underlying information is wrong. The rules also connect the explanation to channels, languages, disability access, and a simple process rather than treating a disclosure as a document that exists only for a file.
The chatbot rules perform a similar translation, but at the interaction level. A disclosure for a minor using a screen-based service must remain visible throughout the conversation and be distinct from the conversation itself. For other users, the document describes disclosure at the beginning of the first interaction each day, at intervals during a continuous interaction, or persistently. Age assurance must protect privacy, provide choices, use measurable methods, respond to contradictory signals, and avoid treating an inconclusive result as proof that a user is an adult. Safety controls must be tested under realistic scenarios and revisited after model updates or new features.
The point is not that every listed detail is a universal technical solution. The point is that legal accountability becomes meaningful only when it can be observed at the interface where a decision or interaction occurs. A consumer needs a route to information. A reviewer needs evidence and authority. An operator needs a way to know whether a safeguard works. Rules make those dependencies visible.
Accountability has more than one owner
The system's provider and the organization using it do not occupy the same position. Under SB26-189, a developer supplies information that a deployer needs to use a Covered ADMT appropriately and explain its role. A deployer decides how the system is configured and used in a consequential decision, keeps records, communicates with the consumer, and handles correction or review. If a company integrates a third-party system into its own product, the rulemaking document treats that middle layer as important: the integrator should obtain upstream documentation and make it available downstream.
The consumer or user is the reason these handoffs matter. A model card that never reaches the deployer cannot support a decision-specific explanation. A deployer's record that omits the system version cannot show which behavior produced the output. A chatbot's safety policy that is not tested after a product change cannot show that it still works. In each case, accountability fails at the connection between an actor's responsibility and the evidence needed to exercise it.
This is also why Colorado's framework does not make compliance a substitute for every other legal duty. The signed act preserves discrimination-related responsibility and states that compliance with Part 17 does not excuse violations of other state or federal law. The rules coordinate with regimes such as ECOA, FCRA, FERPA, and health-privacy requirements where possible, but coordination is not erasure. A notice can satisfy more than one requirement only if it contains what each applicable law requires and does not disclose information that federal law protects.
The Future of Privacy Forum's comment letter identifies the same problem from a stakeholder perspective. It argues that the ADMT Act and Colorado Privacy Act may use different definitions, triggers, timing, and approaches to opt-out or appeal, even when they govern the same processing. Its recommendations—to align terminology, streamline rights, keep age-assurance methods flexible, and define crisis-protocol elements without freezing one method—are persuasive proposals, not binding law. They nevertheless identify where operational design will determine whether people experience one coherent process or several disconnected ones.
The boundary question ahead
Colorado's AI regime should therefore be read neither as a simple ban nor as a complete technical specification. It is an attempt to build a chain of accountability around two different kinds of exposure: an automated output that changes a consequential decision, and a conversational service whose ongoing interaction can create safety risks. The chain is strong only when its links line up: coverage is correctly identified, responsibility is assigned, evidence survives updates, explanations are specific, remedies are usable, reviewers can act independently, and safety controls are measured rather than assumed.
The materials also leave important questions open. The rulemaking text does not supply a performance record for every age-assurance method or crisis detector. The comment letter warns that indirect expressions of suicidal ideation may be difficult to identify and that safety monitoring can require processing highly sensitive information. Overlap with privacy, federal, and sector-specific law still requires factual and legal judgment. None of those limits makes the framework irrelevant. They show why operational rules must preserve uncertainty instead of hiding it behind a confident label.
The next issue is the first gate in the chain: when does a system's output cross the line from ordinary software assistance into a Covered ADMT that materially influences a consequential decision? That question determines whether the rest of Colorado's accountability machinery attaches at all.