Colorado’s AI Act Turns Impact Assessments Into Operations

Take a résumé-ranking system used to recommend which Colorado applicants receive interviews. The model reads application materials, converts selected information into scores, and gives recruiters a ranked queue. If that output is a substantial factor in an employment decision, the deployment may fall within the act’s high-risk AI framework.

The useful object here is not a broad “responsible AI” policy. It is the change ticket for that hiring screener: the record connecting a deployed version to its intended use, input data, performance evidence, discrimination analysis, approval, applicant notice, and route to human review.

Colorado enacted the framework in 2024 and later postponed implementation until late June 2026. The law directs deployers, meaning organizations that use covered systems, to exercise reasonable care against known or reasonably foreseeable risks of algorithmic discrimination. It also creates a rebuttable presumption of reasonable care for organizations that follow specified governance measures. That is an evidentiary benefit, not immunity.

The Colorado attorney general has enforcement authority; the act does not create a private right of action. It also authorizes rulemaking, so organizations should distinguish enacted requirements from interpretations or procedures that remain subject to change. This walkthrough uses the statutory framework as an operating specification, not as legal advice.

Start with the consequential decision

Do not begin by cataloging every model the company can access. Begin with the decision.

For the hiring screener, document where the recommendation enters the workflow and who can alter it. A recruiter might receive a ranked queue, open only the first group of applications, and advance candidates manually. A nominally advisory score can still matter if the interface and operating targets make lower-ranked applications unlikely to receive review.

That dependency is more important than a vendor’s product label. Colorado’s framework covers an AI system when it makes, or is a substantial factor in making, a consequential decision in areas that include employment, lending, housing, education, health care, insurance, and essential government services. A substantial factor generally means the system assists in making a decision and can alter its outcome.

The assessment record should therefore identify the decision owner, model owner, affected Colorado population, output shown to the operator, and fallback when the system is unavailable. It should also state what the model does not decide. If recruiters must independently read every application before rejecting anyone, preserve evidence that this control happens rather than relying on a written instruction that the product interface quietly defeats.

Scope errors propagate. If the organization records the tool as generic productivity software, later teams may omit applicant notices, discrimination testing, and appeal handling because no workflow owner realizes a consequential decision is involved.

Make one assessment record the control point

Colorado requires an impact assessment at least annually and “within ninety days after any intentional and substantial modification” to a high-risk AI system. That language turns the assessment into a recurring operating process.

Give the hiring screener a controlled assessment record tied to the production configuration. It should name the system and vendor, describe the intended use and deployment context, identify the categories of data entering and leaving the system, and link to the performance measures used to judge it. If the employer customizes the model with its own hiring data, the record should identify those data categories and the customization method.

The record also needs the risk decision. For this workflow, reviewers should examine whether the model creates a known or reasonably foreseeable risk of unlawful differential treatment or impact, what mitigations reduce that risk, and why the expected benefits justify the residual exposure. A statement that a vendor tested for bias is not enough if the employer uses different job families, thresholds, applicant data, or recruiter instructions.

Keep the supporting evidence with the decision: vendor documentation, test definitions, approval comments, notice text, monitoring results, incident tickets, and prior assessments. The act requires retention of the latest assessment and records concerning assessments for at least three years after final deployment. A dashboard can help people find these artifacts, but an attractive governance interface does not replace the underlying records.

Put changes through the same gate

Return to the change ticket. Suppose the employer adds interview-transcript analysis, changes the score threshold, starts using a new applicant pool, or accepts a vendor update that changes outputs. The release process needs a named person who decides whether the change is intentional and substantial, records the reasoning, and triggers the statutory assessment window when required.

That gate has a cost. Product and recruiting teams may need to hold a release while governance staff collect test results, compare outcomes, revise notices, and confirm that appeal staff can interpret the new output. Small updates may still require triage even when they do not trigger a fresh statutory assessment, because the organization needs a defensible record of why it classified the change that way.

Version labels alone will not do this. The employer should preserve the deployed model or service version where available, feature configuration, decision threshold, prompt or instruction changes, data-schema changes, rollout population, and approval time. Closed vendor systems can make some of that information inaccessible. The practical response is contractual: require change notices and enough documentation to evaluate foreseeable risks, known limitations, performance, and intended uses before an update reaches production.

A vendor assessment can supply evidence, and the act allows a deployer’s assessment to incorporate a developer’s assessment. The employer still owns its deployment context. The developer cannot see whether recruiters override recommendations, whether the company uses the tool for jobs outside the tested population, or whether an appeal reaches someone authorized to reverse a rejection.

Connect the assessment to applicant-facing steps

The consumer-facing workflow should come from the same system record, not from a separate privacy notice that nobody updates after launch.

Before a covered consequential decision, a deployer must tell the consumer that a high-risk AI system is being used, explain its purpose and the nature of the decision, provide contact information, and supply a plain-language description of the system. For the hiring screener, the notice should match what applicants experience. Calling the tool “application support” would obscure its role if its ranking affects who receives an interview.

An adverse decision creates another set of duties. The organization must provide the principal reason or reasons, explain the degree and manner in which the system contributed, and disclose the types and sources of data processed in making the decision. It must also offer a way to correct inaccurate personal data and appeal the decision, with human review when technically feasible.

Build that response from retained decision data. A generic message that another applicant was more qualified may not explain why this applicant was screened out or how the model contributed. Yet a generated explanation can also mislead if it reconstructs a plausible reason rather than reporting the features and rules that affected the stored result.

For each decision, retain enough information to reproduce the path: the system configuration, relevant inputs, output, threshold, operator action, notice version, and any override. This increases storage and operational work, particularly when vendors return only a score. It is still cheaper than discovering during an appeal that the organization cannot tell which model configuration evaluated the applicant.

Monitor the workflow, not just model accuracy

Colorado’s framework expects post-deployment monitoring and user safeguards, including human oversight. A model can retain acceptable aggregate accuracy while the surrounding workflow fails.

The hiring assessment should track whether recruiters follow required review steps, whether overrides cluster by job or location, whether applicants can reach the correction and appeal channels, and whether human reviewers receive enough context to make an independent judgment. Teams should also revisit outcome testing when the applicant population or job criteria change, because validation performed on an earlier population may no longer describe production use.

Monitoring needs escalation thresholds decided in advance. If an analysis identifies a possible discrimination risk, the owner should know whether to pause automated ranking, widen manual review, restore an earlier configuration, or stop using the system. The fallback has a real labor cost: recruiters may need to review more applications, decisions may take longer, and consistency may decline. An unusable fallback is not a control.

The act also requires deployers to notify the attorney general after discovering that a high-risk system caused algorithmic discrimination, subject to the statute’s timing and cure provisions. That makes incident classification part of the operating design. Legal, compliance, technical, and decision owners need a shared route for preserving evidence and deciding whether observed harm meets the statutory standard.

Test the record with one rejected application

Before launch, select a test application and walk it through the full production path. Confirm that the employer can identify the deployed configuration, show the input categories used, recover the resulting score or recommendation, state who acted on it, issue the correct notice, accept a correction, and route an appeal to a person capable of changing the result.

Then open the hiring screener’s change ticket. It should point to every artifact needed for that reconstruction and show who approved the residual risk. If the evidence sits in vendor emails, an unversioned policy document, and a dashboard that overwrites yesterday’s results, the assessment is not repeatable yet.

Questions people ask

Does every workplace

AI tool require a Colorado impact assessment?

No. The central issue is whether the system makes or is a substantial factor in a covered consequential decision, such as an employment decision. A writing assistant may fall outside that definition, while a ranking tool that materially affects interview selection may fall within it. Organizations still need to document their scope determination.

Can a vendor’s impact assessment cover the employer?

A deployer may incorporate a developer’s assessment, but vendor material cannot resolve deployment-specific facts. The employer must account for its applicant population, thresholds, recruiter behavior, custom data, notices, monitoring, and appeal process. Contracts should require documentation and advance information about changes that could affect those conclusions.

How often must the assessment be updated?

The enacted framework calls for an assessment at least annually and within ninety days after an intentional and substantial modification. Teams also need a change-review gate between those assessments so they can classify updates, preserve the reasoning, and avoid discovering months later that a model or workflow changed without review.

What should a human appeal reviewer receive?

The reviewer needs the original inputs relevant to the decision, the system output, its contribution to the result, the applicable criteria, and any corrected information from the applicant. Human review adds little if the reviewer merely accepts the same score without authority, time, or evidence to reach a different decision.