Map Colorado AI Decisions Before Buying Compliance Software

Start with a hiring workflow. A company accepts applications for a warehouse supervisor role, sends each résumé through a vendor’s ranking model, and tells recruiters to review the highest-scoring candidates first. The recruiter makes the formal choice, but applicants below the cutoff may never reach a person.

That single workflow gives a governance team more useful information than a company-wide search for products labeled “AI.” It identifies the decision, the people affected, the output that changes their treatment, the vendor and the human fallback. Those facts are what the Colorado AI Act uses to sort systems into obligations.

The Act establishes duties for developers and deployers of certain high-risk artificial intelligence systems. Its central duty is framed as “reasonable care to protect consumers from any known or reasonably foreseeable risks of algorithmic discrimination.” Compliance duties include risk management, impact assessments, notices and documentation, subject to the law’s definitions and exceptions.

This is an operational walkthrough, not legal advice. Whether a particular organization, system or decision falls within the statute can depend on facts outside a technical inventory, including corporate structure, sector-specific law and the current text of amendments or implementing rules. Those calls belong with counsel. The inventory makes them answerable.

Inventory the decision before the model

The first row should describe the warehouse hiring workflow, not “résumé model” or the vendor’s product name. Write down the business action in ordinary language: rank applicants, decide which applications receive recruiter review, and select candidates for interviews.

Then identify the people whose access or terms may change. Under the Act, a consumer is a Colorado resident. That does not mean the inventory should discard every non-Colorado workflow. Geography may sit in an applicant address, a job location, an account record or nowhere reliable at all, and a system may process a mixed population before anyone can isolate Colorado residents.

Next, mark the relevant decision domain. The enacted definition of “consequential decision” covers decisions with a material legal or similarly significant effect on access to, the cost of or terms of education, employment, financial or lending services, essential government services, healthcare, housing, insurance or legal services. Hiring sits directly in the employment category. An AI-written internal meeting summary usually does not.

The difficult gate is whether the system “makes, or is a substantial factor in making” that decision. Colorado’s text reaches an AI-generated output used to assist with a consequential decision when the output is capable of altering its outcome. A human click at the end does not settle the question.

Return to the hiring ranker. If recruiters can inspect every applicant and routinely disregard the order, the model’s practical role differs from a workflow in which only the top band appears in their queue. The inventory should capture that mechanism rather than accept a control description such as “human in the loop,” a phrase that says nothing about what the human can see, change or recover.

For each workflow, record the input, output and action in sequence. In this case: the applicant submits a résumé and form; the vendor extracts features and assigns a score; the applicant tracking system sorts the queue; a recruiter reviews a limited portion; rejected applicants receive a disposition. If a threshold automatically suppresses applications, record who configured it and whether a recruiter can retrieve the hidden records.

That sequence exposes the place where an output becomes consequential. It also identifies the fallback. If the scoring service fails, does recruiting pause, process applications chronologically or rely on a different filter? A fallback can become its own covered workflow when it uses another model.

Give each workflow one evidence-backed row

A spreadsheet is enough for the first pass. One row should represent one use of a system in one decision workflow, because the same model may summarize support tickets in one department and rank insurance claims in another. Product-level inventories collapse those uses and produce assessments too vague to test.

The minimum useful row for the warehouse workflow looks like this:

| Field | Hiring workflow entry | |---|---| | Business action | Select applicants for recruiter review and interviews | | Affected people | Applicants, including Colorado residents | | Decision domain | Employment opportunity | | System output | Applicant score and ranked queue | | How output changes treatment | Recruiters initially see only applicants above a configured band | | System supplier | Ranking vendor; applicant tracking provider if separate | | Operating entity | Employer using the output | | Human authority | Recruiter can advance, reject or retrieve an applicant | | Evidence | Contract, configuration export, screenshots, rejection rules and workflow log | | Owner | Recruiting operations, with HR and technical contacts | | Counsel review | Consequential decision, substantial-factor analysis and any exception |

Do not fill uncertain cells with assumptions. Mark them unknown, assign an owner and retain the source used to close them. A vendor questionnaire may say the system “supports talent acquisition,” while a configuration screen shows that scores below a threshold are excluded from review; the screen is better evidence of the deployed use.

Logs matter, but they are not the inventory. An application log may capture a model score and timestamp without showing that the recruiter interface hid lower-ranked applicants. Conversely, a policy may promise manual review while logs show bulk rejections immediately after scoring. Keep the contract, technical configuration, user procedure and observed execution linked to the same row so reviewers can compare intended and actual use.

Separate the developer from the deployer

The Act assigns different duties to developers and deployers. A developer is generally the person doing business in Colorado that develops or intentionally and substantially modifies an AI system. A deployer is generally the person doing business in Colorado that deploys a high-risk AI system.

In the warehouse example, the ranking vendor may be the developer and the employer may be the deployer. That is a working hypothesis, not a conclusion. If the employer fine-tunes the model, changes its decision logic or combines vendor outputs into a new scoring system, counsel may need to examine whether the organization has also taken on developer obligations.

Procurement labels do not control this analysis. “Software provider,” “customer” and “processor” can help locate contracts, but they do not replace the statutory definitions. Record every organization that builds, modifies, hosts, configures or uses the relevant output, along with the legal entity signing the contract and the entity making the decision.

That map also tells procurement what to request. Developers of high-risk systems have documentation and disclosure duties concerning intended uses, known limitations, data, evaluation and measures taken to mitigate discrimination risks. A deployer cannot complete a meaningful impact assessment from a marketing page. The inventory should flag missing model documentation, evaluation results, version history and notice of substantial modifications rather than pretending those records exist.

Triage without declaring compliance

Once the rows are complete, sort them through four factual gates: a Colorado nexus, a consequential decision domain, an AI system and an output that makes or substantially affects the decision. This is triage. Legal classification comes after the facts are documented.

Create three queues. Send likely covered uses, such as the hiring ranker with an enforced review cutoff, to counsel and the impact-assessment owner. Hold ambiguous uses where evidence is missing or the output’s influence is disputed. Keep apparently out-of-scope uses with a short rationale and a review trigger, such as a future configuration that feeds a résumé summary into applicant ranking.

The Act contains exceptions and narrower provisions for some organizations and technologies. A small-employer provision, for example, depends on more than headcount and should not become a blanket spreadsheet formula. Regulated financial institutions, insurers, healthcare activity and federally governed systems can raise overlapping-law questions. Ask counsel to decide whether an exception applies and document which duties it changes.

Do not turn every ambiguity into a full impact assessment. That wastes time and obscures the uses most likely to affect people. An assessment should begin only after the team can name the deployed version, intended purpose, decision process, affected population, data categories, performance limits, oversight controls and discrimination risks being examined.

For a covered deployer, the enacted framework requires a risk management policy and program, impact assessments at specified intervals and after certain modifications, consumer notices, a public statement about deployed high-risk systems, and procedures connected to adverse consequential decisions. The exact obligation depends on the current law and the organization’s circumstances. Proposed rules, stakeholder recommendations and bills are not enforceable merely because they describe possible implementation details.

Buy tooling after the map survives review

Compliance software can maintain evidence links, route approvals, track assessment dates and preserve version history. It cannot reliably discover the warehouse ranking workflow from an identity-provider scan if recruiters upload files manually, if AI is embedded inside an applicant tracking product, or if the consequential cutoff lives in a business rule outside the model.

Run the first inventory with procurement records, security questionnaires, data-flow diagrams and interviews with the people who operate each decision. Test a sample workflow end to end. For the hiring ranker, submit or replay representative application records in an authorized test environment, inspect what the recruiter sees, and trace how the final disposition reaches the applicant record. Avoid using real applicant data unless existing controls and permissions allow it.

Only then write software requirements. A useful tool should preserve one-to-many relationships among models, vendors and workflows; distinguish proposed systems from deployed ones; retain evidence for each classification; and trigger review when a model, threshold, data source or user interface changes. If a product offers only a model registry and a generic risk score, it is not yet worth the money for this job.

The finished artifact is not a declaration that the company complies. It is a decision map with receipts. On the warehouse row, a reviewer can see why employment is implicated, how the score changes recruiter access, which entity supplied the system, which entity uses it and which unresolved questions require counsel.

Questions people ask

Does human review keep a system outside the Colorado AI Act?

Not by itself. The relevant factual question is whether the AI output makes or is a substantial factor in a consequential decision. Record what the reviewer can see, whether the reviewer can override the output, how often review occurs and whether people below a model-generated threshold ever reach that reviewer.

Should every generative AI tool go into the inventory?

Start with uses tied to business decisions, then retain a lighter record for tools that appear outside scope. A model drafting job descriptions differs from one ranking applicants, although the first use may need reassessment if its output later feeds screening or determines which candidates receive opportunities.

Can a vendor’s assurance replace an impact assessment?

No. Vendor documentation can supply evidence about design, intended use, data, testing and limitations, but the deployer must examine the system as configured in its own workflow. The same ranking model can have a different effect when one employer displays all applicants and another hides everyone below a cutoff.

Which inventory questions should go to counsel?

Ask counsel to resolve whether the organization and affected person fall within the statute, whether the workflow produces a consequential decision, whether the output is a substantial factor, which entity is a developer or deployer, and whether an exception or sector-specific law changes the duties. Keep the operational evidence attached to each question.