Map Colorado AI Act Decisions Before You Map the Software

Start with one rejected job applicant.

A Colorado employer uses a vendor’s recruiting platform to fill warehouse supervisor roles. The platform parses resumes, converts recorded interviews into text, scores candidates against configured criteria, and sends a ranked list to a recruiter. The recruiter usually reviews the first page of results. Everyone else receives an automated rejection email.

A software inventory might record one recruiting platform and mark its owner as Human Resources. That tells a governance team almost nothing about the decision: which score changed the applicant’s position, what personal data fed it, whether a recruiter could see lower-ranked candidates, who approved the rejection language, or how the applicant could challenge an incorrect transcript.

Colorado’s AI law makes that missing context material. The Colorado AI Act focuses on a “high-risk artificial intelligence system,” meaning an AI system that, when deployed, makes or is a “substantial factor in making a consequential decision.” Employment is among the covered decision areas. The statute defines a substantial factor around AI-generated output that can alter the outcome and is used as a basis for the decision.

The enacted framework assigns deployers duties including risk management, impact assessments, consumer disclosures, correction and appeal mechanisms, and reasonable care to protect consumers from known or reasonably foreseeable algorithmic discrimination. Its implementation schedule and related rulemaking have been subject to legislative activity, so teams should verify the operative date and current requirements rather than treating an old compliance calendar as settled. This worksheet supports readiness. It is not legal advice.

Give the decision its own record

Name the decision in language the affected person would recognize: “Reject applicant before recruiter interview,” not “use talent optimization module.” One workflow can contain several consequential decisions, and one platform can support decisions with different owners, data, and review paths.

Create one row per decision and record:

| Field | What to enter for the hiring screen | |---|---| | Decision | Reject an applicant before a recruiter interview | | Population | Colorado residents applying for warehouse supervisor roles | | Consequence | Loss of an employment opportunity | | Decision point | Ranked candidates outside the recruiter’s review range receive rejection emails | | AI contribution | Resume extraction, interview transcription, scoring, and ranking | | Human authority | Recruiter may advance a candidate but usually sees only the highest-ranked group | | Final action | Recruiting platform changes status and triggers email | | Business owner | Head of recruiting operations | | Technical owner | HR systems team | | Evidence owner | Named person responsible for logs, assessments, notices, and appeal records |

The “human authority” field needs more than a checkbox. A recruiter does not supply meaningful review merely by having permission to override a score. Record what information appears on screen, whether the recruiter sees the source resume and transcript, whether lower-ranked applicants remain accessible, and whether production metrics discourage review.

This is the first gap test. If nobody can explain the exact event that turns a ranking into a rejection, the organization cannot reliably connect its notices, impact assessment, or appeal process to the relevant decision.

Trace the decision backward through every component

Return to the rejected applicant and work backward from the status change. The rejection email came from a workflow rule. That rule depended on rank. Rank depended on a composite score.

The score may have used extracted employment history, answers from an assessment, and a transcript produced by a separate speech-to-text model.

Each component belongs in the decision record even if the employer never bought something labeled AI. An application programming interface, or API, lets one software service request output from another; vendors often call external models through APIs without exposing those model names in the customer’s administrator panel.

For every component, capture its function, input, output, and effect on the decision. Also record whether it is supplied by the deployer, the primary vendor, or a subcontractor. A useful dependency row looks like this:

| Component | Input and output | Effect | Evidence to request | |---|---|---|---| | Resume parser | Resume file to structured job history | Missing or incorrect fields lower the score | Field mapping, confidence handling, error logs | | Interview transcription | Audio to text | Transcript becomes scoring input | Language support, retention terms, correction path | | Candidate scorer | Structured fields and transcript to score | Score sets ordering | Feature list, configuration, validation material | | Workflow rule | Rank and recruiter settings to status change | Triggers rejection | Rule configuration, change history, event log |

Do not stop when a vendor says its product only “assists” a recruiter. The operational issue is whether the output can alter the outcome and is used as a basis for it. In this hiring screen, limiting routine review to the first page can make ranking decisive for everyone outside that view, even though a human advances the finalists.

The vendor may refuse to disclose model weights or source code. Those are not the only useful receipts. Ask for input categories, output definitions, known limitations, customer-configurable thresholds, testing relevant to the use case, version-change notices, logging fields, retention periods, and subcontractor responsibilities. If the vendor cannot provide enough information to assess the deployment, mark that as an evidence gap rather than copying its marketing description into the inventory.

Map data at the point where it changes the outcome

A generic entry such as “candidate data” will not support correction or investigation. Tie each data element to the component that consumes it and the output it can influence.

For the warehouse applicant, the inventory could show that the parser extracts dates and job titles from a resume, the transcription service converts spoken answers into text, and the scorer compares those fields with employer-selected criteria. Record the source of each field, whether the applicant supplied it directly, how inferred fields are labeled, and where corrections propagate.

Propagation matters. Correcting a transcript in a customer-service ticket does not repair the decision if the old score remains in the recruiting database. The worksheet should identify the action that forces rescoring, the person authorized to initiate it, and the record proving that the corrected input reached the new decision.

Data mapping carries operational costs. More detailed event logs consume storage and may preserve sensitive material longer than necessary, while sparse logs reduce privacy exposure but can leave the employer unable to reconstruct an adverse result. Set retention by evidence need and applicable obligations, restrict access, and document the tradeoff. Keeping every recorded interview indefinitely is not a defensible substitute for designing useful logs.

Attach the statutory-facing controls

Colorado’s framework requires more than an internal risk register. Before using a high-risk system to make a consequential decision, a deployer must provide the consumer specified notice about the deployment, its purpose and nature, contact information, and access to the deployer’s public statement. After an adverse consequential decision, the law calls for disclosure that includes the principal reason or reasons, the degree and manner in which the system contributed, and information about the data involved.

The same decision row should therefore link to the exact notice template and trigger. For the hiring screen, inspect the applicant experience rather than the policy folder. Find where the pre-decision notice appears, confirm that it covers the transcription and ranking functions, then submit a test application and preserve the resulting rejection message.

A generic sentence saying that technology may assist hiring does not document what the system does. Nor can a useful adverse-decision explanation merely repeat “qualifications did not match.” The evidence map should let the employer identify the principal factors that drove the outcome without exposing another applicant’s information or inventing certainty the model did not produce.

Colorado also contemplates an opportunity to correct incorrect personal data and appeal an adverse decision, with human review where technically feasible. Add these worksheet fields: intake channel, identity verification, correction location, rescoring step, reviewer role, reviewer evidence, response record, and escalation owner. Four of those fields are often split across the vendor, recruiting, privacy, and legal teams. Give one team authority to coordinate them.

Human review adds delay and labor. That cost is real, particularly in high-volume hiring, but an appeal button that opens a ticket nobody can use to change the outcome is only interface decoration. The reviewer needs access to the original inputs, model output, decision rule, corrected information, and authority to reverse the rejection.

Turn blank cells into a remediation queue

Once the warehouse hiring row is complete, score evidence rather than confidence. Use four states: documented and tested; documented but untested; asserted by a vendor; missing. A contract promise belongs in the third state until the employer can connect it to logs, configuration, or a test result.

Prioritize gaps that block several duties at once. If the employer cannot retrieve the transcript version used for scoring, it may struggle to explain the rejection, correct the input, run an effective appeal, or investigate discriminatory outcomes. Fixing that evidence path has more value than polishing the public AI statement first.

Assign every gap an owner, dependency, target period, and closure artifact. The closure artifact might be a revised contract exhibit, a screenshot from a test application, an exported decision log, or an approved appeal procedure. “Vendor reviewing” is a status, not evidence.

Then repeat the method for each consequential decision, including promotion recommendations, credit eligibility, housing screening, insurance decisions, healthcare access, education opportunities, and covered government services where relevant. Do not import the hiring assumptions. A model that only routes documents in one workflow may influence eligibility in another.

The resulting inventory is smaller than a catalog of every algorithm in the company, but more demanding. It shows where a person encountered a consequential decision, which systems shaped it, what evidence survives, and who can repair the result.

Questions people ask

Does every

AI feature belong in the Colorado AI Act inventory?

No. Start with systems that make or substantially influence covered consequential decisions, then document why adjacent components are included or excluded. A scheduling feature may fall outside the decision path, while a resume parser belongs in it if extracted fields feed the score used to reject applicants.

Can a vendor’s compliance document replace our impact assessment?

A vendor document can supply evidence about a model, its testing, and known limits, but the deployer must assess the actual use. Your configuration, applicant population, decision rule, human review practice, data sources, and appeal path can create risks that the vendor’s general assessment does not cover.

Is a recruiter’s override button enough to count as human review?

Not by itself. Record whether the reviewer can inspect the relevant inputs and output, understand why the result occurred, consider corrected information, and reverse the decision. If the interface hides lower-ranked applicants or the reviewer lacks authority, the button does not establish a functioning review process.

What should we do when a vendor will not identify its model?

Document the refusal and request operational evidence that does not require source-code access, including input categories, output meaning, limitations, version notices, logs, testing, retention, and subcontractor roles. If those materials still cannot support explanation, correction, assessment, and appeal, treat the missing evidence as a deployment risk.