Build a Colorado AI Inventory Before High-Risk Duties Start

Colorado’s AI law is scheduled to take effect in June 2026 after lawmakers delayed its original effective date. Its central operational trigger is not whether a company has purchased something marketed as AI; it is whether an AI system makes, or materially influences, a decision about a Colorado resident in a covered area such as employment, housing, lending, healthcare, education, insurance, legal services, or an essential government service.

The attorney general can enforce the enacted statute. Rulemaking may clarify implementation, but proposed language and stakeholder suggestions are not enforceable requirements unless adopted in final form. Teams building an inventory now should therefore label every field according to its source: enacted law, final rule, internal control, or unresolved interpretation. This walkthrough uses the enacted framework as its baseline and is not legal advice.

Keep one concrete workflow in view: a hypothetical applicant-screening system that reads resumes, assigns candidates a score, and ranks them for a recruiter deciding whom to interview for a warehouse supervisor position. That single row exposes most inventory failures. Procurement knows the vendor, recruiting knows how the ranking appears on screen, security knows where data moves, and legal may know the notice language. Nobody necessarily knows whether recruiters routinely follow the ranking.

Start with decisions, not software catalogs

A conventional software inventory usually records an application name, owner, vendor, contract date, and security classification. That is useful but insufficient here. Colorado defines a high-risk AI system as one that “makes, or is a substantial factor in making, a consequential decision.” A consequential decision has a material legal or similarly significant effect on access to, the cost of, or terms for one of the covered services or opportunities.

Start by listing covered decision workflows, then trace the technology inside each one. Ask employment operations how applicants are screened, lending teams how applications are priced or declined, and housing staff how tenants are prioritized. This catches embedded AI features that never passed through a centralized AI purchasing process, including a scoring module added to an existing software subscription.

For the applicant screener, the unit of inventory is not the vendor’s underlying model. It is the deployed system within a defined workflow: resumes enter, the system extracts information and produces a ranking, a recruiter sees that ranking, and selected applicants proceed to an interview. The same vendor product used only to format job descriptions would be a separate use case because its decision role and potential impact differ.

Create one row for every distinct combination of system, purpose, affected population, and decision workflow. A practical first-pass schema looks like this:

| Field | What to record for the applicant screener | |---|---| | System and owner | Product name, internal recruiting owner, technical owner, vendor | | Purpose and context | Rank applicants for warehouse supervisor interviews in Colorado | | Decision and subject | Interview selection affecting job applicants | | System role | Score and ordered list shown before recruiter selection | | Inputs and output | Resume and application fields; candidate score and ranking | | Human control | Recruiter may reorder candidates; record whether this occurs in practice | | Potential impact | Qualified applicant may receive less consideration or no interview | | Evidence status | Vendor documentation received, reviewed, missing, or contractually unavailable | | Monitoring and change | Review owner, last assessment, model or configuration changes, incident link |

Do not fill uncertain cells with “human in the loop.” That phrase describes an interface arrangement, not a control. Record what the person sees, whether the AI output arrives before the judgment, whether overriding it requires extra work, and whether logs preserve the final choice. A recruiter who can ignore a score but almost never does may leave the system as a substantial factor in practice.

Test the system’s actual decision role

Use a short decision-role test for every candidate row. First, identify the covered decision without mentioning AI. In the example, it is the choice of applicants who receive interviews. Then reconstruct the system’s output and where it appears in the sequence.

Finally, determine whether removing or changing that output could alter the result.

That last point needs evidence. Interview the workflow owner, inspect configuration screens, sample logs where available, and compare written policy with ordinary use. If the applicant score automatically removes candidates below a threshold, the system has a direct role. If the ranking changes which resumes a recruiter sees first, its role may remain substantial even though a person clicks the final button.

A genuinely administrative tool that schedules interviews only after candidates have been selected sits elsewhere in the workflow.

Record the conclusion as “likely in scope,” “likely outside scope,” or “needs review,” followed by the facts supporting it. Avoid a bare yes-or-no field. The applicant row might say: “Likely in scope because the ranking is displayed before interview selection and recruiters use the ordered queue; override frequency is not yet measured.” That sentence gives the next reviewer something to verify.

Build the impact record alongside the inventory

Colorado’s framework calls for deployers of high-risk systems to maintain a risk-management policy and complete impact assessments at least annually and within 90 days after an intentional and substantial modification. The assessment must address the system’s purpose, intended use, deployment context, limitations, discrimination risks, data, performance measures, transparency measures, and safeguards, among other statutory elements.

Do not treat the inventory and assessment as separate projects. Add links from the applicant-screening row to the current impact assessment, test results, operating procedure, consumer notice, appeal route, and incident record. A missing link becomes visible work rather than an assumption buried in a compliance memo.

For impact, describe a plausible pathway rather than writing “bias risk.” The screener may infer experience from job titles, normalize employment gaps, or weight credentials that correlate with access to particular institutions. The inventory should state which inputs reach the system, which protected or proxy characteristics are excluded or retained, what evaluation the deployer can run, and what fallback applies if performance cannot be supported. That fallback might be unranked review, a different screening method, or suspension of the tool for the affected role.

Performance costs belong in the record too. Turning off ranking may increase recruiter review time; retaining it may produce consistency while obscuring qualified candidates whose resumes do not match historical patterns. Do not invent an accuracy figure because the vendor dashboard displays a generic score. Record the population, outcome, comparison method, and date behind every metric, or mark the metric unusable for the deployed context.

Turn missing vendor material into named evidence gaps

Developers of covered systems have their own documentation duties under the Colorado framework, including information intended to help deployers understand intended uses, limitations, discrimination risks, evaluation, data governance, and monitoring. A contract promise to “support compliance” is not the evidence itself.

For the applicant screener, request documentation that identifies the intended hiring uses, known unsuitable uses, input and output design, training-data governance at the level the law requires, evaluation methods, relevant performance limitations, discrimination mitigations, and post-deployment monitoring. Also ask how the vendor announces model, feature, or threshold changes. A silent update can invalidate an assessment even when the product name and contract stay the same.

Give each request an owner, status, due point, and consequence. “Model card missing” is too vague; a model card is a structured description of a model’s intended uses and evaluation, but it may not cover the configured product or the customer’s workflow. Write instead: “No evidence that ranking performance was evaluated for this job family; recruiting analytics owner to determine whether local validation is feasible before continued use.”

Some vendors will decline to disclose proprietary details. The inventory should preserve that refusal and the deployer’s response. A confidentiality claim does not prove the system is unsafe, but it can leave the deployer unable to complete an assessment or explain an adverse decision. At that point, the operational choices are narrower: negotiate access, test independently, constrain the use, or replace the system.

Attach controls to the moment they operate

Colorado’s law includes consumer-facing duties around notice and, after an adverse consequential decision, explanation, correction, appeal, and human review where technically feasible. An inventory entry should point to the control at the relevant stage, not merely state that a policy exists.

For the applicant workflow, record where notice appears before the consequential decision, how an applicant can correct inaccurate personal data, which team receives an appeal, and what information lets a reviewer reconsider the result without blindly reproducing the ranking. Test the route with a fictional record. If an appeal enters a general support queue that cannot identify the model output or retrieve the application version, the control exists on paper but not in operation.

Change management closes the loop. Procurement should require advance notice of material product changes, while the technical owner records configuration edits and the business owner confirms whether the workflow changed. Preserve completed impact assessments for the statutory retention period, and keep enough version information to reconstruct which system configuration affected a given decision.

Return to the applicant row after this work. It should now show the decision role, evidence for that conclusion, links to controls, unresolved vendor gaps, and a named owner empowered to pause the ranking feature. If it still says only “AI recruiting tool, medium risk,” the inventory cannot support an assessment, an appeal, or an attorney general inquiry.

Keep enacted duties separate from proposed detail

Build a source column into the register. Cite the Colorado statute for the high-risk definition, assessment cadence, documentation duties, and consumer protections. Add final attorney general rules if and when they apply. Put draft rules, public comments, and preferred internal practices in separately labeled rows so nobody mistakes a proposal for an enforceable requirement.

That distinction also prevents teams from waiting for every detail to settle. The exact template may change, but the underlying facts will still be needed: what the system does, which consequential decision it affects, how its output changes that decision, who can intervene, what harm can follow, and what evidence supports the controls.

Questions people ask

Does every

AI tool need a Colorado impact assessment?

No. The statutory assessment duty centers on high-risk AI systems used to make, or act as a substantial factor in making, a covered consequential decision. Keep lower-risk tools in a broader technology register, but document why uses such as interview scheduling or text formatting do not influence the underlying employment decision.

Is a human reviewer enough to keep a system outside the law?

Not by itself. Record whether the reviewer sees the AI output before deciding, how often people override it, whether the interface favors the recommendation, and whether the output changes which cases receive attention. Those facts matter more than a policy statement that assigns final authority to a person.

What should we do when a vendor will not provide evidence?

Log the exact missing material, the vendor’s response, and the compliance or testing task it blocks. The deployer can seek contractual access, conduct context-specific evaluation, limit the system’s role, or choose an alternative. Continuing unchanged while recording only “proprietary” leaves the underlying evidence gap unresolved.

Can one inventory row cover every use of the same product?

Only when the purpose, affected population, decision role, configuration, and controls are materially the same. Resume ranking and interview scheduling should be separate entries even if one platform performs both, because only the ranking use directly affects who receives consideration for employment.