Colorado SB 26-189: What AI Platform Teams at Lenders and Banks Need to Enforce and Evidence

What the statute says, and what it leaves to interpretation

The bill page describes SB 26-189, titled Automated Decision-Making Technology, as an act that repeals and reenacts earlier provisions with new requirements for the use of ADMT in consequential decisions. It assigns duties to both developers and deployers. A bank or lender that runs AI in lending or other consequential decisions will most likely be asked, first, which role it occupies.

The deployer duty that is stated concretely is the explanation requirement. When a covered ADMT makes a consequential decision with an adverse outcome for a consumer, the deployer must give that consumer a plain-language description of the ADMT's role within 30 days.

The attorney general enforces the act through the Colorado Consumer Protection Act, and a violation is deemed a deceptive trade practice. For actions initiated before January 1, 2030, the attorney general must first give the developer or deployer 60 days' notice and an opportunity to cure, if a cure is deemed possible.

Terms such as covered ADMT, consequential decision, adverse outcome and the ADMT's role are legal questions. The platform team should not settle them alone. What the team can do is make sure that, once counsel decides, the platform can answer them from facts rather than reconstruction.

Where platform responsibility starts and stops

A 30-day explanation window implies that someone can retrieve, for a specific decision, whether and how an ADMT participated and what the outcome was. That is a platform capability. It requires a stable identifier per consequential decision and a record linking the model invocation, tool calls and data sources used in that interaction to the outcome. The statute summary does not prescribe a record format, so the format is an engineering choice.

The platform team can also maintain an inventory of AI systems that take part in consequential decisions. Counsel needs that inventory to decide which systems are covered ADMT. Without it, scoping is guesswork.

Several things stay outside the platform. Counsel decides whether the institution is a deployer or developer and which decisions are consequential. Legal and compliance write and deliver the consumer explanation. Model risk management under SR 11-7, which covers development, implementation and use, validation, and governance, policies and controls, remains an organizational function. Platform evidence of what a deployed system was permitted to do can support validation, but it does not replace it. Escalation and cure procedures after an attorney general notice also need a named owner outside the platform team.

Control mapping: statutory, supervisory or engineering choice

Label every control by its origin. Examiners and internal reviewers will ask which requirements are legal and which are your design decisions, and the answer shapes how much latitude you have to change them.

• 30-day explanation of the ADMT's role (statutory): Platform: per-decision record of model, tools and data sources invoked, keyed to a decision ID and outcome. Organization: what counts as the ADMT's role, notice wording and delivery.
• Identifying covered ADMT (statutory scope): Platform: inventory of AI systems that participate in consequential decisions. Organization: legal determination of the definitions and of the institution's role.
• Cure readiness (statutory process): Platform: retained evidence of what happened and which rules applied, so a possible violation can be identified and corrected. Organization: named owner for notice response.
• Model validation and governance (supervisory, SR 11-7): Platform: runtime evidence of permitted behavior as an input to validation. Organization: validation, governance and policy ownership.
• Versioned policy and model configuration (engineering choice): Platform: evidence shows which rules and configuration applied at the time of a decision.
• Human escalation points (engineering choice): Platform: route defined actions or decision types to human approval inside the execution path. Organization: decide which decisions need a person.

Enforcing policy where the decision happens

Policy documents and after-the-fact reviews show what was intended. They do not show what an AI system was permitted to do, or did, in a particular interaction. Placing enforcement and evidence capture in the execution path, on model calls and tool calls, closes that gap because the record is produced by the same mechanism that applied the policy.

At runtime, each model call or tool call can be allowed, redacted, blocked, rate limited or escalated for human approval. None of these actions is mandated by the SB 26-189 summary. They are design choices that give the institution a defensible way to say what the system could do. For example, redaction limits which customer data reaches a model. Blocking prevents a tool from being called outside its approved use. Escalation puts a person in front of an action your policy says needs one.

Two tradeoffs deserve attention. Inline enforcement adds a dependency to the decision path, so availability and failure behavior (fail open or fail closed) must be decided per use case. And evidence volume grows quickly, so retention periods and data residency should follow the legal team's determinations rather than platform defaults.

Runtime enforcement addresses individual interactions and tool calls. It does not by itself establish a decision's business context across a multi-step workflow, and it does not make the legal determinations above.

Where Trussed fits

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, with actions to allow, redact, block, rate limit or escalate for human approval at the level of individual interactions and tool calls. Enforcement generates continuous, audit-ready evidence, so what the AI was allowed to do and what happened is enforced at runtime, not reviewed after the fact. It can be deployed self-managed in the customer cloud, with configurable retention and data residency.

Insurance, a regulated financial sector, is where Trussed is deepest. The platform has run continuously in a regulated enterprise for more than 18 months at 99.95% uptime on live production traffic, with more than 100 models under one policy plane. Whether any given control satisfies SB 26-189 is a determination for your counsel and compliance team.