Key Takeaways
The original Colorado AI Act, SB 24-205, never took effect. Colorado replaced it with SB 26-189, signed on 14 May 2026 and effective 1 January 2027. The new law covers automated decision-making technology that materially influences consequential decisions about people. It requires notice before use, an explanation within 30 days of an adverse outcome, human review on request, and three years of records.
- Scope: decisions about education, employment, housing, lending, insurance, healthcare and government benefits, not AI in general.
- Effort: the heavy lifting is decision records, notice tracking and a human-review queue.
- Risk: a 30-day explanation clock you cannot meet because the decision inputs sit in separate systems.
- Retention: at least three years of records, longer than many platform logs keep by default.
The law most teams planned around is gone. Colorado Governor Jared Polis signed SB 26-189 on 14 May 2026, substantially revising the state’s AI law before the original version, which had been set to take effect on 30 June 2026, ever applied. The replacement takes effect on 1 January 2027.
The new text is narrower, but its record-keeping is concrete. Developers and deployers must retain records necessary to demonstrate compliance for at least three years, and a deployer owes a plain-language description of the system’s role within 30 days after it makes a consequential decision with an adverse outcome. Both are data problems before they are legal ones.
Here is what that looks like on the ground. A lender’s scoring vendor returns a number, an underwriter overrides it in a loan system, and the notice text sits in a document tool. Three months later a declined applicant asks why. Nobody can reassemble the decision, and the 30-day window is already running.
What Changed Between SB 24-205 and SB 26-189
If your team spent 2025 preparing for SB 24-205, some of that work carries over and some does not. The replacement is scoped to automated decision-making technology (ADMT) in consequential decisions. Do not plan around annual algorithmic impact assessments, a statutory duty of reasonable care, or a mandated risk-management program: none of them appears in SB 26-189.
What carries over is the data foundation, and it belongs on one governed lakehouse rather than spread across the systems that make the decisions. An inventory of decision systems, lineage on their inputs and a durable decision log were useful under the old bill and are required in practice under the new one.
The Definitions That Set Your Scope
The bill defines ADMT as a technology that processes personal data and uses computation to generate output used to make, guide or assist a decision concerning an individual. A consequential decision is one that relates to an individual’s access to, eligibility for, or compensation related to education, employment, housing, financial or lending services, insurance, health-care services, or essential government services and public benefits.
Two practical readings follow. First, “guide or assist” reaches beyond fully automated decisions: a score an underwriter reads counts if it materially influences the outcome. Second, the trigger is the decision category, not the technique. A rules engine is in scope as much as a gradient-boosted model or a large language model.
Five Obligations, Five Data Artifacts
| Obligation in SB 26-189 | Who owes it | Data artifact that supports it |
|---|---|---|
| Clear and conspicuous notice before ADMT materially influences a consequential decision | Deployer | Notice version table joined to every decision record |
| Plain-language description of the ADMT’s role within 30 days after an adverse outcome | Deployer | Decision log with adverse flag and an explanation-due date |
| Right to request meaningful human review and reconsideration after an adverse outcome | Deployer | Review queue table with reviewer, outcome and timestamps |
| Technical documentation: intended uses, training data categories, known limitations, instructions for appropriate use | Developer | System inventory row linked to the vendor documentation version |
| Records to demonstrate compliance, kept at least 3 years | Developer and deployer | Retention policy on all of the above, plus snapshots of lineage and audit logs |
Deployers who buy a vendor score still need the developer’s documentation inside their own inventory. When the explanation request arrives, the vendor’s PDF on a procurement share does not help the analyst writing the answer.
Decision Records as an Architecture
Treat decision records as a product of the lakehouse, built with the same medallion discipline as anything else. Bronze holds the raw inputs: application fields, vendor scores, the model output. Silver conforms them to one consumer key and one definition per field. Gold holds the decision log, the notice table and the review queue.
The decision log is append-only and written only by the service principal that runs the scoring job. Each row carries decision_id, consumer_key, system_id, model_version, a pointer to the exact input row, the outcome, an adverse flag, the notice version shown, decided_at and explanation_due_at, which is decided_at plus 30 days. That last column turns the statutory clock into something a dashboard can count down.
Unity Catalog captures lineage automatically for queries run on Databricks, down to the column level, so the path from source field to decision input is recorded without hand-drawn diagrams. It has gaps: column-level lineage is not captured for UDFs or for tables referenced by path. Our Unity Catalog guide covers the setup that keeps lineage intact.
Human Review Needs a Queue, Not an Inbox
“Meaningful human review” fails most often as a shared mailbox. Requests arrive, someone forwards them, and nobody can show later who reviewed what. Build it as data instead. A review request lands in a table, Lakeflow Jobs (formerly Workflows) routes it with branching logic by decision type, and the reviewer’s outcome writes back to the review table and to the decision log.
This is where Lean thinking pays. Map the review value stream with the people who do it. Where does the reviewer need the original inputs? Who can overturn? What counts as reconsidered? Automate that process after it is agreed, not before. In AIM-IT terms, Assess and Innovate come before Model and Implement for a reason.
Keeping Three Years of Records When Logs Keep One
This is the detail that catches good teams. The lineage system tables, system.access.table_lineage and system.access.column_lineage, keep a rolling one-year window. The audit log system table, system.access.audit, is in Public Preview with a default 365-day retention, configurable through a Beta setting. Colorado asks for at least three years.
So copy what you need into the lakehouse. A scheduled job snapshots the lineage and audit rows that touch in-scope tables into your own governed Delta tables every month, tagged by decision system. Then the three-year obligation is met by your retention policy, not by a platform default you do not control.
Access Control Around Consumer Decision Data
Decision logs are dense with sensitive data, which makes them an attractive target and an easy overshare. Databricks announced attribute-based access control, governed tags and automated data classification as generally available on 13 May 2026. Use ABAC row filters and column masks so reviewers see full records for their queue, analysts see masked consumer keys, and nobody gets update rights on the log.
Where AI Agents Fit
Expect someone to point an assistant at the decision data to draft explanations. That is reasonable, with controls. Microsoft states that Copilot extensions do not grant access beyond what the user is already authorized to see, which means your permissions are the control. Ground any drafting agent on gold tables with defined meanings, because an agent that improvises over raw inputs writes confident nonsense. Our piece on why AI agents hallucinate on company data explains the mechanism. A human signs the explanation before it goes out.
What Trips Teams Up Before January
- Scoping by technique instead of decision. Teams inventory their machine learning models and miss the rules engine and the vendor score. Walk every consequential decision point instead.
- Logging the model, not the decision. The score is logged; the underwriter’s override is not. The log then describes a decision that never happened.
- No adverse flag. Without an agreed definition of an adverse outcome per decision type, the 30-day clock cannot be computed, let alone met.
- Vendor documentation outside the catalog. Developer documentation arrives as a PDF and never links to the system inventory, so the explanation writer cannot find it.
- Retention left to defaults. Lineage and audit history roll off after a year while the statute asks for three.
Two regulatory details are still settling. The Colorado Attorney General is reported to be required to adopt implementing rules by 1 January 2027, with proposed rules filed in August 2026 and a hearing reportedly scheduled for 26 October 2026. Law-firm summaries also report that enforcement sits with the Attorney General, with no private right of action. Watch the final rules before you freeze explanation templates.
Readiness Signals: When You Are Ready and When You Are Not
Score yourself honestly against these before the end of the year.
You are ready when every consequential decision point has an owner and an inventory row; decision inputs land in governed tables with lineage you have checked end to end; the decision log records the final decision, including human overrides; explanation_due_at drives a dashboard someone reviews daily; the review queue is a table with timestamps; and lineage and audit snapshots are running on a schedule.
You are not ready when the inventory is a slide; any decision input comes from a spreadsheet; overrides live in email; nobody has defined an adverse outcome for each decision type; or your retention plan is “the platform keeps logs”.
If you land in the second group, the gap is usually three months of focused work on one governed lakehouse. Our AI governance and compliance practice builds the inventory, decision log and review queue on Databricks. This is general information, not legal advice, and counsel or a qualified assessor makes the compliance call for your organization.
Frequently Asked Questions (FAQs)
Is the Colorado AI Act still going into effect?
The original act, SB 24-205, never took effect. It was replaced by SB 26-189, signed on 14 May 2026, which takes effect on 1 January 2027 with a narrower scope focused on automated decision-making technology in consequential decisions.
What is a consequential decision under SB 26-189?
A decision relating to an individual’s access to, eligibility for, or compensation related to education, employment, housing, financial or lending services, insurance, health-care services, or essential government services and public benefits.
Does the Colorado AI Act require annual impact assessments?
Not under SB 26-189. The replacement law centers on notice, post-adverse-outcome explanations, human review, developer documentation and record retention. Plan around those obligations rather than an assessment cycle.
How long must records be kept under the new Colorado law?
Developers and deployers must retain records necessary to demonstrate compliance for at least three years. Check that against platform defaults: several Databricks system tables keep about one year unless you copy the data out.
Can consumers sue under the Colorado AI law?
Law-firm summaries report no private right of action. Enforcement is reported to sit with the Colorado Attorney General, with violations treated as deceptive trade practices.
What should a data team build first for Colorado compliance?
An inventory of every automated system that influences a consequential decision, with owners and data sources. The decision log, notice tracking and review queue all depend on knowing which systems are in scope.