Colorado Makes Businesses Own Their High-Risk AI Records

Take a résumé-ranking system used to fill a Colorado job. It parses applications, assigns scores and sends candidates above a threshold to a recruiter; those below it receive a rejection unless someone intervenes. The software vendor built the model, but the employer chose the job, threshold, data fields, recruiter instructions and fallback.

Under Colorado’s Artificial Intelligence Act, that employer is the deployer. The law covers a deployer that uses a high-risk AI system “to make, or be a substantial factor in making, a consequential decision.” Employment is one covered area, alongside fields including education, lending, housing, insurance, health care, legal services and essential government services.

The operational change is ownership. A vendor can supply model documentation and testing results, but the employer must connect that evidence to its own hiring workflow, assess discrimination risks, notify candidates, support challenges and retain records. Buying a compliance folder with the software will not answer why this candidate was rejected under this configuration.

Colorado enacted these requirements, then postponed their operative date to June 2026. They are statutory obligations, not merely recommendations, although attorney general rulemaking and guidance may refine how businesses demonstrate compliance. The following is an implementation workflow, not legal advice.

Start with the decision, not the product label

Create one internal decision packet for the résumé-ranking workflow. That name is not required by the statute; it is a practical container for the records the law does require and the evidence needed to maintain them.

First, describe the decision in operational terms. Record where an application enters, which fields the system reads, what it outputs, how the threshold works, who can override it and what happens if the service is unavailable. A generic statement that the company uses AI to assist recruiters is too loose to test and too vague to support a candidate notice.

Next, decide whether the system is high-risk in this use. Colorado’s definition turns on whether AI makes, or substantially influences, a consequential decision. A spell-checker in the recruiter’s email is not equivalent to a ranking model whose score determines which applications receive review. Calling the model “decision support” does not settle the issue if recruiters routinely follow its recommendation.

Capture evidence of real use rather than relying only on the intended workflow. Logs should show the model version, input categories, score, threshold, resulting action, human override and timestamps needed to reconstruct the decision. If the employer cannot connect a rejection to the system state that produced it, later review becomes guesswork.

Return to the packet whenever the workflow changes. Adding interview transcripts as an input, moving the rejection threshold or allowing the model to recommend compensation may alter both the risk and the required explanation, even if the vendor keeps the same product name.

Write the impact assessment around the local configuration

Colorado requires a deployer to complete an impact assessment at least annually and within 90 days after an intentional and substantial modification. The assessment must address the system’s purpose and context, reasonably foreseeable risks of algorithmic discrimination, the data and outputs involved, performance limitations, safeguards, monitoring and transparency measures.

Algorithmic discrimination, in this context, concerns unlawful differential treatment or impact based on a protected classification. For the hiring system, the employer should test more than aggregate accuracy. It needs to examine whether screening outcomes differ across relevant groups, whether missing or proxy data changes those outcomes, and whether the recruiter’s use of the score amplifies a disparity that the vendor’s laboratory evaluation did not cover.

The assessment should name controls that someone can operate. One control might route low-confidence applications to manual review. Another might disable a field that behaves as a proxy for a protected characteristic. Monitoring could compare selection rates over time and trigger investigation when a defined threshold is crossed, while the fallback sends all applications to recruiters if the model or its logs fail.

There is a tradeoff. More human review costs staff time and slows hiring, while a broad override right can make outcomes less consistent if recruiters receive no guidance. A deployer should document the choice it made, the evidence supporting it and the residual risk rather than describing human involvement as an automatic safeguard.

The law requires the deployer to keep the most recent assessment and records concerning completed assessments for at least three years after the system’s final deployment. Version the decision packet accordingly. Overwriting last year’s assessment with this year’s text destroys the record of which controls applied to earlier candidates.

Put notices and appeals inside the product flow

Before the high-risk system makes or substantially contributes to a consequential decision, the deployer must tell the consumer that it is being used, explain its purpose and identify the nature of the decision. For the résumé workflow, place that notice where the candidate submits the application, not in a general privacy policy that requires unrelated navigation.

The notice should match the mechanics. If the model ranks candidates and the ranking determines who receives recruiter review, say so. Do not claim that a human makes every decision when the operating rule automatically rejects applications below a score unless an exception fires.

An adverse decision creates a second documentation task. The deployer must provide the principal reason or reasons, including the degree and manner in which the AI contributed, along with the types and sources of data used. It must also offer an opportunity to correct incorrect personal data and an appeal that allows human review where technically feasible.

That means the rejection service needs access to the decision packet. A static message such as “other candidates were more qualified” cannot explain whether the model discounted an employment gap, failed to parse a credential or ranked the application below a configured threshold. The appeal queue also needs authority to change the result; sending a complaint back through the same model is not meaningful human review.

Test the route before launch. Submit an application with an intentionally incorrect credential, generate an adverse result, request correction and verify that a reviewer can see the original data, the corrected record, the model output and the rule that produced the rejection. If any link is missing, the notice is ahead of the system that must honor it.

Treat vendor material as evidence, not delegation

Colorado places separate duties on developers, which are the organizations that build or intentionally and substantially modify covered systems. A developer is expected to provide deployers with documentation about intended uses, known limitations, data governance, performance evaluation, foreseeable misuse and measures taken to reduce discrimination risk. It must provide information reasonably necessary for the deployer’s impact assessment.

Ask for that material during procurement, before the résumé tool touches live applications. The contract should preserve access when the model changes and should define how the vendor reports substantial modifications, newly discovered limitations and incidents that affect the employer’s assessment. A marketing summary or security certification does not substitute for system-specific evidence.

Verification remains local. Confirm that the vendor evaluated the same use, comparable input data and the output the employer relies on. If the vendor tested candidate recommendations but the employer converts scores into automatic rejections, its evidence covers a different workflow. If the vendor cannot reveal training data in detail, the employer still needs enough information about data sources, limitations and evaluation methods to judge whether deployment is supportable.

Some gaps should stop deployment. When a vendor cannot identify the active model version, preserve decision-level logs or explain the factors available for adverse-decision notices, the employer cannot repair those omissions with policy language. The alternative is a narrower use, such as allowing the tool to organize applications without determining who receives review, or returning to manual screening.

Build the control loop before the first rejection

The statute creates a duty of reasonable care to protect consumers from known or reasonably foreseeable risks of algorithmic discrimination. Compliance with specified risk-management, assessment, notice and reporting practices can support a rebuttable presumption of reasonable care, which means evidence can still challenge it; this is not an unconditional safe harbor.

Connect the decision packet to an owner and an operating calendar. The hiring team should know who reviews monitoring results, who pauses the model, who handles appeals and who decides whether a vendor update counts as an intentional and substantial modification. The risk-management program should align with a recognized framework, such as the National Institute of Standards and Technology’s AI Risk Management Framework, while remaining specific to the deployed system.

A deployer that discovers algorithmic discrimination must report it to the Colorado attorney general within 90 days. That clock makes escalation design material. An analyst who sees a disparity needs a route to compliance staff, access to the underlying records and a defined standard for investigation; otherwise the company may spend most of the reporting window deciding who owns the finding.

Colorado assigns enforcement to the attorney general under the state’s consumer-protection framework and does not create a private right of action under this act. The attorney general’s future rules may add detail, but proposed language is not the same as a final enforceable rule. Track rulemaking separately from the enacted checklist, then update the résumé system’s decision packet when a final requirement changes the workflow.

Questions people ask

Does every AI hiring tool count as high-risk?

No. Coverage depends on what the system does in the deployed workflow, not whether the vendor markets it as AI. A tool that ranks, rejects or materially steers candidate selection is more likely to qualify than software used only for scheduling or proofreading, although the statutory definitions and exclusions require case-specific review.

Can the vendor complete the impact assessment for the employer?

A vendor can supply technical evidence, evaluation results and draft material, but the deployer owns the assessment of its use. The employer must account for its threshold, candidate population, recruiter behavior, notices, overrides and monitoring because those facts are outside a developer’s general model documentation.

Is having a human recruiter in the loop enough?

No. Human review matters only if the reviewer receives useful information, has time and authority to disagree, and does not merely confirm the model’s output. The deployer should log overrides and test whether the review path catches parsing errors, unsupported scores and incorrect personal data.

What should a business request from an AI vendor now?

Request the intended-use documentation, active model and change history, evaluation methods, known limitations, relevant data information, discrimination-risk controls and decision-level logging support. For the résumé workflow, verify that these materials cover the employer’s rejection rule and can support a candidate explanation before signing or renewing the contract.