What No One Is Saying About Colorado's ADMT Rules

The Debate Everyone Is Having (and What It Misses)

Colorado's proposed rules for the Automated Decision-Making Technology Act (SB 26-189) have drawn the predictable battle lines. The technology industry is arguing that the rules are too broad. Consumer advocacy groups are arguing they are not broad enough. Insurers want their existing regulatory framework to count. Everyone has filed their positions. The formal rulemaking hearing is set for October 26, 2026.

We read the public comment record. Here is what the major stakeholders are fighting about:

The tech industry wants clearer developer-deployer bifurcation, safe harbors for using established risk management frameworks like the NIST AI RMF, and assurances that companies will not have to disclose proprietary model weights or algorithmic source code. BSA, TechNet, CCIA, and the Colorado Technology Association have all filed some variation of this position.

Consumer advocacy groups want mandatory bias testing, private enforcement rights, meaningful human review standards, and whistleblower protections for engineers who expose flawed AI systems. Consumer Reports, the ACLU of Colorado, EFF, and CDT have driven this side of the debate.

The insurance industry wants the deeming provision in Section 6-1-1708 to mean exactly what they think it means: that compliance with SB 21-169 fully satisfies the ADMT requirements for the practice of insurance.

These are all legitimate positions. They are also the positions you would expect to see in any AI governance rulemaking in any state. They track almost identically to the arguments that appeared in the California CPPA proceedings, the EU AI Act consultations, and a half-dozen other jurisdictions.

What we did not find in the record is any stakeholder asking the question that determines whether the rules will actually work: How does anyone verify that the developer's training data documentation is true?

The Verification Problem Nobody Raised

Section 6-1-1706(1)(a)(IV) of SB 26-189 requires developers to provide deployers with documentation of “the categories of data, including personal data, used to train the Covered ADMT.” The proposed rules elaborate on format, accessibility, and delivery. This is the core transparency mechanism. Everything else in the regulatory architecture depends on this documentation being accurate.

But the statute and the proposed rules are silent on verification. The developer writes a document saying what data it used. The deployer receives the document. The Attorney General can request it. At no point in this chain does anyone independently confirm that what the document says matches what actually happened.

Disclosure without verification is attestation. It is the developer's word, unaudited.

This is not a theoretical concern. It is the same structural weakness that appears everywhere AI training data intersects with legal liability. The developer has complete knowledge of what data it used. The deployer has none. The regulator has none. There is a word for this arrangement: information asymmetry. And we know from decades of experience in financial regulation, environmental compliance, and healthcare quality that information asymmetry does not resolve itself through disclosure mandates alone. You need someone in the middle whose job is to check.

In the entire Colorado ADMT public comment record, no commenter other than Box Commons raised this point. The tech industry argued about the scope of what must be disclosed. Consumer groups argued about whether the disclosure requirements go far enough. Neither side questioned the mechanism by which the disclosed information would be confirmed. The debate was about what to require in the document, not about whether the document would be true.

The Insurance Exclusion Nobody Connected

While the policy community has been debating bias testing protocols and safe harbor language, the insurance industry has already confronted the verification problem in a way that has direct consequences for Colorado's ADMT rules.

In January 2026, Verisk ISO released exclusionary endorsement forms CG 40 47 and CG 40 48, stripping AI-related bodily injury, property damage, and advertising injury from standard commercial general liability policies. Approximately 95% of carriers are adopting these exclusions. The companion endorsement CG 35 08 applies to professional liability. This is not a future risk. It has already happened.

The immediate consequence is that any company deploying AI systems trained on data of uncertain provenance now faces an uninsurable liability exposure under standard commercial policies. Enterprise customers require their vendors to carry adequate insurance. Government contracts require it. If an AI developer cannot demonstrate the provenance and consent status of its training data, it cannot get insured, and if it cannot get insured, it cannot sell to its most valuable customers.

The specialty insurers who have stepped into this gap — Armilla (up to $25 million, Lloyd's-backed), Munich Re's aiSure program (up to €15 million), Testudo (up to $9.25 million) — all require data provenance audits as a condition of coverage. Not disclosure forms. Not developer attestations. Independent, third-party audits. They learned, from the same Gallagher Re data showing a 978.1% increase in generative AI-related lawsuits from 2021 to 2025, that self-attestation is insufficient to quantify risk.

No other commenter in the Colorado ADMT docket connected these insurance market developments to the training data documentation requirements. The insurance industry's filing focused on the deeming provision. The tech industry's filing focused on scope. Nobody pointed out that the insurance market has already solved the verification problem that the proposed rules do not address, and that the insurance market's solution is independent certification.

The Vendor Oversight Bottleneck

The verification gap becomes particularly acute in the vendor oversight context. Most deployers in regulated industries do not build their own AI systems. They purchase or license AI tools from third-party developers. The deployer's compliance obligation under SB 26-189 depends on the accuracy of documentation it receives from a vendor whose internal practices it cannot independently observe.

This is not a new problem. It is the standard third-party risk management challenge that appears in every regulated industry. Healthcare solved it with HITRUST. Financial services solved it with SOC 2. Payment card processing solved it with PCI DSS. In every case, the solution was the same: an independent third party verifies the vendor's claims, and the verification travels with the vendor's product or service so that every downstream customer can rely on it.

Colorado's ADMT rules create a deployer obligation without creating a verification mechanism. The deployer must oversee its vendors. The rules do not specify how a deployer is supposed to determine whether the vendor's training data documentation is accurate. In practice, the deployer will accept the documentation at face value because it has no practical alternative.

This is not compliance. It is paperwork.

Independent data certification resolves the bottleneck. When training data is certified by an accredited third-party assessor, the certification mark travels with the data through the supply chain. The deployer can rely on it. The Attorney General can verify it through a public registry. No proprietary systems need to be inspected. No trade secrets need to be disclosed.

The Deeming Provision Gap

Section 6-1-1708 of SB 26-189 contains a provision that has received remarkably little analytical attention: insurers complying with SB 21-169 (the existing algorithmic discrimination law codified at C.R.S. § 10-3-1104.9) are “deemed compliant” with SB 26-189 “regarding the practice of insurance.”

The insurance industry has treated this provision as a clean exemption. File your SB 21-169 attestation, and the ADMT rules do not apply. This reading is convenient but incomplete.

Under DOI Regulation 10-1-1, which implements SB 21-169, insurers must maintain a documented governance framework for the use of External Consumer Data and Information Sources (ECDIS), algorithms, and predictive models. Life insurers have been filing attestations since December 2024. Auto and health insurers face a July 1, 2026 deadline. These governance frameworks require insurers to document and control the data flowing into their algorithmic decision tools.

Here is what the deeming provision actually creates: two parallel compliance pathways that both require the same thing the rules do not provide.

If an insurer goes through the SB 26-189 pathway, it must ensure its developer provides adequate training data documentation — which it cannot independently verify. If the insurer goes through the SB 21-169 pathway, it must maintain a governance framework that documents and controls vendor AI data practices — which it also cannot independently verify.

The deeming provision does not eliminate the vendor data verification requirement. It duplicates it. Both pathways converge on the same bottleneck: the insurer needs a way to confirm that the third-party AI vendor's data practices are what the vendor claims they are.

No commenter in the ADMT docket analyzed this convergence. The insurance industry asked for the exemption. The tech industry did not comment on the insurance pathway. No one pointed out that the deeming provision creates a logical dependency on verification infrastructure that does not yet exist in the regulatory framework.

Certification as Compliance: The Argument That Changes the Frame

The regulatory pattern we are describing — independent certification as a structured compliance mechanism — is not novel in concept. It has been proven repeatedly in adjacent regulatory domains.

The HITRUST Common Security Framework has achieved dominant adoption in healthcare and insurance cybersecurity compliance: over 81% of hospitals and health systems, and 83% of health plans now utilize the HITRUST CSF. State insurance departments accept HITRUST certification as evidence of compliance with NAIC Model Law #668 cybersecurity mandates. The pattern is: published standard, independent assessment, certification mark, public registry, regulatory recognition.

What makes our argument to Colorado different from a generic call for more oversight is that we are not proposing a framework. We are operating one. Box Commons currently runs a live audio data certification pipeline — the BC-Certified Audio Data Standard — validated against a 22-station broadcast radio network. It captures stream metadata, performs copyrighted music exclusion, verifies consent documentation, and maintains a tamper-evident audit trail from source ingestion through dataset finalization. The tools are open-source. Any deployer, developer, or regulator can inspect, reproduce, or adapt them.

This operational proof matters because the most common objection to certification-based compliance is that it sounds good in theory but cannot scale. We have demonstrated that it scales. A 22-station network processing continuous live broadcast streams is not a laboratory exercise. It is an operating system.

Our recommendation to Colorado is narrow and deliberately technology-agnostic: the final rules should recognize that a developer's use of datasets certified by an independent standards body — one meeting defined governance criteria — creates a rebuttable presumption that the developer has provided adequate training data documentation. The proposed rule language does not name any specific standards body. It establishes structural criteria that any qualifying organization could satisfy.

This is how HITRUST works in healthcare. This is how SOC 2 works in cloud services. This is how PCI DSS works in payment processing. The AI training data ecosystem needs the same architecture, and Colorado's ADMT rules are the right place to establish it.

What Happens Next

The formal rulemaking hearing is October 26, 2026. The Attorney General's office will consider the public comments and decide which recommendations to incorporate into the final rules.

If the rules are finalized without addressing the verification gap, Colorado will have created a training data transparency requirement that no one can independently enforce. Developers will file documentation. Deployers will accept it. The Attorney General will have the authority to request it but no practical mechanism to determine whether it is accurate. The rules will generate compliance paperwork without producing compliance.

The alternative is straightforward. Recognize independent certification. Establish governance criteria for qualifying standards bodies. Let the market build the verification infrastructure that the rules need but do not provide. This is not a speculative proposal. The insurance industry is already doing it. Healthcare has been doing it for over a decade. The architecture exists. It works.

The only thing missing is someone in the regulatory process pointing out that the emperor has no verification clothes.

Content Integrity Notice: This analysis was authored by the Box Commons Policy Working Group. Generative AI was used for research synthesis and drafting support. All policy positions, recommendations, and normative claims were formulated and reviewed by human authors.