When Does the Colorado AI Act Take Effect? What Asian Vendors Owe

Colorado's rewritten AI Act, SB 26-189, takes effect on 1 January 2027 and applies to consequential decisions made from that date. Signed on 14 May 2026 to replace the 2024 law, it dropped impact assessments and risk programs. What it kept matters more to a software vendor in Singapore or Southeast Asia. If you sell, license or build part of a tool that scores, ranks or recommends about people for jobs, credit, insurance, housing, education, health care or public benefits, and your customers use it in Colorado, you can be a "developer" with documentation duties.

The timing is tight. The Colorado Attorney General's proposed rules, filed on 11 August 2026, go to a public hearing scheduled for 26 October 2026, and as drafted they would also take effect from 1 January 2027. This is general information, not legal advice.

What changed when Colorado rewrote its AI Act?

Colorado rewrote its AI Act by repealing the 2024 statute and re-enacting a narrower one. SB 26-189, signed on 14 May 2026, swaps the old duty to prevent "algorithmic discrimination" for disclosure duties around "automated decision-making technology" (ADMT, software that uses personal data to score, rank or recommend about a person). The new text governs from 1 January 2027.

The original law, SB 24-205, was signed on 17 May 2024. It asked developers to use reasonable care against algorithmic discrimination and required deployers (the businesses that use the tool on consumers) to run a risk management program and complete impact assessments. An August 2025 special session moved its start to 30 June 2026.

That date passed with the 2024 text on the books and unenforced. The AI company xAI sued in April 2026, and the US Department of Justice moved to intervene on 24 April 2026. Three days later the Attorney General agreed to a court order not to enforce it, covered below.

Here is what the replacement keeps and what it drops.

Most coverage reported that Colorado narrowed its AI law, which is right for deployers. The developer's documentation duty survived almost whole. A deployer cannot write a lawful explanation of an adverse decision without it.

Who counts as a developer, and can an Asian vendor be one?

An Asian vendor can be a developer under SB 26-189 without any office in the United States. The Act defines a developer as "a person doing business in Colorado" that "develops, offers, sells, leases, licenses, or otherwise makes commercially available" a covered ADMT, or builds a component designed or contracted for one (signed act, section 6-1-1701(8)). A head office in Singapore does not take you out. Two features of the definition decide most cases.

The first is a gap. The Act never defines "doing business in Colorado", and it does not require an office, staff or a Colorado entity. Careful vendors whose contracts let a Colorado employer screen applicants, or a Colorado lender score borrowers, assume they are exposed until counsel has looked at their facts.

The second is that your marketing and contracts set your scope more than your model does. The developer documentation duty applies only where the tool "was marketed, advertised, configured, contracted, sold, or licensed to be used to materially influence a consequential decision" (section 6-1-1702(3)). The definition of ADMT also excludes a tool used "solely to summarize, organize, translate, draft, route, or present information for human review of administrative processing". Customer service triage, marketing, fraud prevention and anti-money-laundering controls are carved out of "consequential decision" altogether.

Customer-facing chatbots get their own exclusion, with two conditions. The bot must not be "contracted, advertised, marketed, configured, or intended by a person to be used in a consequential decision", and it must sit under an acceptable use policy that bans using its output in one (section 6-1-1701(2)(b)(III)). Note the words "by a person". If a customer configures your bot to pre-screen applicants, the policy alone may not keep it out, so a policy you monitor and act on is worth more than one buried in the terms.

The same model can be in or out. A landing page promising "AI shortlists your best candidates" pulls you in. The duty can also switch on later, once you become aware that customers use the tool for consequential decisions in line with its intended and contracted uses (section 6-1-1702(5)).

Illustrative example: a Singapore HR-software firm sells two products to 80 US customers, 4 of which hire in Colorado. Product A ranks applicants and is sold as "shortlist your strongest candidates". Product B is a chatbot that answers candidates' questions, under a use policy that bans using its answers in hiring decisions, and no customer has configured it to screen anyone. Product A puts the firm in the developer box for those 4 customers. Product B stays outside the definition while those facts hold. The decision this supports: one documentation pack for Product A by the end of 2026, a reviewed policy plus a configuration check for Product B, and no company-wide AI compliance program.

There is a second route in, and it fits many Southeast Asian software firms. The Attorney General's proposed rules of 11 August 2026 define a "midstream developer" as "a party that integrates Covered ADMT as a component into its own Covered ADMT product and provides its Covered ADMT product to another Developer or a Deployer". Proposed Rule 4.2 gives the example of a company that builds an AI application on third-party foundation models and sells it on: that company must obtain the upstream documentation, "to the extent possible", and make it available to its customers. A proposal is not a rule yet, and the hearing notice openly asks whether "ADMT vendors" need their own duties. Plan for the pass-through anyway.

What does a developer have to hand over from 1 January 2027?

From 1 January 2027 a developer owes each Colorado deployer a written documentation pack under section 6-1-1702. It covers intended and known harmful uses, training-data categories, known limitations, instructions for monitoring and human review, and whatever else the deployer needs for its own disclosures. Material updates need timely notice.

The obligations split like this (1702 means section 6-1-1702).

Version identifiers are where engineering teams get caught. After an adverse decision, the deployer must give the consumer a way to request the system's name, its "version number, if applicable" and its developer, to the extent the deployer received that information (section 6-1-1704(3)). If you ship weekly and cannot map a decision date to a version per customer, your customer has nothing to pass on.

For a product built on a third-party model API, a version string for your own code is not enough. The useful record is a tuple: your release, the provider's model identifier, the prompt template and that customer's configuration on that day. Logging it per decision is the same discipline as an audit trail that answers who did what, with which version, and when.

Owners and managing directors should read the liability section twice. A developer is liable in a discrimination claim "only to the extent" the deployer used the tool as the developer intended, documented, marketed or contracted. Any contract clause that indemnifies a party for its own discriminatory acts "is contrary to public policy and void" (section 6-1-1707(7)(a)).

Read together, those rules reward a precise statement of intended and prohibited uses and punish a vague one. The provisions that leave a customer's off-label use with the customer apply only where the developer "complied with section 6-1-1702". The documentation is the price of that protection.

Compliance and legal teams will find that the review duty lands on the customer but its definition describes a product. "Meaningful human review" means a trained reviewer with authority to override, who "does not default to the system output" and can see the output's intended use, limitations, input categories and principal factors (section 6-1-1701(15)). If your interface shows only a score, your customer cannot meet the review duty. We covered the design side in designing the confirm step.

Will Colorado actually enforce it?

Colorado's Attorney General has agreed not to enforce the Act for now, under a federal court order of 27 April 2026 that runs until after xAI's injunction bid is decided. The duties still apply from 1 January 2027; only enforcement waits.

The order is a minute order (ECF No. 24) entered by a magistrate judge in X.AI LLC v. Weiser, No. 1:26-cv-01515 (D. Colo.), granting a joint motion the parties filed. It bars the Attorney General from initiating enforcement, "including but not limited to the initiation of an investigation", of SB 24-205 or any law replacing or amending it enacted in the 2026 session. The bar covers violations up to 14 days after the court rules on xAI's preliminary-injunction motion, which xAI must file within 28 days after the AI rules are finally adopted.

SB 26-189 is inside the order, because it replaced SB 24-205 in that session. As written, the bar is tied to when a violation occurs, so it reaches conduct up to that date however late a case is opened. The state's final fiscal note of 8 September 2026 describes the same order more loosely, as lasting until rulemaking is complete and the court rules.

Washington is pushing the same way. On 1 July 2026 the Federal Trade Commission proposed a policy statement on AI accuracy whose announcement says "Colorado's Artificial Intelligence Act, for instance, appears to coerce companies into altering the output of their AI models to comply with and advance the state's ideological objectives." That is a proposed position, not a ruling, and the rewritten law has already dropped the reasonable-care duty the DOJ attacked.

When enforcement does start, the mechanics are modest. A violation is a deceptive trade practice, with a civil penalty of up to $20,000 per violation (fiscal note, September 2026). The 60-day cure period lasts until 1 January 2030, and it falls away for knowing or repeated violations.

None of this pauses the calendar for vendors. Your Colorado customers owe consumers explanations from 1 January 2027 and cannot give them without your details, so the request will reach you through procurement whatever the court decides. The California Privacy Protection Agency's ADMT rules require businesses that use ADMT to make significant decisions about Californians to comply from 1 January 2027, so expect one questionnaire covering both states.

How does Colorado compare with the EU AI Act and other US state laws?

Colorado regulates disclosure about automated decisions, while the EU AI Act regulates the AI system as a product. The EU reaches a provider in Singapore "where the output produced by the AI system is used in the Union" (Regulation (EU) 2024/1689, Article 2) and requires risk management for high-risk systems, which apply from 2 December 2027 under the Digital Omnibus, Regulation (EU) 2026/1744.

The overlap is partial. Hiring and credit-scoring tools are high-risk under the EU's Annex III and consequential under Colorado's Act. An EU technical file will cover most of Colorado's developer pack. It will not supply the Colorado-specific pieces: per-customer update notices, the version mapping a deployer needs for a 30-day explanation, or the intended-use language that decides your share of fault.

The reverse fails. A Colorado pack falls far short of an EU conformity assessment. If you already sell into Europe, our guide to what the EU AI Act asks of Singapore SMEs sets out the live duties.

Other US laws target different firms. Pick your market.

Most summaries miss one shared date. Colorado's Act, California's ADMT rules and New York's RAISE Act compliance all land in January 2027. For a vendor whose US customers hire, lend or insure, the first quarter of 2027 is when the questionnaires arrive.

Where Origin Pi stands

Colorado's rewrite leaves vendors in Asia with a duty of evidence. Can you show what your system is for and what it is not for, which version touched which decision, and that a person with real authority could override it? Those are architecture questions before they are legal ones.

That is the part we work on. We design automation with the evidence built in: an audit trail that ties every output to a model and prompt version, bounded permissions so a tool cannot drift into decisions it was never sold for, and a confirm step where a trained person approves or overrides before a consequential action lands. Whether you are "doing business in Colorado" is a question for your counsel; we do not give legal opinions on it.

Your first action this week: open every product page, sales deck and contract template you use with US customers, and mark each line that says or implies your tool decides who gets hired, lent to, insured or housed. Each marked product needs a documentation pack ready by 1 January 2027. Each unmarked one needs a use policy, and a check of how customers have configured it, to keep it that way. Our AI compliance work starts from that inventory.