The question at hand
Colorado's Automated Decision-Making Technology Act (SB 26-189) creates a documentation chain: developers must describe their systems, and deployers must explain those systems to consumers. However, the interim rules released in October 2026 don't fully specify how these obligations connect.
This gap is crucial because it determines who bears the compliance burden when a consumer asks, "Why did your AI deny my application?" If the developer's documentation doesn't cover what the deployer must disclose, the deployer either invents an answer, disclaims knowledge, or faces a violation. None of these outcomes serve the law's intent.
The Future of Privacy Forum's October 26, 2026 comments to the Colorado Department of Law frame this as an alignment problem. Should developer disclosures be explicitly tied to deployer obligations, or should each party's requirements stand independently?
The case for independent obligations
Some practitioners argue that developer and deployer duties should remain separate. Developers build systems without knowing every deployment context. A credit scoring model might be used for auto loans, mortgages, or tenant screening. Each use case triggers different consumer questions and different disclosure needs.
Under this view, developers should document what they know about the system itself: training data characteristics, validation results, and known failure modes. Deployers then translate that technical documentation into consumer-facing explanations appropriate to their specific use.
This approach preserves flexibility. A developer creating a resume screening tool can't anticipate whether a deployer will use it for initial filtering or final candidate selection. The materiality of the system's role differs, so the disclosure should too.
It also avoids forcing developers to become compliance consultants. If developer documentation must enable every possible deployer obligation, developers need expertise in employment law, fair lending, insurance regulation, and housing discrimination. That's not scalable for software companies serving multiple sectors.
The existing structure in the interim rules already requires developers to provide "intended uses and known limitations." Practitioners in this camp see that as sufficient. Deployers should take responsibility for understanding their own compliance obligations and mapping developer documentation to those requirements.
The case for explicit alignment
The opposing view holds that misaligned obligations create a compliance fiction. If a deployer must explain "known risks" to a consumer, but the developer's documentation uses different terminology or addresses different risks, the deployer can't comply without conducting their own risk assessment. That defeats the purpose of developer documentation requirements.
FPF's comments recommend that developers provide "information sufficient to enable deployers to meet their statutory responsibilities, to the extent that information is within the developer's knowledge." This shifts the framing: developer obligations aren't independent; they're instrumental to deployer compliance.
Consider the practical scenario. The law takes effect January 1, 2027. A deployer using ADMT for employment decisions must provide notices and explanations to applicants. If the developer's general statement describes "intended uses" but doesn't specify the performance limitations relevant to employment screening, the deployer faces a choice: conduct additional validation testing to generate that information, or provide incomplete disclosures.
Most deployers lack the technical capacity to independently assess model performance. They can't re-run fairness metrics or evaluate training data representativeness. They depend on developer documentation. If that documentation doesn't map to their disclosure obligations, the regulatory chain breaks.
The alignment approach also promotes standardization. FPF's comments reference model cards and system cards as potential formats. These structured templates already exist in the ML community. Requiring developers to populate fields that correspond to deployer obligations creates interoperability across the supply chain.
This matters for organizations operating in multiple states. California's ADMT regulations emphasize human involvement. Colorado's interim rules propose six considerations for assessing whether ADMT materially influenced a decision. If developer documentation aligns with deployer obligations, it can serve compliance needs across jurisdictions rather than requiring state-specific versions.
Where practitioners actually land
Most governance teams don't treat this as an either/or question. They're building tiered documentation: technical specifications for internal validation teams, general statements for regulatory filing, and consumer-facing explanations for deployers to customize.
The challenge isn't creating multiple documents. It's ensuring the chain of custody works. If your technical documentation says "model performs at 87% recall on the validation set" but your deployer obligation requires explaining "known limitations in accuracy," someone needs to translate that metric into plain language and assess whether 87% recall constitutes a limitation worth disclosing.
That translation step is where alignment breaks down in practice. Developer teams often don't know which performance characteristics matter for consumer disclosure. They document what they measured, not what deployers must explain.
The interim rules' proposal to require documentation of "known risks" illustrates this gap. Does "known" mean risks identified during development testing, risks reported post-deployment, or risks that a reasonable developer should have identified? The answer determines whether a developer who didn't test for disparate impact across protected classes can claim the risk wasn't "known."
Our take
Developer documentation should be explicitly scoped to enable deployer compliance, but not to dictate it. The standard should be: developers must provide the information deployers need to meet their transparency obligations, to the extent that information exists within the developer's knowledge and control.
This means three specific changes to the interim rules:
First, clarify that "known limitations" includes performance characteristics relevant to the system's intended use cases, not just catastrophic failure modes. If you built a resume screener, you tested it on something. Those test results constitute known information about limitations.
Second, establish ongoing disclosure triggers. Developers should notify deployers when material updates occur, when intended uses change, or when newly identified risks emerge post-deployment. The January 1, 2027 effective date creates a snapshot obligation, but ADMT systems evolve.
Third, encourage but don't mandate standardized formats. Model cards work for some systems. For complex multi-model pipelines, a system card might be more appropriate. The requirement should specify the information categories, not the document structure.
The tradeoff is real: tighter alignment increases developer burden and reduces deployer flexibility. But the alternative creates a compliance theater where deployers make disclosures they can't verify and consumers receive explanations no one can substantiate. That doesn't serve transparency. It just distributes liability without distributing knowledge.
