Filter by Category

How to Comply With Colorado’s AI Act (SB 24-205) for High-Risk HR and Lending Algorithms Explained

Colorado’s AI Act (SB 24-205) takes effect on February 1, 2026, and it imposes compliance duties on businesses that develop or deploy “high-risk” AI in employment and lending. For Colorado employers, lenders, fintechs, and HR vendors, the law targets algorithmic discrimination and requires governance, notices, and risk management. This article explains who is covered, what “high-risk” means in HR and credit, and a practical compliance checklist.

Colorado has enacted one of the nation’s first broad, cross-industry AI governance statutes focused on preventing algorithmic discrimination. Senate Bill 24-205—commonly referred to as Colorado’s AI Act—creates affirmative obligations for businesses that either (1) develop artificial intelligence systems offered for use in Colorado or (2) deploy AI systems to make, or substantially assist with, certain consequential decisions about Colorado residents.

For legal and compliance teams, the practical question is whether your HR tools (screening, ranking, interviewing, performance scoring) or lending/credit tools (underwriting, pricing, line management, collections prioritization) qualify as “high-risk” and, if so, what concrete steps must be in place before February 1, 2026.

1) What Colorado’s AI Act regulates: “High-risk” AI and consequential decisions

SB 24-205 is built around two concepts: (a) “high-risk” AI systems and (b) “consequential decisions.” The law is aimed at preventing “algorithmic discrimination,” generally meaning unlawful differential treatment or impact based on protected characteristics when AI meaningfully influences a decision.

Consequential decisions: why HR and lending are in the crosshairs

Although the statute’s definitions are detailed, the core idea is straightforward: if an AI system is used to help make a decision that has a major legal or practical effect on a consumer—such as getting a job or credit—additional guardrails apply.

HR examples (employment):

AI-assisted resume screening that ranks applicants and determines who advances.
Automated interview scoring tools that recommend “hire/no hire.”
Internal mobility tools that score employees for promotions or layoffs.
Performance analytics used to decide compensation adjustments or termination.

Lending examples (credit and related services):

Underwriting models that approve/deny applications.
Pricing models that set interest rates, credit limits, or fees.
Line management models that reduce limits or trigger account closure.
Collections prioritization models determining which accounts receive aggressive actions first.

In practice, many organizations will discover that an AI system becomes “high-risk” not because it is sophisticated, but because of where it is used and how much it influences the final decision.

2) Who has duties under SB 24-205: Developers vs. Deployers

The Colorado AI Act distinguishes between:

Developers: entities that develop or substantially modify an AI system and make it available for use in Colorado.
Deployers: entities that use a high-risk AI system in Colorado to make, or be a substantial factor in making, consequential decisions.

This distinction matters for contracting and compliance architecture. For example, a SaaS HR platform provider may be a developer, while the employer using the tool is a deployer. In lending, a fintech vendor providing a credit decision engine may be a developer; the bank or lender using the system is typically the deployer (even if it relies heavily on vendor settings).

Key compliance reality: You may be both. A lender that fine-tunes a vendor model, adds proprietary features, or materially changes model behavior may step into “developer” obligations, while still being the “deployer” for decisions affecting Colorado borrowers.

3) Core compliance duties for deployers using high-risk AI in HR or lending

Deployers face the most operational requirements because they are closest to the decision and the affected consumer. While implementation details will depend on the system and use case, the deployer’s playbook should generally include governance, risk management, transparency, and response processes.

A. Implement a risk management program designed to prevent algorithmic discrimination

Deployers should treat SB 24-205 as requiring an AI-specific risk management layer that sits alongside existing compliance programs (e.g., EEO/OFCCP processes for employers; ECOA/Reg B, FHA, FCRA, and UDAAP programs for lenders). At a minimum, this typically involves:

Inventorying AI uses in HR and credit, including “shadow AI” (tools used by recruiters or loan officers outside formal procurement).
Identifying whether the system is high-risk and documenting the basis for the determination.
Testing and monitoring for discriminatory outcomes and drift over time.
Documenting controls, model limitations, and required human oversight.

HR-specific example: If an AI resume screener disproportionately screens out older applicants, the deployer should be able to show documented monitoring, bias mitigation steps (feature review, threshold changes, alternative scoring), and a governance decision approving continued use.

Lending-specific example: If a credit model’s decline rates or pricing decisions correlate with protected classes (even indirectly), the deployer should have a testing methodology consistent with fair lending expectations, and a documented path for remediation (feature removal, policy constraints, second-look reviews, or score band adjustments).

B. Provide required notices and meaningful information

SB 24-205 emphasizes transparency when high-risk AI is used in consequential decisions. Practically, this means deployers should be prepared to:

Inform individuals that a high-risk AI system is being used in connection with a consequential decision.
Provide information about the system’s purpose and the nature of its role in the decision.
Offer a method to contest or seek review in appropriate circumstances, including human review where required or promised.

Interplay with existing law: For lenders, SB 24-205 transparency obligations will often run parallel to FCRA adverse action notices and ECOA/Reg B requirements (including reason statements). For employers, it may overlap with background screening notices and state privacy or biometric rules, depending on the tools used.

C. Ensure appropriate human oversight (not rubber-stamping)

Where an AI system substantially influences an HR or lending outcome, deployers should define what “human oversight” means in policy and practice. Regulators typically look for:

Clear authority for a human decision-maker to override the model.
Training so reviewers understand model limitations and common failure modes.
Controls preventing overreliance (e.g., requiring documented rationale when accepting model outputs in edge cases).

Practical HR example: If an interview-scoring tool flags candidates as “not recommended,” recruiters should have guidance on when to review underlying factors, when to escalate, and how to avoid discriminatory proxy criteria (speech patterns, accent, disability-related cues).

Practical lending example: For borderline declines or high-cost pricing decisions, a second-look process can reduce risk—if it is structured, measurable, and not merely discretionary in a way that creates new discrimination risk.

D. Maintain documentation and vendor management controls

Even if SB 24-205 does not prescribe a single “model file” format, deployers should expect that documentation will be central to demonstrating compliance. Recommended components include:

System description and intended use, including what data inputs are used and excluded.
Governance approvals, risk assessments, test results, and mitigation steps.
Change management records for retraining, feature updates, thresholds, or vendor version changes.
Incident logs (complaints, anomalies, suspected discrimination events) and resolutions.

Vendor contracts should also be updated to require cooperation, including access to necessary technical and compliance artifacts, audit support, and allocation of responsibilities when the vendor is a “developer” and you are the “deployer.”

4) Developer obligations: what HR tech and credit model vendors must do

Developers—such as HR software providers, assessment vendors, and credit decisioning platforms—should prepare for obligations that support deployers’ compliance and reduce downstream harm. Common obligations include:

Providing information and instructions for safe, compliant deployment (intended purpose, known limitations, appropriate data use, and required human oversight).
Designing to reduce algorithmic discrimination through testing, validation, and bias mitigation practices.
Enabling transparency so deployers can generate notices and meaningful explanations consistent with the system’s function.

From a commercialization standpoint, SB 24-205 will likely become a procurement gate: enterprise customers will demand “Colorado-ready” documentation, audit rights, and clarity on whether the tool is high-risk in particular configurations.

5) A step-by-step compliance checklist for HR and lending organizations

Step 1: Build an AI inventory and classify use cases

List all AI and algorithmic tools touching hiring, employment, and credit workflows. Include third-party tools and internally built models, plus “embedded AI” in ATS/CRM products. For each system, document: use case, decision point, data inputs, vendor, and whether the output is advisory or determinative.

Step 2: Determine whether each use is “high-risk” and document the rationale

Classification should be written and repeatable. If a system influences hiring, termination, promotion, compensation, or credit approval/pricing, assume it may be high-risk until counsel confirms otherwise.