Build Colorado’s AI Inventory Before the Compliance Clock Starts

Colorado’s AI law is scheduled to take effect in June 2026 after lawmakers delayed its original start date. For deployers, meaning organizations that use an AI system rather than develop it, the central scoping question is whether a system makes or is a substantial factor in making a consequential decision.

Consider an apartment screening workflow. A prospective tenant submits an application, a vendor service checks supplied and third-party data, the service returns a recommendation, and a leasing employee accepts or rejects it. That workflow should become one inventory record, even if the vendor describes its product as fraud detection, decision support or ordinary automation.

Call the illustrative record CO-HOUS-014. The identifier is mundane on purpose. If compliance staff cannot connect a complaint, vendor update or adverse decision to a stable record, the inventory will not produce the evidence that later reviews require.

This is not legal advice, and Colorado’s requirements may change through legislation or rulemaking. The inventory below is an operational starting point built from the enacted statute, not a claim that every field is expressly mandated.

Start with the decision boundary

The Colorado law defines a high-risk AI system around its role in a consequential decision, including decisions involving housing, employment, education, lending, insurance, health care, legal services and essential government services. An AI output is a “substantial factor” when it assists in making the decision, can alter its outcome and was generated by an AI system.

That framing makes a model registry too narrow. A registry might say that the housing company uses a prediction service from Vendor A. CO-HOUS-014 must say that the service ranks rental applications, sends a recommendation to the leasing queue and can change whether an applicant receives an offer. The unit of control is the deployed workflow.

Begin discovery in procurement records, accounts-payable data, single sign-on logs, API key stores and departmental software lists. Ask workflow owners where software ranks, recommends, flags, scores or generates information used in covered decisions. Browser extensions and AI features added to existing software deserve attention because a department may activate them without a new contract.

Do not classify every automation as high risk merely because it contains AI. Record the workflow, then document the scoping conclusion and its basis. A tool that formats an employee’s notes differs from one that ranks job applicants, although the same underlying model could support both.

For CO-HOUS-014, the first fields should read: housing application screening; rental applicants in Colorado; recommendation to approve, deny or request more information; recommendation delivered before the leasing employee’s decision; provisionally in scope. Add the accountable business owner and the person authorized to approve continued use.

Write the purpose as an operational statement

“Improve efficiency” is not a purpose an auditor can test. Use a sentence that names the population, action, output and decision: “The service evaluates rental application data and returns a recommendation that a leasing employee uses when deciding whether to offer an apartment.”

Record the intended use next to prohibited or unapproved uses. If the vendor’s service was purchased to identify inconsistent application details, but staff also use its score to reject applicants, the inventory should show that gap rather than preserve the purchasing description. Actual deployment matters.

Colorado requires a deployer of a high-risk system to “implement a risk management policy and program to govern the deployer’s deployment” of those systems. It also requires impact assessments at least annually and within 90 days after an intentional and substantial modification. The statute specifies assessment material such as purpose, intended use cases, deployment context, data categories, outputs, performance metrics, known limitations, safeguards and discrimination risks.

An inventory is not named as a standalone statutory deliverable. It is the index that lets an organization find those assessments, notices, monitoring results and owners. Label that distinction in the governance policy. Calling the inventory itself a legal requirement would overstate the enacted text.

Record data paths, not copied personal data

For each workflow, identify input categories and their sources. CO-HOUS-014 might receive application fields directly from the applicant, records from a screening provider and variables produced inside the service. Distinguish supplied data from inferred data, which the system derives rather than collects directly.

The record should also identify which inputs can affect the recommendation, where they are stored, how long they remain available and how a person can challenge an error. Do not paste applicant records into the inventory. It should hold metadata, meaning information about the data, plus links to controlled documentation.

This step exposes a common failure: the deployer can name the form fields it sends but cannot explain the attributes a vendor appends. Colorado’s adverse-decision provisions require disclosure of the principal reason or reasons, the degree and manner in which the system contributed, and the types and sources of data processed. If a vendor cannot return that information for a specific result, procurement has created a compliance constraint that policy language cannot repair.

Add an evidence link for each claim. Useful artifacts include a current data-flow diagram, field dictionary, retention schedule, sample output and correction procedure. Give each artifact an owner and review date so the inventory does not point to an abandoned document.

Describe what the human can change

A checkbox labeled “human review” says almost nothing. For CO-HOUS-014, record who sees the recommendation, what underlying information appears with it, whether the employee can override it, which reasons permit an override and whether the system logs that action.

Time matters too. A reviewer handling a large queue with only a score and a few seconds per application may supply formal approval without meaningful judgment. The inventory does not need a fabricated threshold for adequate review, but it should capture queue design, displayed evidence and escalation paths so the organization can test whether review works as represented.

Colorado requires an opportunity to appeal an adverse consequential decision for human review “if technically feasible.” Keep two fields separate: human involvement before the original decision and human review after an appeal. For the second, identify the team that receives the appeal, the information it can reconsider, the correction channel for inaccurate personal data and the system where the outcome is logged.

Also name the fallback. If the screening service is unavailable or produces an unsupported result, staff might switch to a documented manual review. If no fallback exists, say so. An undefined fallback encourages employees to improvise with screenshots, personal accounts or unapproved AI tools, leaving no dependable record.

Map the vendor chain to evidence

CO-HOUS-014 depends on more than the company named on the invoice. Record the contracting vendor, the product, any disclosed model or downstream provider, hosting location when relevant, integration owner and support contact. Note whether the vendor can change models or decision logic without approval, and whether it promises advance notice of material changes.

The law places documentation duties on developers of high-risk systems, including providing deployers with information about intended uses, known or reasonably foreseeable limitations, data governance, evaluation and measures taken to reduce discrimination risks. A deployer should link the received documents to the inventory record and mark missing material rather than assuming the contract covers it.

Ask for output-level reason information, update notices, evaluation documentation, retention terms and access to logs needed for an impact assessment or complaint review. Some vendors will resist because their service is closed or shared across customers. That is a real tradeoff: the product may be cheaper to operate than an internal system while leaving the deployer unable to explain an individual result or detect a silent model change.

Create a material-change trigger in the record. A new model, altered cutoff, added data source, expanded applicant population or changed role for the recommendation should send CO-HOUS-014 back to its owner. The owner can then determine whether the change requires a new impact assessment rather than relying on the vendor’s release label.

Keep the inventory alive

A spreadsheet can support the first pass. Use one row per workflow, stable identifiers and controlled links to evidence; do not force assessments, contracts and logs into cells. Larger organizations may need a governance system that preserves approvals and access history, but buying one before agreeing on the workflow boundary often produces an expensive software catalog.

At minimum, each record should cover status, owner, decision domain, affected population, operational purpose, output and role in the decision. It should then map input categories and sources, human review and appeal paths, fallback behavior, vendor dependencies, monitoring, known limitations, assessment dates and evidence locations.

Reconcile the inventory against purchasing and identity records on a set schedule, while allowing employees to report an unlisted workflow at any time. Tie change management to the identifier. When Vendor A updates the apartment screening service, the ticket should name CO-HOUS-014, the affected documentation and the person deciding whether deployment can continue.

The immediate test is practical. Select a recent recommendation and use only the inventory links to reconstruct what system ran, what data categories it processed, what the employee saw, which vendor version or configuration applied and where an applicant could seek correction. Any missing answer becomes a remediation item with an owner, not another blank field.

Questions people ask

Does every

AI tool belong in the Colorado inventory?

Record AI-assisted workflows broadly enough to support scoping, then identify which ones make or substantially influence consequential decisions. A general writing assistant may remain outside the high-risk category in one use, while the same technology drafting applicant rankings could require closer analysis. Preserve the reason for each classification.

Is a vendor’s AI system card enough documentation?

Usually not by itself. A system card may describe intended uses and limitations, but the deployer still needs its own workflow purpose, input sources, configuration, human authority, appeal path and evidence of what happened in individual decisions. Link the vendor document to the record rather than treating it as the record.

Should the inventory contain personal information?

It should normally describe data categories, sources, retention and correction paths without copying case-level personal information. Store decision logs and applicant records in systems with appropriate access controls, then link to those repositories through a stable evidence reference where authorized staff can retrieve them.

Who should own the inventory record?

Assign ownership to the business role that controls deployment, with named support from legal, privacy, security or model-risk teams as appropriate. For CO-HOUS-014, that owner should be able to pause the screening workflow, require manual review and obtain vendor evidence when a complaint or material update arrives.