TwinEthosRequest access

Law

Colorado ADMT Act (SB26-189)

Colorado Attorney General · Colorado (US-CO) · 4 provisions encoded · verified against the official source as of 2026-08-30.

Informational data, not legal advice. Summaries are TwinEthos's own words and rules have not been reviewed by a lawyer: check the official text before relying on any of it. A guard addresses an item; adding it is not a statement that your code meets any law.

Official text: leg.colorado.gov.

Binding law — not yet in force or stayed Stayed

Adverse ADMT outcomes require a 30-day plain-language explanation

C.R.S. 6-1-1704(3) · official text · Enacted but stayed: would apply from 1 Jan 2027 · Colorado (US-CO)

When covered ADMT materially influences a consequential decision that results in an adverse outcome, the deployer must, within 30 days, give a plain-language description of the decision and the ADMT's role, instructions to request more information (ADMT name/version/developer, data categories), and an explanation of consumer rights. Detect an adverse-outcome path with no explanation artifact.

Who it applies to

  • Duty falls on: deployer
  • Systems covered: automated decision, consequential decision
  • Sectors: employment, insurance, lending, housing, healthcare, education, essential services
  • Deployers in Colorado whose covered ADMT materially influences a consequential decision producing an adverse outcome for a consumer. Effective 2027-01-01; enforcement stayed.
  • Whether it applies depends on facts outside the code; a person has to decide.

The guard to add

Send each adverse AI-assisted decision with its main reasons and the AI's role, plus a way to correct data and appeal to a human who can change the outcome.

Where model output becomes an adverse status (denied, declined, rejected, ineligible), the decision service stores reason codes or principal reasons, the model id and version, and an input snapshot or hash with the decision. The notice to the person (letter, email, portal response) says AI was involved and what role it played, lists the main factors, and links to data correction and to an appeal that creates a human-review task with authority to change the outcome. An explanation endpoint returns the stored record on request, so the deployer can explain a decision long after the model has changed.

Where it goes: 2 data models, 9 AI output handling, 14 user-facing text.

What this provision adds:

  • Give the explanation within 30 days of the adverse outcome: a plain-language description of the decision and the ADMT's role, and an explanation of consumer rights.
  • Include instructions to request more information: the ADMT's name, version and developer, and the data categories used.

Example (Python + OpenAI SDK + Pydantic), before:

resp = client.chat.completions.create(model=MODEL, messages=msgs)
if 'deny' in resp.choices[0].message.content.lower():
    application.status = 'denied'
    send_email(applicant.email, 'Your application was declined.')

After:

a = Assessment.model_validate_json(resp.choices[0].message.content)   # decision, reason_codes
if a.decision == 'deny':
    decisions.insert(app_id=application.id, status='denied', reason_codes=a.reason_codes,
                     model=resp.model, input_hash=hashlib.sha256(payload).hexdigest())
    send_email(applicant.email, render('adverse_action_notice.txt',
        reasons=a.reason_codes,
        role_of_ai='An AI model assessed your application; a reviewer can change the outcome.',
        correct_data_url='/profile/data', appeal_url=f'/appeals/new?decision={application.id}'))

Control: Adverse AI decision without explanation/appeal. The same guard addresses 6 items with binding law in 2 jurisdictions. Engineering guidance, not legal advice.

Standards that recommend the same control

Related incidents

  • UnitedHealth nH Predict claim-denial litigation (2023-11; alleged (not proven)). A class action filed in November 2023 alleges that UnitedHealth's nH Predict model had a 90% error rate, measured by denials reversed on appeal, while only about 0.2% of members appealed. UnitedHealth disputes the allegations; the litigation is ongoing. Source: STAT News · evidence grade: primary · cited by Explain adverse AI-assisted decisions and offer a way to contest them — everywhere

Rule id co-sb26-189.adverse-outcome-explanation · review status: primary source derived

Binding law — not yet in force or stayed Stayed

Deployers must give point-of-interaction notice when covered ADMT influences a consequential decision

C.R.S. 6-1-1704(1) · official text · Enacted but stayed: would apply from 1 Jan 2027 · Colorado (US-CO)

Before a deployer uses covered automated decision-making technology (ADMT) to materially influence a consequential decision, it must give the consumer a clear and conspicuous notice that ADMT was/will be used, plus instructions to obtain more information. Detect a consequential-decision path invoking ADMT with no consumer-notice step.

Who it applies to

  • Duty falls on: deployer
  • Systems covered: automated decision, consequential decision
  • Sectors: employment, insurance, lending, housing, healthcare, education, essential services
  • Deployers doing business in Colorado using covered ADMT to materially influence consequential decisions about Colorado consumers (incl. employees and job applicants). Effective 2027-01-01; enforcement stayed pending litigation.
  • Whether it applies depends on facts outside the code; a person has to decide.

The guard to add

Send the person an AI-use notice on the decision path, before or when an AI system makes or substantially factors a consequential decision about them, and record its delivery.

A notice step in the decision workflow itself (application intake, underwriting, eligibility, applicant or employee scoring, diagnostic support) that runs before the model call, e.g. send_admt_notice(consumer) ahead of underwrite(), or a notice block rendered on the intake page the person submits from. The notice says that AI is used in the decision, for what, and how to get more information or ask for review, and its delivery is stored with the decision (notice id, channel, timestamp). The template lives in the repo so its content is reviewable; a privacy-policy paragraph alone is not on the decision path.

Where it goes: 1 application source code, 9 AI output handling, 14 user-facing text.

What this provision adds:

  • The notice is clear and conspicuous, says covered ADMT was or will be used, and includes instructions to obtain more information.
  • Consumers here include employees and job applicants, so employment decision paths need the notice too.

Example (FastAPI + OpenAI SDK), before:

@app.post('/applications')
def apply(app_in: Application):
    resp = client.chat.completions.create(model=MODEL, messages=underwriting_prompt(app_in))
    return {'decision': underwrite(resp.choices[0].message.content)}

After:

@app.post('/applications')
def apply(app_in: Application):
    notice = send_admt_notice(app_in.applicant_id, template='ai_decision_notice_v2')
    resp = client.chat.completions.create(model=MODEL, messages=underwriting_prompt(app_in))
    decision = underwrite(resp.choices[0].message.content)
    db.decisions.insert(app_in.id, decision, notice_id=notice.id)
    return {'decision': decision, 'ai_notice': notice.text}

Control: Consequential AI decision without consumer notice. The same guard addresses 6 items with binding law in 5 jurisdictions. Engineering guidance, not legal advice.

Standards that recommend the same control

Rule id co-sb26-189.consumer-notice-consequential-decision · review status: primary source derived

Binding law — not yet in force or stayed Stayed

Developers of covered ADMT must document intended uses, training data, and limitations for deployers

C.R.S. 6-1-1702(1) · official text · Enacted but stayed: would apply from 1 Jan 2027 · Colorado (US-CO)

Developers of covered ADMT must make available to each deployer documentation covering intended and harmful uses, categories of training data (incl. personal data), known limitations and risks, human-review instructions, and information the deployer needs to meet its own disclosure duties. Detect a covered-ADMT codebase with no deployer-facing documentation artifact.

Who it applies to

  • Duty falls on: developer
  • Systems covered: automated decision, consequential decision
  • Sectors: employment, insurance, lending, housing, healthcare, education, essential services
  • Developers doing business in Colorado that make covered ADMT commercially available for use in consequential decisions. Effective 2027-01-01; enforcement stayed.

The guard to add

Ship a deployer-facing model card or deployer guide with each ADMT release covering intended uses, training-data categories, limitations, and human-review instructions.

A deployer-facing documentation artifact versioned with the decision system, such as MODEL_CARD.md or docs/deployer-guide.md (or a Hugging Face model card README with Uses, Bias, Risks, and Limitations, and Training Data sections). It states what the system is for, the categories of data it was trained on, its known limitations and risks, and how a deployer should monitor it and carry out meaningful human review of its outputs. A CI or release step checks that the file exists, carries each of those sections, and names the version being shipped, so a release cannot go out with missing or stale documentation.

Where it goes: 12 repository artifacts, 14 user-facing text, 11 CI/CD pipeline.

What this provision adds:

  • Cover known harmful or inappropriate uses alongside intended uses, and list training-data categories including any personal data.
  • Make the documentation available to each deployer and include the information the deployer needs to meet its own disclosure duties.
  • For deployers' notices, state the ADMT name, version, developer, and data categories.

Example (MODEL_CARD.md), before:

# Tenant Screening Scorer
Install with `pip install screener` and call `score(applicant)`.

After:

# Tenant Screening Scorer
Version: 2.3.0  Developer: Example Analytics
## Intended uses
Ranks rental applications for a leasing agent to review. Not for automatic denial.
## Training data
Categories: rental payment history, income verification, eviction filings (personal data).
## Known limitations
Less accurate for applicants with thin credit files; not validated outside the US.
## Human review
Agents see the top factors per score and must review every score below 40 before acting.

Control: Covered ADMT without developer documentation to deployers. The same guard addresses 1 item with binding law in 1 jurisdiction. Engineering guidance, not legal advice.

Rule id co-sb26-189.developer-documentation-to-deployers · review status: primary source derived

Binding law — not yet in force or stayed Stayed

Consumers can request human review and data correction after an adverse ADMT decision

C.R.S. 6-1-1705(1) · official text · Enacted but stayed: would apply from 1 Jan 2027 · Colorado (US-CO)

After an adverse outcome from a covered-ADMT-influenced consequential decision, the deployer must, on request, provide a way to access and correct factually inaccurate personal data and an opportunity for meaningful human review and reconsideration (to the extent commercially reasonable). Detect an adverse-outcome ADMT path with no correction or human-review affordance.

Who it applies to

  • Duty falls on: deployer
  • Systems covered: automated decision, consequential decision
  • Sectors: employment, insurance, lending, housing, healthcare, education, essential services
  • Deployers in Colorado whose covered ADMT materially influences an adverse consequential decision. Effective 2027-01-01; enforcement stayed.
  • Whether it applies depends on facts outside the code; a person has to decide.

The guard to add

Give people who receive an adverse AI-influenced decision a way to see and correct the data used and to request human review that can change the outcome.

Built into the adverse-outcome path: when a decision is adverse, the system saves the personal-data inputs the model used with the decision, and the letter or screen that communicates it links to two routes. A data access and correction route (GET/PATCH /me/data, correct_input_data) shows those inputs and accepts corrections of inaccurate data, which send the decision back for re-run or review; a reconsideration route (POST /decisions/{id}/reconsideration, request_human_review) places the case in a review queue where a reviewer with authority to change the outcome records reviewer_id and override_reason.

Where it goes: 1 application source code, 9 AI output handling, 15 agent action surface, 2 data models.

What this provision adds:

  • On request after an adverse outcome, provide correction of factually inaccurate personal data and meaningful human review and reconsideration, to the extent commercially reasonable.

Example (FastAPI), before:

if result['decision'] == 'denied':
    applications.save(app_id, status='denied')
    send_email(applicant.email, render('denial.txt', applicant=applicant))

After:

if result['decision'] == 'denied':
    applications.save(app_id, status='denied', inputs_used=features, model_version=MODEL_VERSION)
    send_email(applicant.email, render('denial.txt', applicant=applicant,
               data_url=f'{BASE}/me/data', review_url=f'{BASE}/decisions/{app_id}/reconsideration'))

@app.patch('/me/data')
def correct_input_data(fix: DataCorrection, user=Depends(current_user)):
    corrections.create(user_id=user.id, field=fix.field, value=fix.value)
    review_queue.enqueue(user.latest_decision_id, reason='data_corrected')

@app.post('/decisions/{decision_id}/reconsideration')
def request_human_review(decision_id: str, user=Depends(current_user)):
    review_queue.enqueue(decision_id, reason='consumer_request')   # reviewer can change the outcome

Control: No human review/data-correction path after adverse ADMT decision. The same guard addresses 2 items with binding law in 1 jurisdiction. Engineering guidance, not legal advice.

Standards that recommend the same control

Related incidents

No guardrail sits on this exact control; these incidents are cited by guardrails on related controls.

Rule id co-sb26-189.human-review-and-data-correction · review status: primary source derived