Colorado Is Writing the Rules Right Now, and the Comment Window Is Closing

Most of the AI compliance attention of the last six months has pointed at Brussels, which is understandable given the size of the fines and the density of the deadlines. It has also meant that a genuinely consequential piece of American rulemaking has been running almost unwatched. On 11 August 2026 the Colorado Attorney General filed proposed rules implementing two laws, Senate Bill 26-189, the Automated Decision-Making Technology Act, and House Bill 26-1263, the Chatbot Safety Act. Both take effect on 1 January 2027. The early comment deadline was 4 September, which has now passed. A revised draft is due to circulate by 23 September, and the final comment deadline is 26 October 2026. If you sell software into the United States, you have somewhere between six and sixteen weeks to influence the text and roughly sixteen weeks to comply with it.

The history matters because it explains the shape of the rules. The original Colorado AI Act, Senate Bill 24-205, was the first comprehensive state AI law in the country and it was built on a European chassis: a duty of care, algorithmic impact assessments, a rebuttable presumption of compliance. It never took effect in that form. Enforcement was stayed in April 2026 while litigation ran, the General Assembly rewrote it, and the replacement was signed in May. SB 26-189 keeps the target and discards most of the machinery. Out went the duty of care, the impact assessments and the presumption. In came specific disclosure obligations, three year record keeping, and a sixty day cure period administered by the Attorney General that itself sunsets on 1 January 2030. That is a deliberate pivot from a risk management statute to a consumer notice statute, and it changes who does the work. Under the old model the burden fell on your governance function. Under the new one it falls on your product and support teams.

The split between developer and deployer is where most teams will find themselves misclassified. If you build automated decision-making technology and hand it to someone else, you owe them meaningful and accurate information about intended uses, documented known limitations and risks, monitoring instructions, and the categories of training data, and you can only withhold that on trade secret grounds with a legal justification and an adequate alternative. If you deploy it in a consequential decision, meaning employment, financial services, housing, insurance or education, you owe the consumer a disclosure that it was used. The proposed rules also address the case almost every real product actually is, which is neither one nor the other: a midstream developer who takes an upstream model, wraps it, and ships it onward has to pass the full upstream documentation downstream. If you are building on a foundation model and reselling the result, that clause is about you, and it is the clause most likely to send you back to your provider asking for paperwork you have never requested before.

For deployers the proposed rules attach a clock to everything, and the clocks are the part that will actually break. An adverse outcome notice goes out within thirty days through two separate communication methods, and it has to explain the decision, the role the technology played, the principal reasons, any factor that produced an automatic denial, and any risk score used. A consumer request to correct personal data or to obtain human review has to be acknowledged within ten days and completed within forty five. The human review has to be independent and carry genuine authority to override, which rules out the common pattern where a person rubber stamps the model output because the workflow gives them nothing else to do. None of that is a policy problem. It is a ticketing, routing and service level problem, and the teams that treat it as something for the legal function to draft will discover in January that the obligation lives in a queue nobody owns. There is one piece of good news buried in the drafting: existing notices under the Equal Credit Opportunity Act and the Fair Credit Reporting Act can satisfy the requirement if you add the technology specific content, so lenders already running adverse action notices are extending a pipeline rather than building one.

The Chatbot Safety Act is the half that will surprise more people, because its scope is not limited to companion apps despite how it has been reported. An operator has to disclose that the user is talking to software rather than a person, with a persistent visible disclaimer where the user is a minor, and has to use commercially reasonable methods to estimate age in the first place. Beyond that sit suicide and self harm response protocols, a prohibition on presenting outputs as equivalent to licensed professional services, restrictions on training with data from minors, protection of minors from sexually explicit content, and a ban on engagement maximising mechanics such as streaks, badges and leaderboards for minor users. Narrow topic menu driven or rule based bots are exempt, and so are deployments available only to your own workforce. Violations are enforced as Colorado Consumer Protection Act violations with civil penalties up to twenty thousand dollars per violation, and the first annual operator reports fall due on 1 July 2027. The line worth sitting with is the professional services one. A support bot that answers a question about medication, benefits eligibility or a legal deadline is closer to that line than its owners think.

This is the point where the audience for these rules stops being large regulated enterprises and starts being everyone who shipped something quickly. A support widget assembled in Lovable, a triage assistant prototyped in Bolt, an onboarding flow generated in v0 and wired to ChatGPT or Claude, an ElevenLabs voice front end on a booking system: each of those is a chatbot operator under this statute if it talks to consumers in Colorado, and age estimation, self harm protocols and a persistent disclaimer for minors were almost certainly not in the prompt that produced it. We have made the argument before that platform compliance is not your compliance, and this is the sharpest version of it. The builder gave you a product. It did not give you an operator obligation, an annual report, or a defensible answer to a state attorney general about how you estimate the age of your users. The exemption for internal workforce deployments is genuinely useful here, and the fastest risk reduction available to a lot of teams is simply confirming that the assistant they built is in fact internal only, and that nothing has quietly exposed it to customers.

Mapping this into the compliance programme you already run is easier than it looks, because the artefacts overlap almost completely with ones you should already hold. Under ISO 42001, every automated decision-making system and every consumer facing chatbot earns an inventory entry with a named owner, its role in the decision, whether you are developer, midstream developer, deployer or operator for that system, and the date the disclosure text was last verified. The developer documentation obligation is an ISO 42001 supplier and customer information control by another name, and the three year record keeping requirement is a retention schedule, not a new system. Under SOC 2 and ISO 27001, the notice pipeline and the human review queue are change managed components with availability and processing integrity implications, because a release that breaks the disclosure banner is now a regulatory event rather than a cosmetic bug. Vanta, Drata, Secureframe, Sprinto, Thoropass and Hyperproof will each carry this as a monitored control with a review cadence, which converts a January scramble into a tracked obligation. What none of them will do is tell you which of your products talks to consumers in Colorado. That remains a person with a product inventory and an afternoon.

The unusual thing about this particular deadline is that it is still partly writable, and very few teams treat rulemaking comment windows as a lever available to them. The proposed rules define terms that will determine how expensive compliance actually is: what counts as meaningful human review, what commercially reasonable age estimation looks like in practice, how much of a model card a midstream developer must pass downstream, and how the two required communication methods for an adverse outcome notice are satisfied. A revised draft is expected by 23 September and comments close on 26 October. A short, specific, operationally grounded submission from a company that actually ships this software is worth considerably more to a regulator than another association letter, and the cost of writing one is an afternoon. If your product falls inside either statute, reading the revised draft when it lands in late September is the highest leverage compliance hour available to you this quarter.

It is fair to be tired of this. A national market now has a European regime with staggered deadlines, a growing set of divergent state statutes, and a Colorado law that was written, stayed, litigated, repealed and rewritten inside eighteen months, which is not a stable basis for building a product. The fragmentation is a real cost and the criticism is legitimate. It also changes nothing about the position a team is in on 5 September 2026. The rules are drafted, the comment window is open for another seven weeks, and both laws take effect on 1 January 2027 whether or not anyone in your company has read them. The teams that come out of January cleanly will not be the ones with the longest policy document. They will be the ones who can list every system that makes a consequential decision or talks to a consumer, name the role they play in each, show the disclosure text and when it was last checked, and point at the queue where a human review request lands and the person whose name is on it.