Generating and Logging Colorado SB 26-189 Consumer Notices at Runtime

What the statute requires, and what that means at runtime

As of November 2026, SB 26-189 is documented as a session law, and the Attorney General's office has published pre-rulemaking considerations that seek comment on consumer notice regulations. Detailed rules may follow, so the notice design should be easy to change.

The act sets two notice moments. The first is a pre-use notice. Before a deployer uses a covered ADMT to materially influence a consequential decision, it must tell the consumer that the decision uses ADMT. The notice must be clear and conspicuous at the point of interaction. It can be satisfied by a prominent public notice that is reasonably accessible at points of consumer interaction, including a link or posting reasonably proximate to the interaction or transaction in which a consequential decision may occur.

The second is a post-decision notice. If a covered ADMT makes a consequential decision with an adverse outcome, the deployer must give the consumer, within 30 days, a plain-language description of the decision and the ADMT's role. The notice must also include instructions and a simple-to-follow process for requesting additional information about the ADMT and its inputs, and an explanation of consumer rights. Those rights include requesting personal data, requesting correction of factually incorrect data used by the ADMT, and requesting meaningful human review and reconsideration after an adverse outcome.

Both developers and deployers must retain records demonstrating compliance for at least three years. Violations of the disclosure requirements are a deceptive trade practice enforced by the Attorney General under the Colorado Consumer Protection Act. In practice, that means the question a regulator can ask is not whether a notice page exists, but whether a specific consumer interaction was covered by a notice and whether you can prove it.

Notice templating and versioning

Treat the post-decision notice as a template with required fields: the decision description, the ADMT's role, the information-request instructions and process, and the explanation of consumer rights. If a field cannot be populated, the generation step should fail and escalate instead of sending a partial notice.

Version every template. Developers must give deployers technical documentation that includes information reasonably necessary for the deployer's own notice and disclosure duties, and must notify deployers of material updates or modifications to the ADMT. Link each template version to the developer documentation and update notices it relies on, and to the ADMT version in use when the notice was issued. Without that link, you cannot show that notice content matched the system's actual behavior at the time.

Keep template content separate from application code. Because the Attorney General's office is considering consumer notice regulations, content, format or timing requirements may change. A template store with a change history lets you update wording without redeploying applications, and the change history itself becomes part of your evidence.

The notice evidence record

The statute requires records that demonstrate compliance but, in the text reviewed here, does not prescribe a schema. The fields below are a suggested design. Write each record as an immutable entry at the moment of enforcement, not as a reconstruction from application logs afterward. Retain records for at least three years from creation, and confirm the retention start point against the final text.

The record should answer four auditor questions: what was shown, why it was shown, whether the system allowed the action, and whether the consumer received it. Use a pseudonymous consumer or session reference where possible, and decide early where records are stored, since retention and data residency requirements may constrain the location.

• Notice type and template version: Pre-use or post-decision, with the template version and linked ADMT and developer documentation versions.
• Trigger event: The interaction or decision event that caused evaluation, with the policy condition that matched.
• Timestamps: Interaction time, decision time for adverse outcomes, generation time and delivery time.
• Policy decision: Allow, block or escalate, with the policy version that produced it.
• Delivery channel and status: Where the notice was presented or sent, and whether presentation or delivery was confirmed.
• Consumer or session reference: An identifier that lets you retrieve the record for a specific interaction on inquiry.

Enforcing the step in the execution path

Hard-coded application-layer notices and manual review share a weakness: they sit beside the AI execution path rather than in it. Each application implements its own logic, coverage differs across models, agents and tools, and the record of what happened is assembled after the fact. A policy enforced at runtime applies one rule across every path that can influence a decision, and produces the evidence as a by-product of enforcement.

Trussed is one way to implement this. It enforces policy in the execution path across models, agents and tools, with outcomes such as allow, redact, block and escalate for human approval, scoped to individual interactions and tool calls. Evidence is generated by that enforcement and is audit-ready, and it can be retained in the customer's own cloud with configurable retention and data residency. In this pattern, that covers the pre-use check and the evidence record for each interaction. The 30-day post-decision timer and template store remain components you design, and they should write to the same evidence trail.

The tradeoff of inline enforcement is added latency and a new dependency in the request path. Decide the failure behavior explicitly: for covered decision contexts, a failed notice check should block or escalate, not default to allow.