Colorado SB 189: Developer and Deployer Obligations

On 14 May 2026, Colorado Governor Jared Polis signed SB 189 into law, replacing the unenforced Colorado AI Act (SB 24-205) with a narrower framework that takes effect on 1 January 2027. The Colorado Attorney General has exclusive enforcement authority through the Colorado Consumer Protection Act, and no ordinary legislative window exists between now and the effective date.

The early commentary falls into two camps that mostly cancel each other out. Industry groups are presenting SB 189 as a major rollback and scaling back client compliance posture accordingly. Consumer advocates are mourning the death of meaningful AI regulation in the United States. Both framings miss what the bill actually does.

A narrower law that is operative creates more compliance exposure than a stronger predecessor that was frozen by litigation and never enforced. The novel piece of SB 189 sits in Section 6-1-1707, a statutory developer-deployer relative-fault rule for automated decision-making technology, which the Business Software Alliance fought against during the legislative process. For any company using automated decision-making technology in employment, housing, lending, insurance, healthcare, education, or essential government services in Colorado, the compliance exposure after SB 189 is real, concrete, and dated 1 January 2027.

This post walks through what changed, what deployers and developers each have to do, why Section 6-1-1707 is the most consequential piece of the law, and why the most cost-efficient path to SB 189 compliance for any company with EU exposure is to use an EU AI Act programme as the governing layer.

1. What Colorado just did

SB 189 (Senate Bill 26-189) passed the Colorado Senate 34-1 and the House 57-6, then went to Governor Polis on 14 May 2026. The bill repeals and replaces SB 24-205, the original Colorado AI Act passed in May 2024 and never enforced. The effective date is 1 January 2027.

Enforcement sits with the Colorado Attorney General under the Colorado Consumer Protection Act, with violations treated as deceptive trade practices. There is no private right of action, no joint and several liability beyond what existing law would provide, and civil penalties of up to $20,000 per violation under C.R.S. § 6-1-112. The AG is required to issue rulemaking on the post-adverse outcome disclosure obligation on or before 1 January 2027, the date the law takes effect.

Senate Majority Leader Robert Rodriguez, who authored SB 24-205, summed up the scope of the change in committee testimony: "I've whittled this bill down to more of a discrimination decision bill."

The practical effect of that whittling: SB 189 imposes targeted disclosure obligations on deployers, technical documentation obligations on developers, and a fault allocation framework that determines who pays when an AI system contributes to a discriminatory outcome. SB 189 drops the proactive-compliance architecture that defined SB 24-205 and that the EU AI Act has at its core.

2. Why most takes on SB 189 are wrong

The industry-rollback take goes like this. SB 189 strips out impact assessments, risk management programmes, the duty of reasonable care, and the algorithmic-discrimination framework that SB 24-205 had at its centre. SB 189 leaves three deployer obligations (consumer notice, post-adverse disclosure, records retention), three developer obligations (documentation, notice of updates, records retention), and a compliance surface dramatically smaller than either the original Colorado AI Act or the EU AI Act. Industry counsel can reasonably tell clients to scale back their Colorado-AI-Act readiness programmes.

The argument is internally consistent and substantively wrong. SB 24-205 was never enforced. It was signed in May 2024, delayed twice by the legislature, attacked through a sustained industry lobbying campaign, sued in federal court by Elon Musk's xAI, joined in that lawsuit by the US Department of Justice, and frozen by the Colorado Attorney General as the legislative and rulemaking timeline played out. Companies that ignored SB 24-205 paid no price for ignoring it. The compliance exposure under a frozen statute is theoretical.

SB 189 becomes enforceable on 1 January 2027, with the AG's rulemaking due on or before that date and a statutory cure mechanism (covered in Section 10) operative for most enforcement actions before 1 January 2030. No ordinary legislative window remains to delay the statute again. A narrower law that the AG will actually enforce creates more compliance exposure than a broader law that was frozen indefinitely.

The consumer-advocacy take goes the other way. SB 189 represents the death of meaningful AI regulation in the United States. The Colorado experiment failed; risk-based AI regulation cannot be passed and held in the US political system; companies face only token disclosure obligations.

That take misreads Section 6-1-1707. The relative-fault allocation between developers and deployers is the most consequential piece of SB 189, and it is the piece the Business Software Alliance fought against during the legislative process. The disclosure obligations in SB 189 are operationally taxing but legally familiar. The novel piece is the liability architecture in Section 6-1-1707, which is a statutory developer-deployer relative-fault rule inside a state ADMT law.

Read SB 189 as the United States' first operative AI compliance regime. Plan accordingly.

3. What changed in plain terms

Three substantive shifts separate SB 189 from SB 24-205. None is cosmetic.

The statutory term changed. SB 24-205 regulated "high-risk artificial intelligence systems." SB 189 regulates "automated decision-making technology" (ADMT). The new term is broader on its face but bounded by a "materially influence" test that the original "high-risk" language did not have. Section 5 walks through what ADMT covers in practice.

The compliance architecture changed from proactive to reactive. SB 24-205 imposed pre-deployment obligations: impact assessments, risk management programmes, a duty of reasonable care, and an obligation to report algorithmic discrimination to the Attorney General. SB 189 imposes post-deployment obligations: consumer notice at the point of interaction, plain-language disclosure within 30 days of an adverse outcome, correction rights, and meaningful human review on request. The compliance burden shifted from process documentation to outcome handling.

The liability framework changed from algorithmic discrimination to fault allocation. SB 24-205 created a Colorado-specific algorithmic-discrimination concept layered on top of existing antidiscrimination law. SB 189 deletes the algorithmic-discrimination concept and adds a fault allocation framework in Section 6-1-1707 that determines, for violations of existing antidiscrimination law (Title VII, Fair Housing Act, ECOA, ADA, ADEA, and state analogues), whether the developer of the ADMT or the deployer of the ADMT bears the cost.

For companies that have done EU AI Act readiness work, most of the proactive-compliance artefacts (impact assessments, risk management documentation, post-market monitoring) map cleanly to what SB 189 needs for Section 6-1-1707 defence and for the 30-day disclosure clock. Section 9 walks through that mapping.

4. SB 189 vs SB 24-205 vs EU AI Act at a glance

The graphic carries the comparison at a glance. The sections below walk through the SB 189 obligations one by one and then map them back to EU AI Act artefacts in Section 9. If your AI inventory touches both Colorado consumers and EU markets, Section 9 is the operating model for using one governance build across both regimes.

5. What automated decision-making technology actually means under SB 189

The ADMT definition is the gateway to every other SB 189 obligation. It covers any technology that processes personal data and materially influences a consequential decision in seven covered sectors: employment, housing, lending, insurance, healthcare, education, and essential government services. The word "materially" is the operative limit.

The seven covered sectors cast a wide net. Worked examples of systems that fall inside SB 189:

• An applicant-tracking system that scores or ranks candidates for employment screening
• A credit-scoring or underwriting model used in consumer lending
• An insurance underwriting or pricing model that takes individual personal data as input
• A healthcare prior-authorisation model that influences whether a treatment is approved
• A public-benefits eligibility model used by a state or local agency
• An education placement or admission system that influences student trajectories
• A tenant-screening model used by landlords and property managers

Worked examples that fall outside SB 189 in their typical configurations:

• A marketing-segmentation model that targets advertising but does not influence a consequential decision in a covered sector
• A model used purely for fraud detection that does not feed a covered consequential decision
• An internal analytics or business-intelligence system that does not produce individual-level decisions

The "materially influences" language is the litigation-prone part of the ADMT definition. A model that ranks candidates is materially influencing the employment screening decision even if a human reviews the ranking before making a final call. A model that provides one data point among many to a human decision-maker is plausibly outside ADMT, depending on how the human actually uses the output. The AG's end-of-2026 rulemaking is expected to clarify sector-specific examples.

The operator implication is that an organisation operating in any of the seven covered sectors needs an ADMT inventory keyed to the "materially influences" threshold for each system. A system used for marketing in one workflow and for workforce screening in another may be inside SB 189 for the second use and outside it for the first. Inventory each use case separately, because the same system can fall inside SB 189 in one workflow and outside it in another.

Colorado nexus. Coverage turns on a person doing business in Colorado using or making available covered ADMT for consequential decisions involving Colorado residents, Colorado-resident job applicants and employees, or opportunities that condition access, eligibility, or benefits in Colorado. A non-Colorado company that has no Colorado consumers or operations is outside the statute. A non-Colorado company that uses ADMT to evaluate Colorado consumers is inside.

Exemptions and non-duplication. Before engineering scopes any SB 189 workflow, each ADMT needs two tags: the sector it affects and any overlapping regime that changes the procedure. SB 189 carries a set of statutory carve-outs in Section 6-1-1708 that govern overlap with other regulatory regimes: ECOA and FCRA notice requirements for credit decisions, FERPA processes for education records, federal cybersecurity and fraud/AML/sanctions obligations, HIPAA-covered entities and business associates, FDA-regulated medical devices, GLBA-protected information for financial institutions, and Colorado insurance rules for regulated insurers. An ADMT subject to one of these regimes is not automatically outside SB 189; the carve-outs address specific procedural or substantive duplication while leaving the new disclosure and documentation duties in place.

6. What deployers must do before 1 January 2027

A deployer is any organisation that uses a covered ADMT to materially influence a consequential decision. Deployers face three concrete obligations.

Consumer notice at the point of interaction. Deployers must provide clear and conspicuous notice to consumers that an ADMT is being used in a consequential decision affecting them, along with instructions for obtaining additional information about the system. The notice can be satisfied through a public posting that is reasonably accessible at points of consumer interaction. Think of it as the AI equivalent of a privacy notice, though the AG's rulemaking may impose specific format and content requirements before the law takes effect.

Post-adverse outcome disclosure within 30 days. When a covered ADMT produces an adverse outcome for a consumer, the deployer must provide a plain-language disclosure within 30 days that contains: a description of the decision and the ADMT's role in producing it, the types and categories of personal data the ADMT used, instructions for requesting data correction, and information on how to request meaningful human review. Each disclosure needs enough system-specific detail for the consumer to understand what happened, request correction, and seek meaningful human review. The AG's rulemaking will clarify sector-specific content requirements.

Records retention for three years. Deployers must retain records reasonably necessary to demonstrate compliance, including system version identifiers, change logs, and documentation of any material mitigation changes. The three-year clock starts on the date of the consequential decision; the system deployment date does not reset or anchor the period.

The first and third obligations are operationally tractable. The second one is the engineering problem. Any organisation making thousands of AI-influenced decisions per month in covered sectors needs infrastructure to detect adverse outcomes in real time, trigger the disclosure workflow, generate a plain-language explanation, route the disclosure to the consumer, and document compliance against a 30-day SLA. That infrastructure does not exist by default; it has to be built. Six to twelve months of engineering work is a reasonable estimate for a large enterprise with multiple ADMT systems in scope, depending on how mature the underlying observability tooling already is.

7. What developers must do under SB 189

A developer is any company that develops, sells, licenses, or makes commercially available a covered ADMT. Developers face three obligations.

Technical documentation to each deployer. Developers must provide each deployer with documentation reasonably understandable to a deployer that covers: a general statement of intended uses and known harmful uses, a description of the categories of training data, known limitations and circumstances where the ADMT should not be used, and instructions for appropriate use, monitoring, and meaningful human review. Trade secrets remain protected; the documentation requirement does not force disclosure of model architecture or training data specifics beyond categorical descriptions.

Notice of material updates within a reasonable time. When a developer releases an update that materially affects the ADMT's outputs, performance, or intended use, the developer must notify deployers within a reasonable time. Material updates include changes to model parameters, default settings, and the developer's documentation about intended use.

Records retention for three years. Developers must retain records necessary to demonstrate compliance, including version identifiers, change logs, and documentation provided to deployers. The developer retention clock runs from record creation; the deployer clock runs from the consequential decision date.

Framed as checklist items, the three obligations understate the legal function of technical documentation. Documentation is load-bearing for Section 6-1-1707, the developer-deployer fault allocation framework that Section 8 walks through. The boundary defined in the developer's intended-use documentation is the boundary of the developer's liability exposure. A developer who writes vague intended-use documentation expands the range of deployer applications for which the developer can be held liable. A developer who writes precise, bounded intended-use documentation and actively notifies deployers when uses fall outside that scope creates a defensible position before the AG.

8. Section 6-1-1707: the developer-deployer relative-fault rule that has no precedent in state ADMT law

The most consequential piece of SB 189 sits in Section 6-1-1707. It allocates fault between developers and deployers in actions alleging unlawful discrimination under Colorado anti-discrimination law when a covered ADMT materially influenced the consequential decision that gave rise to the claim. The underlying cause of action remains in existing Colorado law; Section 6-1-1707 adds the allocation rule on top.

The framework has three elements.

First, the underlying claim is brought under Colorado state law, including the Colorado Anti-Discrimination Act and other Colorado anti-discrimination statutes. SB 189 does not invent new discrimination causes of action and does not reach into federal antidiscrimination claims directly. For a technology leader, the practical consequence is that AI documentation becomes evidence in claims brought under Colorado laws that already apply; there is no new AI-specific cause of action to defend against.

Second, fault is allocated between the developer and the deployer according to their relative fault, subject to gates set out in Section 6-1-1707. The statute does not create new joint and several liability beyond what existing law would provide, and it does not authorise claimant apportionment unless existing Colorado law independently permits it. The pivot is whether the deployer used the covered ADMT in a manner "intended, documented, marketed, advertised, configured, or contracted for by the developer."

A developer is liable under Section 6-1-1707 only where the deployer used the ADMT in a manner that fell within the developer's documented intended use, and the ADMT materially influenced the consequential decision that gave rise to the violation. A deployer remains liable for its own independent acts or omissions in any case, including out-of-scope uses where the developer complied with its Section 6-1-1702 documentation duties.

That structure does real work. The intended-use documentation a developer writes under Section 6-1-1702 is what defines the boundary between developer liability and deployer liability under Section 6-1-1707. A developer that writes loose intended-use documentation expands its exposure across the breadth of deployer applications that fall within that documentation. A developer that writes precise, bounded intended-use documentation and notifies deployers when usage drifts outside that scope confines its exposure to the use cases it actually built for.

Third, Section 6-1-1707(7) voids contractual provisions that purport to indemnify, defend, or hold harmless a developer or deployer from damages under Section 6-1-1707 for the party's own acts or omissions violating Colorado anti-discrimination law in connection with covered ADMT. Companies cannot contract their way out of Section 6-1-1707 by writing indemnification clauses into vendor agreements. The anti-indemnification rule is set as a matter of public policy under Colorado law.

The Business Software Alliance, representing Microsoft, Oracle, SAP, and other major US enterprise software vendors, fought Section 6-1-1707 during the legislative process. They lost. That reaction is informative. The transparency requirements in SB 189 are operationally taxing but legally familiar; comparable disclosure regimes already exist under state consumer-protection law. Section 6-1-1707 is the novel piece, and it is novel in a direction that creates real downside exposure for the largest commercial AI vendors.

The honest counter-case is that Section 6-1-1707 may produce fewer courtroom fault allocations than the emphasis here suggests. The statute creates no private AI cause of action, most AG actions receive a 60-day cure window through 2029, and the underlying discrimination claim still has to arise under existing Colorado law. The provision still matters because it changes procurement, documentation, contract drafting, and enforcement posture before litigation arrives. Vendor counsel asking for fewer commitments and enterprise buyers asking for more documented intended-use boundaries is the more probable near-term effect of Section 6-1-1707 than a courtroom test of fault allocation.

The operator implications split by role.

For developers, intended-use documentation stops being a marketing artefact and becomes a liability-management instrument. Vague intended-use language that lets sales teams pursue any deployer application expands the developer's Section 6-1-1707 exposure across that range. Precise, bounded intended-use documentation, combined with active deployer notification when usage drifts outside that scope, creates the defensible record an AG enforcement action would require.

For deployers, the contractual scope and operational configuration need to match the documented intended use. A deployer that uses an ADMT outside the developer's documented intended use bears the full Section 6-1-1707 exposure alone. Confirming alignment between deployment configuration and developer documentation should sit in quarterly governance, because procurement checks age quickly as configurations and vendor documentation change.

For both, indemnification clauses in vendor agreements need to be audited against Section 6-1-1707(7). Clauses that purport to indemnify either party against its own discriminatory acts under covered ADMT are unenforceable in Colorado as a matter of public policy. Existing template contracts likely need redrafting.

9. Colorado companies should build for the EU AI Act anyway

SB 189 is one of the first broad state AI compliance regimes to become operative for developer and deployer obligations in consequential decisions, and for any company already running an EU AI Act programme, that programme is the right governing layer for SB 189 compliance too. The EU programme produces several high-cost SB 189 inputs: intended-use boundaries, lifecycle risk records, monitoring signals, human-review workflows, and registration evidence. Colorado still adds its own disclosure, routing, correction, records, and contract-review work on top.

Use the EU AI Act programme as the governing layer where EU market access, EU subsidiaries, Annex III-like use cases, or enterprise procurement already justify the EU build. For companies with no current EU exposure and no near-term EU plan, start with a Colorado-first ADMT control layer and reuse EU artefacts only where they reduce duplicate work in the same direction.

The mapping for EU-exposed companies is concrete.

EU AI Act artefact	SB 189 use	Where Colorado still asks for more
Intended-purpose declarations (Article 13 instructions for use; Recital 53)	Developer documentation to each deployer; the boundary that Section 6-1-1707 fault allocation hinges on	Specific intended-use boundaries narrow enough to defend in an AG enforcement action; deployer notification when usage drifts outside that scope
Risk management system (Article 9)	The documented record of how the developer governed the system across its lifecycle; defence record under Section 6-1-1707	Translation into a deployer-facing summary that a non-technical compliance officer can interpret
Post-market monitoring (Article 72)	Provider-side signal infrastructure that a deployer can build on for adverse-outcome detection feeding the SB 189 30-day disclosure clock	Deployer-side routing infrastructure from detection signal to consumer disclosure within 30 days; identity resolution from system event to affected consumer (provider monitoring is not automatically consumer-disclosure-ready)
Human oversight provisions (Article 14)	The meaningful-human-review pathway that SB 189 deployers must offer on request	Consumer-facing intake to request human review; documented escalation path; SLA on review turnaround
Article 49 registration in the EU database (Article 71 hosts the database)	Discoverable evidence of governance posture useful in an AG enforcement action	Colorado-specific consumer notice format and content (pending AG rulemaking on or before 1 January 2027)

The EU AI Act is proactive, assessment-based, and detailed about what counts as governance. SB 189 is reactive, disclosure-based, and short on prescriptive process. A company that has done the EU work has already produced most of the documentation a Colorado AG enforcement action would request. The Colorado-specific gaps are the consumer-facing routing and notice mechanics that the EU regime does not require directly, plus the Section 6-1-1707 contract review for anti-indemnification compliance. Those gaps are real engineering work, but they are a Colorado delta on top of the EU programme.

Connecticut is moving on a similar but narrower path with an employment-centred AI bill that pulls some of the same control patterns into a different procedural shape. Federal comprehensive AI regulation under the current administration remains unlikely, though preemption proposals are circulating in the White House framework and pending congressional text. The practical state-level US build is going to be modular by state, sector, and decision type, with the same artefacts feeding the EU AI Act for any company that also has EU exposure.

For any company with even occasional EU exposure, running one EU AI Act programme that satisfies most of SB 189 is more efficient than running two separate compliance builds. For companies with no EU exposure today, an EU AI Act build is justified only when EU market entry, buyer diligence, or enterprise governance already makes the investment likely. The cheaper first move otherwise is a Colorado-ready ADMT inventory, disclosure workflow, correction intake, human-review path, three-year records layer keyed to the consequential decision date, and Section 6-1-1707(7) contract audit.

US-only employers and HR technology vendors should build the state-law control layer first: an employment ADMT inventory, role tagging by developer or deployer, intended-use documentation, pre- and post-decision notices where the state law requires them, correction and human-review workflows, bias-testing evidence appropriate to the sector, records retention, and contract allocation under Section 6-1-1707. EU AI Act controls become the governing layer for these companies only once EU market access or EU-facing procurement is real.

10. The actual cost of waiting for the AG rulemaking

A defensible-looking response to SB 189 is to wait for the Colorado AG's rulemaking, due on or before 1 January 2027, before starting the workflow build. The rulemaking will clarify sector-specific content requirements for the post-adverse disclosure, the notice format, and possibly the inventory threshold for "materially influences." Why build workflows that may need to be reconfigured?

The cost of that posture is that the workflows do not exist by default. Detecting adverse outcomes in real time across an enterprise ADMT inventory requires observability infrastructure. Generating plain-language explanations within 30 days requires either templated explanation systems with sector-specific copy or generative-AI infrastructure with prompt and review controls. Routing the disclosure to the affected consumer requires identity resolution across decision systems and CRM. Documenting compliance against an SLA requires audit logging that survives an AG records request. Records retention for three years across all of that requires storage planning that respects the existing privacy law of each state where data is processed.

That is six to twelve months of engineering for a large enterprise with multiple covered ADMT systems, depending on ADMT inventory complexity, observability maturity, and how much of the disclosure path can lean on existing customer-communication infrastructure. A company that waits for the AG's rulemaking before starting will not have the workflows in place at the 1 January 2027 effective date. Treat the rulemaking as a configuration parameter for workflows already in motion.

The 60-day cure window. SB 189 includes a notice-and-cure mechanism that softens the immediate enforcement risk. Before initiating most enforcement actions, the AG must issue a notice where the violation is curable, and the developer or deployer then has 60 days to cure. Knowing or repeated violations can skip the cure period. The cure mechanism sunsets on 1 January 2030, after which violations move directly to enforcement. Treat the cure window as a short-term buffer while the workflows mature. A company that cannot detect, document, and remediate an adverse-outcome disclosure failure inside 60 days of notice has not built the workflows the statute assumes are running.

The procurement cycle compounds the timeline. Enterprise buyers in late 2026 will start asking AI vendors for evidence of SB 189-ready deployment configurations. A developer that cannot produce intended-use documentation, training-data category descriptions, monitoring instructions, and meaningful-human-review documentation by Q4 2026 is going to lose those procurement conversations to vendors who can. The EU AI Act programme is the cheapest way to produce all of that on time.

11. The bigger lesson: what Colorado tells us about US AI regulation

Colorado ran the clearest two-year stress test of risk-based AI regulation in American history. Three legislative sessions including a special session, a federal lawsuit from xAI, intervention by the US Department of Justice, a voluntary enforcement freeze by the Colorado Attorney General, and a sustained lobbying campaign by more than 150 industry groups produced a workable equilibrium that other state legislatures are likely to pattern-match.

What survived: transparency obligations at the point of consumer interaction, post-adverse outcome disclosure with correction rights and meaningful human review, three-year records retention, and fault allocation under existing antidiscrimination law. What did not survive: impact assessments, risk management programmes, conformity assessments, and proactive duties of care directed at AI specifically.

Connecticut is moving on a similar but narrower path with an employment-centred bill, which suggests the family of US state AI law is taking shape as modular control architecture: notices, correction, human review, records, developer documentation, and fault allocation, with sector-specific and procedural variations between states. Federal comprehensive AI regulation under the current administration remains unlikely, though federal preemption proposals are circulating. The practical near-term US compliance regime is going to be modular by state, sector, and decision type, with each state adding sector-specific or terminology-specific variations on the same control vocabulary that SB 189 has now established.

For governance teams, the right question has shifted. The question that mattered under SB 24-205 was "what does the law require us to document?" The question that matters under SB 189 is "when an AI system produces a discriminatory outcome and an enforcement action follows, will our documentation demonstrate that we governed responsibly?" Under the Section 6-1-1707 fault allocation framework, the answer to that question determines who bears the cost.

The companies that understand this build governance programmes that produce defensible records as a primary output. Those programmes look very much like EU AI Act programmes already do. The Colorado experiment ratified the shape of the work without imposing the shape of the framework.

What to do this month

Inventory the ADMT footprint against the seven SB 189 covered sectors (employment, housing, lending, insurance, healthcare, education, essential government services). Tag each system with the developer-vs-deployer role, the intended-use boundary, and the alignment between contractual scope and operational configuration. Owners: AI governance and product owners for the inventory itself; legal and privacy for disclosure-workflow design; engineering for adverse-outcome detection and routing; security and IT for records retention and logging; vendor management for the Section 6-1-1707(7) contract audit. If an EU AI Act programme is already running, map the existing artefacts to SB 189 obligations and identify the disclosure, routing, correction-intake, and contract-review work the Colorado side adds on top.

Modulos works with enterprises on the AI inventory, classification, and lifecycle governance that SB 189, the EU AI Act, and ISO 42001 all require. Request a demo to see how the platform makes the cross-jurisdiction build a single programme.