Submission to the Colorado Attorney General: Proposed ADMT Rules, 4 CCR 904-6, 19 October 2026

Technical submissions Fijishi has made to courts' committees, regulators and AI authorities, each published here with its filing date.
Fijishi
Akhil Sharma and Preethi Sharma
Posts: 157
Joined: Fri Feb 27, 2026 7:56 pm

Submission to the Colorado Attorney General: Proposed ADMT Rules, 4 CCR 904-6, 19 October 2026

Post by Fijishi »

On 19 October 2026 Fijishi submitted written comments to the Colorado Department of Law on the Automated Decision-Making Technology (ADMT) provisions of the proposed rules under 4 CCR 904-6, as set out in the interim draft released on 6 October 2026. The comment period closes on 26 October 2026.

The document is dated 23 October 2026; it was submitted on 19 October 2026.

Our comments cover six points: contemporaneous evidence of independent judgment (Rules 2.2 and 6.1(B)(5)); third-party ADMT (Rule 4.3); developer instructions (Rule 5.2(C)(3)); the version number given to consumers (Rules 7.4(A) and 7.6(A)(3)); errors found during Meaningful Human Review (Rule 8.7(D)(2)(b)); and the reviewer's authority and the review record (Rules 8.7(C) and 8.7(H)). Each point proposes wording.

Submitted through the Attorney General's public comment form. Comments received are published by the Attorney General's office as part of the rulemaking record.

Consultation: Colorado Attorney General - ADMT and Chatbot Safety rulemaking

The full text of our submission follows.

Full text of the submission

Comments on the proposed Automated Decision-Making Technology & Conversational Artificial Intelligence Service Rules, 4 CCR 904-6

To: Colorado Department of Law, Consumer Protection Section
From: Fijishi
Date: 23 October 2026

Fijishi is an independent organisation based in Pune, India, that works on the governance of AI decisions.

These comments concern the Automated Decision-Making Technology (ADMT) provisions of the interim draft rules released on 6 October 2026. Rule numbers refer to that draft. We do not comment on the Conversational Artificial Intelligence Service provisions.

The six points below share one theme: the records and controls a Deployer needs in order to show, after the event, how a Consequential Decision was made and what was done when something went wrong. Each point proposes wording. In points 3 and 4, the existing rule text is quoted as it stands in the interim draft, and the words we propose to add are underlined.

1. Contemporaneous evidence of independent judgment - Rule 2.2 ("De Minimis Factor") and Rule 6.1(B)(5)

Rule 6.1(B)(5) allows the presumption of Material Influence to be rebutted by "other persuasive evidence, including contemporaneous evidence, showing judgment independent of the ADMT output." Item 5 of the cover letter published with the interim draft asks what alternative to the rebuttable presumption would let the parties determine whether an output was a de minimis factor, "outside of the Deployer simply asserting that the output was a de minimis factor".

Whichever approach is adopted, the question can be answered on evidence if the Deployer keeps a record made at the time of each Consequential Decision. The considerations already listed in the definition of "De Minimis Factor" in Rule 2.2 (items 1 to 4) indicate what that record would need to show: whether the decision maker saw the output, what other information they reviewed, whether they had authority to decide differently, and whether the decision was consistent with the output.

Proposed addition to Rule 6.1(B)(5):
"Contemporaneous evidence may include a record, made at the time of the Consequential Decision, that identifies: the ADMT output presented to the decision maker and the version of the ADMT that produced it; the other information the decision maker reviewed; the decision maker and their authority to make or change the decision; the time of the decision; and whether the decision was consistent with the ADMT output."
A record of this kind is similar in content to the "contemporaneous documentation" that Rule 8.7(H)(1) requires for a Meaningful Human Review, so a Deployer could keep both in one format.

2. Third-Party ADMT - Rule 4.3

Rule 4.3(A) makes the Deployer "responsible for fulfilling all Deployer obligations" where a third party runs a Covered ADMT on its behalf or at its direction. Rule 4.3(B) allows the Deployer to contract with the third party "to perform functions to assist the Deployer in satisfying its Deployer obligations".

Several Deployer obligations depend on matters the third party controls: the version number in Rules 7.4(A)(ii) and 7.6(A)(3); the sources of Personal Data in Rule 7.6(A)(5), which the Deployer is presumed to know where a vendor runs the Covered ADMT on its behalf; and the reconfiguring of the Covered ADMT and re-performing of the decision in Rule 8.7(D)(2)(b)(1). Where one Covered ADMT is run by a third party for more than one Deployer, each Deployer also needs to be able to stop its own use without depending on the others.

Proposed addition to Rule 4.3(B):
"Functions that a Deployer may require under such a contract include: (1) the ability to suspend use of the Covered ADMT for the Deployer's Consequential Decisions, or for one type of them, without the third party's consent; (2) notice, before they take effect, of changes to the Covered ADMT, its version or its configuration that affect the Deployer's Consequential Decisions; and (3) access to records of the outputs produced for the Deployer's Consequential Decisions, both during the contract and after it ends."
The wording is permissive, consistent with the existing "may" in Rule 4.3(B).

3. Developer instructions - Rule 5.2(C)(3)

Rule 5.2(C)(3) provides that a Developer should include "instructions the Deployer needs to appropriately direct, control, modify, and adjust the Covered ADMT". A Deployer that finds a problem with one type of Consequential Decision may need to stop the Covered ADMT for that type alone, while its other uses continue.

Proposed wording for Rule 5.2(C)(3), with our added words underlined:
"Include instructions, to the extent possible, for determining the reasoning and primary factors relied upon by the Covered ADMT to produce an output that Materially Influenced a specific Consequential Decision, and instructions the Deployer needs to appropriately direct, control, modify, and adjust the Covered ADMT, including instructions for suspending its use for a specific type of Consequential Decision without affecting its other uses, and any instructions that may assist a Deployer to mitigate any known limitations or risks of the Covered ADMT."
4. Version number - Rules 7.4(A) and 7.6(A)(3)

Rules 7.4(A)(ii) and 7.6(A)(3) require the Deployer to provide "the Covered ADMT version number, if applicable". Where the Covered ADMT is updated over time, the information that helps the Consumer is the version that produced the output in their decision, which may differ from the version in use when the request is answered. A Deployer can provide this only if it keeps a dated record of version and configuration changes.

Proposed wording for the words quoted above, in both Rule 7.4(A)(ii) and Rule 7.6(A)(3), with our added words underlined:
"the Covered ADMT version number in use when the Consequential Decision was made, if applicable"
Proposed wording for Rule 7.6(A)(3) as a whole, with our added words underlined:
"Include in its response the information about the Covered ADMT and the inputs, including the name of the Covered ADMT, the Covered ADMT version number in use when the Consequential Decision was made, if applicable, the Covered ADMT Developer, and the types, categories, and sources of Personal Data used. A Deployer may meet this requirement by keeping a dated record of changes to the version and configuration of the Covered ADMT, so that each Consequential Decision can be linked to the version that produced the output."
5. Errors found during Meaningful Human Review - Rule 8.7(D)(2)(b)

Rule 8.7(D)(2)(b) addresses review where the Covered ADMT "may have functioned incorrectly, or did not function as intended", and Rule 8.7(D)(2)(b)(1) provides for "re-configuring the Covered ADMT and re-performing the decision-making process". The example in Rule 8.7(E)(5)(b) describes a Covered ADMT that did not function correctly "because it was incorrectly configured".

When such an error is found, it may also have affected Consumers who did not request review, since Meaningful Human Review is exercised on request (Rule 8.7(A)). The draft does not currently say what the Deployer should consider about those other decisions.

Proposed new Rule 8.7(D)(4):
"Where a Meaningful Human Review finds that a Covered ADMT functioned incorrectly or was incorrectly configured, the Deployer should consider: (a) whether other Consequential Decisions made while the error was present may have been affected, and how those decisions can be identified and re-examined; and (b) whether to suspend use of the Covered ADMT for the affected type of Consequential Decision until the error is corrected."
6. Reviewer authority and the review record - Rules 8.7(C) and 8.7(H)

Rule 8.7(C)(1) requires that the reviewer have "actual authority to approve, modify, or override" the decision, and Rule 8.7(H)(1)(a) requires a record of the reviewer's "identity, authority, and relevant training". Two additions would make the record more useful for later scrutiny.

First, where a review leads to a change in the Covered ADMT, as Rule 8.7(D)(2)(b)(1) contemplates, the record could show that change, so that it can be linked to the other decisions discussed under point 5.

Proposed new Rule 8.7(H)(1)(g):
"Any change made to the Covered ADMT or its configuration as a result of the review."
Second, Rule 8.7(H) does not state how the record is kept or for how long.

Proposed new Rule 8.7(H)(2):
"The Deployer should keep the record in a form in which any later alteration or deletion is itself recorded, and for a period that the Deployer sets having regard to the time within which a complaint, appeal or claim about the Consequential Decision may be brought."
We are grateful for the opportunity to comment.

Akhil Sharma and Preethi Sharma, Fijishi
Fijishi Enterprises Private Limited
protocol@fijishi.com