SR 26-2 vs Colorado AI Act (SB 26-189): Model Risk vs Consumer Protection for AI Lenders

What changed on the Colorado side

Many comparisons still treat SB 24-205 as the operative Colorado law. That is out of date. The Colorado Attorney General describes SB 24-205 as creating consumer protections from algorithmic discrimination in consequential decisions made by high-risk AI systems. In May 2026, SB 26-189, titled Automated Decision-Making Technology, was signed into law. It repeals and reenacts the SB 24-205 provisions with new requirements for automated decision-making technology in consequential decisions.

For a lender, the practical consequence is that the Colorado workstream should be built on the reenacted statute. Dates tied to the original act, including the February 1, 2026 reference for the developer reasonable-care duty, are no longer the reference point. Features of the original act remain useful as background. Financial or lending services was a listed consequential-decision area. Duties were divided between developers and deployers. A deployer that learned its system had caused algorithmic discrimination had to notify the Attorney General within 90 days of discovery. A violation was a deceptive trade practice under the Colorado Consumer Protection Act. This article uses those points as context for how the Colorado frame is built, not as a statement of current operative terms.

SR 26-2, Revised Guidance on Model Risk Management, was issued on April 17, 2026, so both frameworks changed within the same few weeks.

SR 26-2 and the Colorado AI Act side by side

The table is organized by obligation dimension rather than by regulator. Colorado entries describe the Attorney General's characterization of the reenacted law and, where marked, the original act.

• Nature and authority: SR 26-2: a Federal Reserve supervisory letter with attached guidance. Colorado: a state statute, SB 26-189, which repeals and reenacts SB 24-205.
• Status and timing: SR 26-2: issued April 17, 2026. Colorado: signed May 2026, replacing the original act as the reference point.
• Regulated party: SR 26-2: each banking organization, which is ultimately responsible for practices suited to its own risks. Colorado: original act divided duties between developers and deployers; a lender using a vendor model may hold the deployer role.
• Trigger and scope: SR 26-2: use of models, with practices varying by risk profile and model usage. Colorado: use of automated decision-making technology in consequential decisions, with lending listed in the original act.
• Harm addressed: SR 26-2: model risk, including financial loss, errors in financial statements and reporting, and flawed financial and risk management decisions. Colorado: algorithmic discrimination affecting consumers.
• Enforcement posture: SR 26-2: supervisory examination of the institution. Colorado (original act): Attorney General disclosure channels and deceptive trade practice treatment.

Where one control or evidence set can serve both

The frameworks ask different questions, but both end up asking the institution to show what its AI system did and who oversaw it. A supervisor evaluating model risk wants to see that the model operates within its approved use and that exceptions are noticed and handled. A consumer protection regulator wants to see that decisions affecting consumers were made under controlled, reviewable conditions.

That overlap suggests a few evidence types a single design can serve: records of each AI interaction and the policy applied to it, records of when a human reviewed or approved an action, and monitoring records that show how often policies triggered. This is design reasoning, not a statement that either framework prescribes these artifacts. SR 26-2 is principles-based and leaves the form of evidence to each institution, so a lender can choose a format that also answers Colorado questions.

The practical decision is to define evidence once, at the level of the individual interaction, and let the model risk, compliance and legal teams each query it for their own purposes. Separate evidence stores for each framework tend to drift apart and produce inconsistent answers to an examiner and a state regulator.

Where each framework demands something distinct

SR 26-2 is institution-centered. It describes model risk as arising from the use of models and treats the banking organization as ultimately responsible for tailoring its practices. Because expectations scale with risk profile and model usage, two lenders can satisfy the same guidance with different programs. Examination happens through the supervisory process, which has historically focused on validation, governance and ongoing monitoring.

The Colorado frame is outcome-centered. Its concern is whether consumers face algorithmic discrimination in consequential decisions, and it assigns duties by role. That has two consequences. First, a model can pass a sound model risk review and still raise a consumer protection question, because the measure is the effect on consumers rather than the soundness of the model. Second, the developer and deployer split means a lender that buys a model has to understand which duties stay with it, and cannot assume the vendor's validation covers them.

The original act also included a provision under which a bank, credit union or affiliate subject to prudential examination was treated as in full compliance if applicable published guidance met criteria set in the act. It shows that Colorado's own text considered prudential guidance relevant, so the two frameworks are neither one workstream nor wholly separate. Risk leaders should have legal counsel confirm how any such provision operates under the reenacted statute before relying on it.

What runtime control can and cannot support

Controls that act while the AI is running operate on individual interactions and tool calls. They can allow an action, redact sensitive data, block a request, or escalate it for human approval, and they can record each decision. These controls support monitoring, human review and decision records, which fall in the overlap described above.

Several obligations cannot be met in the execution path. Model validation is an independent assessment of design, data and performance. Impact assessments are structured analyses of how a system affects consumers. Consumer notices and explanations of adverse decisions are communications that business and compliance teams design and issue. Runtime enforcement does not replace these. It also cannot show that a model is free of discriminatory effect. It shows what the system was permitted to do and what it did.

A useful ownership split is as follows. Model risk owns validation and the monitoring framework. Compliance and legal own the Colorado interpretation, assessments and consumer-facing communications. Security and platform teams own the runtime policy layer and the retention of its evidence. Keeping a written inventory of duties that sit outside runtime control prevents teams from assuming enforcement logs cover them.

Where runtime policy enforcement fits

Trussed enforces policy in the execution path across models, agents, tools and MCP servers. Policies can allow, redact, block, rate limit or escalate an action for human approval, and the scope is individual interactions and tool calls. Enforcement generates continuous, audit-ready evidence, mapped to frameworks including NIST, and it is enforced at runtime, not reviewed after the fact. Deployment is self-managed in the customer cloud, with configurable retention and data residency.

For an AI lender, the relevance is narrow and specific. When an examiner or regulator asks what a system was allowed to do and what it did on a given interaction, the evidence comes from the enforcement point itself and not from reconstruction. Trussed does not perform validation, impact assessment or consumer notice, and it does not provide model lineage or dataset provenance. It is one layer that supports the shared evidence set, alongside the model risk and compliance processes that own the rest.