NetChoice recently submitted comments on the rulemaking for the Automated Decision-Making Technology Act (Senate Bill 26-189) and the Chatbot Safety Act (House Bill 26-1263). We strongly urge the Colorado Attorney General to scale back proposed rules that overstep the office’s statutory authority. The current drafts threaten free enterprise and AI innovation by inventing new regulated entities like “Midstream Developers,” imposing impossible disclosure mandates on technology creators, and unlawfully forcing businesses to freeze their decision-making operations over unverified data disputes.
NetChoice Comments for the Record on Rulemaking Considerations for the Automated Decision-Making Technology Act (SB 26-189) and the Chatbot Safety Act (HB 26-1263)
September 4, 2026
The Honorable Phil Weiser
Attorney General of Colorado
Colorado Department of Law
Ralph L. Carr Colorado Judicial Center
1300 Broadway
Denver, CO 80203
Dear Attorney General Weiser,
NetChoice is a national trade association of technology and internet businesses that promotes free expression and free enterprise online. We appreciate the opportunity to comment on the proposed rules implementing the Automated Decision-Making Technology Act (SB 26-189) and the Chatbot Safety Act (HB 26-1263), and we submit these comments to the Office of the Attorney General for the September 4 deadline so that they may be considered in any revisions presented at the October 26 hearing. These comments build on NetChoice’s July pre-rulemaking submission and focus on the provisions of the draft rules that most urgently require revision. Our overarching concern is a consistent one: several draft provisions extend beyond the Attorney General’s authority to implement and clarify the statutes, creating new roles, rights, and design mandates the General Assembly not only did not enact, but sought to rectify by repealing and replacing SB 24-205.
I. The “Materially Influence” Threshold: The Presumption-and-Rebuttal Framework Is Preferable, Though Both Options Remain Excessively Broad
The Notice outlines two candidate frameworks for defining “Materially Influence.” Between these options, Standard 2 is the sounder regulatory choice. It rightfully contemplates that a Deployer can establish that a human being made the decision on the basis of independent judgment, with the automated output contributing only marginally. Standard 1’s formulation risks capturing everyday informational tools whose outputs simply sit alongside the myriad other factors a decision-maker considers.
However, the Office must recognize that neither formulation is sufficiently narrow. Under the presumption framework, any output that pertains to the individual, reaches the decision-maker before or during the process, and aligns with the ultimate outcome is presumed to have materially influenced it. This trigger encompasses virtually every analytical tool in commercial use. Because the trigger is so expansive, the rebuttal mechanism carries the entire weight of keeping the rules within the statute’s intended scope. Two revisions to the Notice’s proposed rebuttal framework are essential:
- Disjunctive Rebuttal Criteria: The rebuttal criteria should operate disjunctively, substituting “or” for “and,” so that a Deployer need not run the table on every element to demonstrate that an output played a trivial role.
- Open Evidentiary Categories: The list of qualifying evidence should be instructive, not exhaustive.
Without these modifications, the presumption operates as functionally irrebuttable in ordinary business settings.
Further, the Office should supplement the final rules with concrete illustrations of how the “Materially Influence” standard operates in practice. The competing definitional frameworks, standing alone, leave regulated parties guessing at the line between covered and excluded uses.
That uncertainty is sharpest at the seam between the presumption trigger and the subpart D exclusion for tools used to summarize, organize, translate, draft, route, or present information. The two categories are not cleanly separable: a hiring manager who directs a tool to arrange applications by years of relevant experience is, on any ordinary reading, organizing information for human review — yet the resulting ordered list is also a “rank” that pertains to individuals, reaches the decision-maker, and will frequently align with the eventual outcome. Under the draft text, the same routine act plausibly sits inside the exclusion and inside the presumption at once.
The cleanest way to close this gap is to make the source of the decision criteria the operative distinction. Where a human specifies the sorting logic and the tool merely executes it — ordering candidates by a stated experience threshold, for instance — the analytical judgment remains human, and the tool is doing precisely what subpart D excludes. Where instead the tool selects or weights the criteria itself — asked simply to surface the “strongest” applicants by whatever measures it deems relevant — the tool is supplying the inference, and the presumption is properly available. Subpart B(1) may already intend this distinction, but intent buried in structure is no substitute for text. The Office should state expressly that the presumption attaches only where the ADMT determines the criteria of evaluation, and should pair that clarification with worked examples on both sides of the line.
II. “Midstream Developers” Exceed Statutory Authority and Should Be Struck (Rules 2.2, 4.2)
The statute identifies two regulated actors: Developers and Deployers. The draft rules impermissibly manufacture a third category—the “Midstream Developer”—defined as a party that integrates Covered ADMT into its own product and provides it to another Developer or Deployer. Rule 4.2 then assigns this new entity affirmative duties to reasonably obtain upstream Developer documentation and transmit it downstream.
Manufacturing a new regulated entity and attaching novel obligations goes well beyond clarification and implementation. Contract terms negotiated between sophisticated entities will move necessary information to the appropriate parties far more effectively than a one-size-fits-all pass-through mandate. The definition of “Midstream Developer” in Rule 2.2 and the obligations in Rule 4.2 should be deleted in their entirety.
III. Rule 5.2(B)(1) Imposes an Impossible Knowledge Standard on Developers
Rule 5.2(B)(1) directs Developers to describe the types of Consequential Decisions for which the ADMT is intended, and Rule 5.2(B)(2) requires describing the types of Consequential Decisions for which it is not intended. This goes beyond the statute. 6-1-1702(a) only requires a “general statement” of the “intended uses” and “known harmful or inappropriate uses” [emphases added].
The proposed rule misapprehends the commercial separation between Developers and Deployers. Model development builds capabilities; Deployers select the context, configure the system, and determine whether outputs bear on consequential individual decisions. Knowledge about an ADMT’s real-world applications is divided by role: the Developer understands what its system can do; the Deployer understands the problems it needs to solve.
Neither party alone possesses the full picture, and much of it does not exist at all at the moment of release — the fit between a general-purpose capability and a consequential-decision context is discovered in deployment, as customers adapt the tool to needs its creator never contemplated. A rule demanding that Developers enumerate intended and unintended decision types therefore compels them to certify knowledge that resides with someone else, or with no one yet. The statute’s own text respects this division of labor: by requiring only a general statement of intended uses, the General Assembly placed each disclosure obligation on the party with actual access to the underlying facts. The rules should preserve that allocation rather than invert it.
A Developer cannot enumerate the universe of consequential-decision applications downstream customers may eventually pursue. Furthermore, requiring a Developer to catalog decision types for which the system is not intended demands the description of a boundless negative space. This provision creates an enforcement trap rather than a clear compliance standard. It is also a strong disincentive to innovate, as developers will be incentivized to list limited uses and discourage any use case around consequential decisions other than those listed in the intended uses. The rule must be revised to require only a good-faith, general description of intended uses at the level of generality that the Developer’s actual design choices support.
The Office should clarify disclosure obligations by providing illustrative examples of sufficient disclosures, including sector-specific examples. The Act requires Developers to disclose a covered ADMT’s “harmful or inappropriate uses” and the “known risks and circumstances in which the covered ADMT should not be used,” but as written those terms give a good-faith Developer no way to know when its disclosures are complete. Illustrative examples would meaningfully reduce uncertainty.
IV. The Notice’s Developer-Disclosure Mandates Should Be Rejected
The Notice invites comment on whether the rules should compel Developers to disclose detailed testing performed—including methods, results, and affirmative statements when no testing occurred—as well as specify training-data categories at prescribed granularity. NetChoice strongly urges the Office to reject this expansion.
The enacted statute reflects a considered legislative judgment that stripped ex-ante assessment and audit mandates from the previous statute. A rulemaking proceeding cannot restore what the General Assembly explicitly excised. Furthermore, mandating that every internal evaluation become a compelled public disclosure will perversely disincentivize companies from running certain evaluations—directly undermining sound AI governance.
V. Rule 6.4 Rewrites the Disclosure Duty into an Engineering Mandate
Rule 6.4(B) dictates that an Adverse Outcome Disclosure must explain and identify underlying Personal Data used to generate inferences, profiles, or risk scores. Under this framework, a Deployer is out of compliance anytime it cannot articulate at the level of the individual consumer precisely how an automated output shaped a particular decision.
This transforms a statutory notice obligation into an engineering design mandate, effectively requiring per-decision interpretability for every covered system. Again the proposed rules would reimpose an ex-ante regulatory approach that the General Assembly sought to rectify, requiring that AI be re-architected from the ground up instead of regulating misuse.
The statutory duty is satisfied by an honest, comprehensible account of the system and its role in the decision process. Layering a decision-by-decision explainability guarantee on top of this collides with the statutory protection against forcing the surrender of proprietary system details. Rules 6.4(B)(11) and (B)(12) exceed the Office’s rulemaking authority and should be struck in their entirety.
VI. Rule 7.3 Confuses Data Access with a Right to System Outputs
Rule 7.3 instructs Deployers to hand over “specific pieces of Personal Data,” explicitly categorizing “final rank, score, classification, recommendation, prediction, or other inferences,” as well as “all ADMT inputs,” as Personal Data a consumer may demand.
This misinterprets the statute. What a system generates about a person is the operator’s proprietary work product, not the individual’s Personal Data. The statutory access right reaches only the Personal Data actually used in the consequential decision. Furthermore, the all-inputs requirement is operationally untenable; modern systems process thousands of data points per individual, the vast majority of which are immaterial to a specific decision. Rule 7.3 must be re-anchored to the statutory text and limited strictly to the data that genuinely bore on the decision at issue.
VII. Rule 7.4: The Correction Remedy Must Be Scaled and the Stay Removed
Rule 7.4 requires Deployers to correct Personal Data “in its existing systems,” reading more like an IT-architecture command than a data-accuracy remedy. This should be restated so the obligation scales to the data and the processing purpose.
More problematically, Rule 7.4 mandates that “[w]here possible, an Adverse Outcome must be stayed pending correction of incorrect Personal Data”. No such pause appears in the statute. Because a consumer’s bare assertion of inaccuracy is deemed sufficient for third-party-sourced data, any consumer can freeze commercial decision-making simply by contesting a data point without supporting evidence. The stay provision should be struck.
VIII. Rule 7.7: Reconsideration Requires Materiality and Feasibility Limits
Rule 7.7 obligates a Deployer to re-perform the decision-making process whenever a consumer exercises their right to correct Personal Data. The rule contains no requirement that the correction could plausibly alter the outcome, nor does it accommodate decisions that are final and irreversible.
Under the current draft, any successful data-correction request—however trivial the field—forces an organization to indefinitely reopen settled decisions. Reconsideration must be conditioned on a consumer’s identification of the corrected data and a plausible explanation of its materiality to the adverse outcome. Additionally, re-performance must be excused where the decision has been fully executed and unwinding it is not commercially reasonable.
IX. Rule 7.7: Meaningful Human Review Should Not Trigger a Statutory Stay
Rule 7.7 mandates that “[w]here possible, an Adverse Outcome must be stayed pending Meaningful Human Review”. It also establishes a fixed 45-day window for completing the review and providing a response.
As with the correction stay, suspending the underlying decision pending review converts a procedural right into a substantive veto without statutory authorization. Furthermore, the fixed 45-day completion window ignores the reality that review demands will spike unpredictably during hiring cycles or enrollment periods. The cumulative design of these draft rules—implementing stays at multiple points alongside compressed clocks—forces organizations to prioritize speed over substance. The Office should adopt a flexible, risk-calibrated response framework and remove the unauthorized stay provisions.
X. “Accessible to the General Public” Sweeps in Unintended Enterprise Tools (Rule 2.2)
The definition of “Accessible to the General Public” excludes only “an internal-only workforce deployment through restricted, authenticated environments that are not Consumer-facing”. This narrow exclusion captures a wide array of business tools—such as procurement assistants or order-status bots—that share none of the relational, open-ended engagement dynamics targeted by the Chatbot Safety Act.
The Office should expressly exempt systems built principally for enterprise customers, customer-service tools, embedded features of broader non-companion products, and tools deliberately confined to narrow, discrete tasks. Subjecting routine enterprise bots to companion-chatbot compliance obligations imposes heavy costs without advancing consumer protection.
XI. The “Age Category” Definition Improperly Extends Age Assurance to Adults (Rule 2.2)
The Chatbot Safety Act (HB 26-1263) is targeted at minors. Yet Rule 2.2 defines “Age Category” to include bands for individuals “at least eighteen but under twenty-five years of age” and “over twenty-five”. Consequently, Rule 13.4 requires Operators to report user distribution across all these categories in their Annual Report.
This functionally obligates Operators to build mandatory age-estimation infrastructure for adults, representing a significant policy expansion masked as a mere definition. It lays the groundwork for extending youth-protective duties to young adults without legislative approval. The definition must be pared down to the bands the statute actually regulates—under 13, 13 to 17, and adult.
Thank you for the opportunity to provide input. We welcome any questions and would be glad to serve as a resource to the Department throughout this rulemaking.
Sincerely,
Patrick Hedger
Director of Policy, NetChoice (The views of NetChoice expressed here do not necessarily represent the views of all NetChoice members.)
NetChoice is a trade association that works to protect free expression and promote free enterprise online.