Colorado SB 26-189 vs the NYDFS AI Letter: Do Multi-State Lenders Need Separate AI Controls?

Two instruments, two legal forms

The first difference is legal form, and it shapes how a control program should treat each instrument. Colorado SB 26-189 is a statute. Signed in May 2026, it repeals and reenacts part 17 of article 1 of title 6 of the Colorado Revised Statutes, replacing the AI provisions created by SB 24-205 with requirements for automated decision-making technology (ADMT) used in consequential decisions. The Attorney General enforces it through the Colorado Consumer Protection Act, and a violation is deemed a deceptive trade practice.

The NYDFS item is an industry letter titled "Cybersecurity Risks Arising from AI and Strategies to Combat Related Risks." An industry letter is a communication from the regulator, not a statute. Its subject, as the title indicates, is the cybersecurity risk that AI introduces and how regulated entities can address it. A lender should read it as the regulator's stated expectations and align its controls to them, while recognizing that it is a different kind of instrument from a statute with defined enforcement consequences.

That difference matters for architecture. A statute tends to produce specific, testable duties with dates attached. Regulator guidance tends to describe risk areas and expected practices. A control baseline has to serve both: fixed, verifiable behavior for the specific duties, and demonstrable discipline across the broader risk areas.

What Colorado SB 26-189 sets out, as of November 2026

Colorado's operative trigger is a date and a decision type. All other sections of the act take effect January 1, 2027 and apply to consequential decisions made on or after that date. The Attorney General must adopt implementing rules before then, and draft rules published in August 2026 cite the post-adverse-outcome disclosure provision and state a January 1, 2027 effective date.

The duty most clearly defined in the available text is the deployer disclosure. Within 30 days after a covered ADMT makes a consequential decision that results in an adverse outcome for a consumer, the deployer must give the consumer a plain-language description of the ADMT's role. Before January 1, 2030, the Attorney General must also give a developer or deployer 60 days' notice and an opportunity to cure an alleged violation, if a cure is possible. Planning should not assume that cure right continues afterward.

The statute assigns duties to developers and deployers. A lender using third-party AI needs to establish which role it holds, and which of its workflows use ADMT in consequential decisions rather than AI only in customer interaction. Colorado also passed a separate Chatbot Safety Act in May 2026 covering conversational AI services, so customer-facing chatbots should be assessed against it independently.

What runtime enforcement can and cannot evidence

Both regimes ultimately ask a lender to show a regulator what its AI was permitted to do and what it did. Those are two different records. The first is the policy in force. The second is the action taken in each interaction or tool call. Enforcement at runtime produces both as a by-product: when a policy is applied in the execution path, the decision to allow, redact, block or escalate is itself the evidence, and it is created when the event happens rather than reconstructed afterward.

The limits need to be stated plainly. Interaction-level and tool-call-level enforcement does not establish model lineage, dataset provenance or transaction-level governance across tasks and agents. Colorado's disclosure duty also assumes a deployer can work out which covered ADMT contributed to a given consequential decision and what role it played. That is an inference from the statute's structure, not a stated technical requirement. Per-event evidence supports that work, but it has not been shown to be sufficient for the duty until the final Attorney General rules are adopted.

This is the practical argument for a baseline plus targeted additions. The baseline covers what is common: enforced policy and durable evidence. The additions cover what is jurisdiction-specific or decision-specific, and they are built only where a duty requires them.

When separate controls are warranted, and where Trussed fits

Separate control sets are justified when a duty exists in only one jurisdiction and cannot be expressed as a configuration of the shared baseline. Colorado's 30-day explanation to a consumer after an adverse outcome is the main example in this comparison. Building it as a distinct process, tested against the final rules, is more defensible than distorting the baseline to carry it. Everything else, including enforcement, escalation and evidence, is better held once and varied by policy, because duplicated controls create inconsistent evidence and gaps between jurisdictions.

Ownership also needs a decision. Someone must attest that the baseline satisfies each jurisdiction, and someone must review changes as the Attorney General's rules and NYDFS communications develop. Whether the separate-controls question is ultimately legal or architectural should be reviewed by counsel; this comparison does not offer a legal opinion.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, and generates continuous audit-ready evidence mapped to NYDFS among other frameworks. It operates on individual interactions and tool calls, with 100+ models under one policy plane in production. It does not provide model lineage, dataset provenance or transaction-level governance, so those obligations need other tooling.