Build the Record Before the Decision
Once an AI use falls within Colorado's consequential-decision framework, the next question is not simply who bought the software. It is whether the right information can move from the developer through any integrator to the deployer before a decision is made, and whether the resulting decision can later be reconstructed. This article follows that developer-to-deployer evidence chain—documentation, intended use, updates, versions, records, and legal interfaces—so readers can see how responsibility is preserved across a changing system.
Developer documentation is an operating boundary
SB26-189 places an upstream knowledge duty on the developer of a Covered ADMT. Beginning January 1, 2027, the developer must make information available to each deployer in a form and manner that is reasonably understandable to a deployer and that protects trade secrets or information protected by law. The required information is not an invitation to hand over source code. It is the information a deployer needs to know what the system is for, when it should not be used, and how its output must be handled.
The statute names five practical categories. The developer must describe intended uses and known harmful or inappropriate uses; describe categories of data used to train the system, to the extent known; identify known limitations, risks, and circumstances in which the system should not be used; provide instructions for appropriate use, monitoring, and meaningful human review where applicable; and supply information reasonably necessary for the deployer's consumer disclosures. The rulemaking document makes those categories more concrete by asking the developer to identify the types of consequential decisions for which the system is intended and those for which it is inappropriate or harmful.
That last distinction matters more than a general claim that a model is “high performing.” A deployer needs to know whether a system was built to rank job applicants, estimate the risk of property damage, recommend a credit decision, or support some other consequential use. The relevant question is not whether the system can produce a number in any context. It is whether the developer has described the context in which the output can be used responsibly and the context in which it should not be used.
The rules also connect documentation to monitoring. Instructions may need to identify the data categories the system requires, methods for collecting and analyzing aggregate performance information, and ways to review an output that materially influenced a particular decision. Where appropriate, they should help the deployer determine the reasoning and principal factors behind an output and adjust the system or mitigate known risks. A deployer cannot perform meaningful review if it receives only a result but no intelligible account of the system's intended use, limitations, inputs, or principal factors.
Trade-secret protection changes the form of disclosure, not the existence of the duty. Under the rulemaking document, information may be withheld only when it is a trade secret or protected from disclosure by state or federal law or another legal authority. The developer must identify the legal authority for withholding it and still provide enough information to satisfy the statutory requirement without revealing the secret. This is a narrower response than saying that an entire system is proprietary.
Intended use must survive organizational handoffs
The statute also requires a developer to give notice within a reasonable time of material updates, intentional and substantial modifications, and changes to intended use, limitations, or risk mitigation. Public release notes can be used if the developer directly tells each deployer about the release. The statute defines a material update broadly enough to include an update, patch, release, revision, or new version—including associated software, model parameters, default settings, or documentation—that the developer knows or reasonably should know is likely to materially affect relevant outputs, performance, or stated intended use. Routine maintenance, cosmetic changes, and non-material bug fixes are outside that definition.
This is a lifecycle rule. A system's compliance story cannot be frozen on the day it is purchased if the version used in a decision is materially different from the version originally documented. A changed default setting may alter the output even if the model name is unchanged. A new model parameter may affect performance in the intended domain. A revised limitation or mitigation instruction can change what the deployer is expected to do. The update notice is the link between those changes and the decision record.
The handoff becomes more complicated when a product embeds another party's system. The rules call this a midstream arrangement. An integrator that incorporates Covered ADMT into its own Covered ADMT product and passes that product to another developer or deployer must reasonably obtain the upstream developer documentation and make it available downstream. The supplied example is an application that integrates a third-party foundational large language model and is then sold to customers who configure it with their own data for a consequential use.
The midstream rule addresses a predictable failure. The downstream deployer may interact only with the integrator, while the integrator may treat the underlying model as someone else's responsibility. Without a pass-through obligation, information about training-data categories, limitations, intended uses, and review instructions can disappear between the model provider and the organization that actually uses the output. A product's commercial packaging does not eliminate the need for an evidence chain.
Deployment creates a reconstructable decision record
The deployer has a different responsibility. The deployer is the person doing business in Colorado that deploys a Covered ADMT, and the statute requires the deployer to retain records reasonably necessary to demonstrate compliance for at least three years after the consequential decision, or longer if another law requires it. The statute gives version identifiers, changelogs, and documentation of material mitigation changes as examples. The rulemaking document adds the information needed to explain an adverse outcome or conduct human review: the system and version, developer, inputs, data sources, evidence considered, reviewer, timestamps, review type, and the result.
Those records are most useful when treated as a decision event rather than as a general archive. Imagine a housing provider using a score to set a security deposit. A later reviewer may need to know which score was generated, which version produced it, what data the system considered, what role the score played alongside any employee judgment, and whether a material mitigation change had occurred shortly before the decision. A folder containing the current model description but no historical version may not answer those questions.
The lifecycle has several meaningful transitions:
At the first transition, the system has an intended purpose. At the second, that purpose is expressed in information another organization can understand. At integration, the information either remains available or is lost. At deployment, the deployer adds configuration and use facts that the upstream developer may not know. At a material update, the historical identity of the system must be preserved rather than overwritten. At the decision, the output becomes connected to one person's circumstances. A request for information or review then adds evidence from the consumer and the reviewer. Retention keeps those states available for later explanation.
The loop matters because deployment is not the end of the lifecycle. A later update can change the system's behavior, intended use, or mitigation. The organization must be able to distinguish a decision made before that update from one made after it. Otherwise, a general statement about how the system works today may be incorrectly applied to a past outcome.
A complete record is not proof of a lawful decision
Traceability improves accountability, but it does not settle the underlying legal question. The rules make a meaningful explanation and review depend on knowing how a Covered ADMT influenced a decision and how it used a consumer's personal data. Missing evidence is therefore an operational problem. Conversely, a complete record does not prove that the underlying decision satisfies every other applicable law; the statute and rules expressly preserve that boundary.
This is why the evidence chain should not be designed only around defending a file after an incident. Its earlier purpose is to prevent a deployer from using a system outside its documented boundary, to make limitations visible before a decision, and to give a reviewer enough context to determine whether the system or the underlying evidence failed. Recordkeeping is valuable when it changes behavior before the adverse outcome, not only when it supplies an explanation afterward.
Other legal regimes shape the same record
Colorado's framework is designed to meet other notice and privacy systems at their boundaries. For a credit decision, a creditor that must provide a notice under the federal Equal Credit Opportunity Act—and, when applicable, the Fair Credit Reporting Act—does not necessarily need a separate Colorado notice if the federal notice also contains the information Colorado requires. The point is coordination, not automatic substitution: the notice must satisfy both sets of requirements.
Education shows a similar approach. A deployer subject to the Family Educational Rights and Privacy Act may use its existing student-record inspection, notice, and amendment procedures for the Colorado rights and disclosures, including the applicable route through a parent, guardian, or eligible student. It need not create a duplicate process if the established procedure offers a reasonable way to request correction and reconsideration.
Health care has a more complicated boundary. The statute broadly excludes HIPAA-covered entities and business associates from several Part 17 provisions, except for consequential employment decisions, while requiring a covered entity to give patients a general notice of advanced technologies and specifying disclosures for eligibility for financial assistance. Protected health information cannot be disclosed in a way that violates federal law. Medical devices subject to FDA oversight and certain research activities are also excluded from the listed provisions.
These interfaces reinforce the importance of knowing what each record is meant to accomplish. A federal adverse-action notice may carry Colorado information, but it cannot contain less than either regime requires. A FERPA process may carry a correction request, but it must actually support the applicable Colorado right. A health-care disclosure must respect federal confidentiality limits. A shared process reduces duplication only when its contents and access route remain adequate for every applicable duty.
The handoff is the real control point
The developer-to-deployer chain can now be evaluated with a few concrete questions. Was the system's intended consequential use stated plainly? Were harmful or inappropriate uses identified? Can the deployer see meaningful categories of training and input data, known limitations, monitoring instructions, and human-review guidance? If another organization integrated the system, did the relevant information survive that handoff? When the system changed, can the deployer identify which version and mitigation state affected a decision?
The questions are operational, but they also define what a later consumer explanation can honestly say. If the deployer cannot identify the system or its inputs, a notice may become vague. If the developer's limitation never reached the deployer, the use may drift beyond its documented purpose. If the version record is overwritten, a reviewer may assess today's system rather than the system that produced yesterday's result. If an external notice is reused without checking its contents, coordination may become an excuse for omission.
A record therefore has two jobs. It preserves evidence about what happened, and it keeps the organizations involved from treating responsibility as someone else's artifact. The next test is whether that chain can be followed for one actual decision—from coverage, to ownership, to version and evidence, and finally to the information an affected consumer would need for a meaningful explanation.