EU AI Act vs Colorado AI Act

What the obligation asks for

On the EU side, Art. 9 requires the provider of a high-risk AI system to establish, implement, document and maintain a risk management system that runs as a continuous iterative process through the lifecycle, and Art. 9(8) requires testing against prior defined metrics and probabilistic thresholds before placing on the market. Art. 26 requires the deployer to use the system in accordance with the instructions for use (Art. 26(1)), to assign human oversight to natural persons with competence, training, authority and support (Art. 26(2)), to monitor operation and suspend use where a risk within the meaning of Art. 79(1) appears (Art. 26(5)), to keep the logs under its control for at least six months (Art. 26(6)) and to inform natural persons subject to a decision (Art. 26(11)). Both duties attach to a system that is high-risk under Art. 6(2) with Annex III from the Annex III application date 2027-12-02Deferred; the Art. 26 record states that Regulation (EU) 2026/1744 did not change the content of Art. 26, and the Art. 9 record lists the same application entries. The testable elements this guide touches are the Art. 9(8) test against prior defined thresholds, the Art. 26(1) fit between the deployed configuration and the instructions for use, the Art. 26(2) oversight assignment and the Art. 26(6) retention configuration; the guide maps them, and the protocols named on each obligation page test them.

On the Colorado side, the object of comparison is Part 17 of article 1 of title 6 of the Colorado Revised Statutes, headed "Automated decision-making technology in consequential decisions". The replacement bill, Senate Bill 26-189, repealed and reenacted Part 17 with amendments and replaced the text enacted by Senate Bill 24-205 before that text took effect. Section 5 of the replacement bill sets the effective date and applies Part 17 to consequential decisions made on or after that date; the attorney general adopts implementing rules on or before that date under sections 6-1-1704(4)(b) and 6-1-1705(3). The reenacted Part 17 regulates "covered ADMT" under section 6-1-1701(5): automated decision-making technology as defined in 6-1-1701(2) that is used to materially influence, as defined in 6-1-1701(13), a consequential decision as defined in 6-1-1701(3) in a covered domain listed in 6-1-1701(6). Its duties are documentation from the developer to the deployer (6-1-1702), record keeping (6-1-1702(4) and 6-1-1703), consumer notice and post-adverse-outcome disclosure (6-1-1704), correction and meaningful human review on request (6-1-1705), and exclusive enforcement by the attorney general under the Colorado Consumer Protection Act (6-1-1706). The duty of reasonable care against algorithmic discrimination, the risk management policy and program, the impact assessment, the rebuttable presumption for a recognised risk management framework and the notification of discovered discrimination to the attorney general, all present in the text enacted by Senate Bill 24-205, do not appear in the reenacted Part 17. Where a row below says the Colorado side has no counterpart, that is the reason.

Inputs

The inputs are the subset of the PR-CLS v1.0 input table that the role and Annex III steps use, plus the Colorado-side materials. The full table is on the protocol page.

• The intended-purpose statement, instructions for use, marketing materials and terms of service, one entry per material.
• The function inventory: each function with its inputs, its outputs and the natural persons it affects.
• The list of places where the system is supplied and where its output is used, per function.
• The contracts, configuration records and licence terms that state the use each customer bought, which section 6-1-1702(3) and 6-1-1707(5) make decisive on the Colorado side.
• The developer documentation supplied to deployers, matched against section 6-1-1702(1)(a) to (e), where the organisation deploys a system built by another.
• The notice text shown to consumers before a decision and the post-adverse-outcome disclosure text, where one exists.
• The Art. 6(3) assessment document, where a not-high-risk conclusion is claimed.
• A shell with python and the pyyaml package for the crosswalk check.

Procedure

The procedure is a decision sequence. Each step names the protocol step or the clause it derives from and the record it produces. Every system name, identifier and value in the examples is synthetic.

1. Record the system name, version, developing organisation, place of establishment and the places where each function's output is used.

   Record System identification record with a market list per function

   [AIAssuranceLabs procedure; PR-CLS step 1]

2. Check whether the system is placed on the Union market or its output is used in the Union.

   Record Territorial scope record, EU side

   [Regulation (EU) 2024/1689, Art. 2(1)(a) and (c); PR-CLS step 11]

3. Check whether the organisation does business in Colorado and evaluates a consumer whose opportunity in Colorado is decided.

   Record Territorial scope record, Colorado side

   [C.R.S. 6-1-1701(4)(b), (7) and (8)]

4. Test the provider and deployer definitions and each Art. 25(1) trigger against the organisation's relation to the system.

   Record Role determination record, EU side

   [Regulation (EU) 2024/1689, Art. 3(3), 3(4) and Art. 25(1); PR-CLS steps 8 to 10]

5. Test the developer definition, its three exclusions, the deployer definition and the intentional and substantial modification rule.

   Record Role determination record, Colorado side

   [C.R.S. 6-1-1701(7), (8) and (12)]

6. Match each function against Annex III and test the four Art. 6(3) conditions and the profiling rule.

   Record Annex III matching record and Art. 6(3) condition record, one row per function

   [Regulation (EU) 2024/1689, Art. 6(2), Annex III, Art. 6(3); PR-CLS steps 13 to 16]

7. Test each function against the ADMT definition, the consequential decision definition, the covered domain list and the materially influence test.

   Record Covered ADMT record, one row per function

   [C.R.S. 6-1-1701(2), (3), (5), (6) and (13)]

8. Fill the crosswalk: name the counterpart section or article for each row on each side, or record none.

   Record Crosswalk, one row per obligation element with a section or the value none on each side

   [AIAssuranceLabs procedure]

9. Compile the obligation register per role, with a regulation entry id per EU date and the bill section per Colorado date.

   Record Obligation register with a regulation entry id per EU date and the replacement bill section for the Colorado date

   [AIAssuranceLabs procedure; PR-CLS step 39]

10. Record the justification for each open judgement: the Art. 6(3) condition claimed and the non-de minimis factor under 6-1-1701(13).

    Record Determination rationale record, one entry per open judgement

    [AIAssuranceLabs procedure; PR-CLS step 40]

11. Mark every determination on both sides as a technical assessment for discussion with counsel.

    Record Counsel note on each determination

    [AIAssuranceLabs procedure; PR-CLS step 43]

Example for step 8. The mapping table below is the crosswalk in Markdown, one row per topic, with the article on the EU side and the section of the reenacted Part 17 on the Colorado side. The relation column has three values: partial, where both sides regulate the topic with different content; none on the Colorado side; and none on the EU side. Rows for Art. 13, Art. 14, Art. 27, Art. 50 and Art. 86 are included because the decision sequence cannot be run without them; their obligation pages, where one exists, are linked from the obligations index.

Example for step 8, encoded. The YAML file below holds the same crosswalk in a form a script can read. Each row carries the EU article, the obligation page slug where one exists, the Colorado section, the relation and the roles the row applies to. The EU date is the regulation entry id rather than a date, so that the date resolves from the regulation data when the file is read; the Colorado date is the replacement bill section that sets it.

# Synthetic example: crosswalk between Regulation (EU) 2024/1689 and C.R.S. Part 17 as reenacted.
crosswalk_version: 1
eu_date_entry: annex-iii-high-risk
colorado_date_source: "SB 26-189 section 5"
rows:
  - topic: regulated object
    eu: { ref: "Art. 6(2), Annex III", page: null }
    colorado: { ref: "6-1-1701(5)" }
    relation: partial
    roles: [provider, deployer]
  - topic: risk management
    eu: { ref: "Art. 9", page: art-9 }
    colorado: { ref: null }
    relation: eu-only
    roles: [provider]
  - topic: information from provider to deployer
    eu: { ref: "Art. 13(3), Art. 9(5)(c)", page: art-13 }
    colorado: { ref: "6-1-1702(1)(a) to (e), 6-1-1702(2)" }
    relation: partial
    roles: [provider]
  - topic: impact assessment
    eu: { ref: "Art. 27", page: art-27 }
    colorado: { ref: null }
    relation: eu-only
    roles: [deployer]
  - topic: use per instructions
    eu: { ref: "Art. 26(1)", page: art-26 }
    colorado: { ref: null, note: "liability allocation only, 6-1-1707(5) and (6)" }
    relation: eu-only
    roles: [deployer]
  - topic: human oversight or review
    eu: { ref: "Art. 14, Art. 26(2)", page: art-26 }
    colorado: { ref: "6-1-1701(15), 6-1-1705(1)(a)(II)" }
    relation: partial
    roles: [provider, deployer]
  - topic: logs and records
    eu: { ref: "Art. 12, Art. 26(6)", page: art-26 }
    colorado: { ref: "6-1-1702(4), 6-1-1703" }
    relation: partial
    roles: [provider, deployer]
  - topic: notice to the affected person
    eu: { ref: "Art. 26(11)", page: art-26 }
    colorado: { ref: "6-1-1704(1), 6-1-1704(2)" }
    relation: partial
    roles: [deployer]
  - topic: correction of input data
    eu: { ref: null }
    colorado: { ref: "6-1-1705(1)(a)(I)" }
    relation: colorado-only
    roles: [deployer]
  - topic: enforcement
    eu: { ref: "Art. 79, Art. 99", page: null }
    colorado: { ref: "6-1-1706" }
    relation: partial
    roles: [provider, deployer]

Example for step 9. The script reads the crosswalk and the role determined in steps 4 and 5, then prints the rows that exist on one side only, which are the register rows that a matrix built for the other regime cannot answer. Run on the synthetic file above for the role deployer, it prints three lines: impact assessment and use per instructions as EU-only, correction of input data as Colorado-only.

# Synthetic example: list the one-sided rows of the crosswalk for a role.
import sys
import yaml

role = sys.argv[1]  # provider or deployer
with open("crosswalk.yaml", encoding="utf-8") as f:
    crosswalk = yaml.safe_load(f)

for row in crosswalk["rows"]:
    if role not in row["roles"] or row["relation"] == "partial":
        continue
    side = row["eu"]["ref"] if row["relation"] == "eu-only" else row["colorado"]["ref"]
    print(f"{row['relation']:<14} {row['topic']:<32} {side}")

A pitfall that vendor documentation omits

Governance tooling and older briefings map "high-risk" to "high-risk" because the text enacted by Senate Bill 24-205 used the term "high-risk artificial intelligence system". The reenacted Part 17 does not use that term. On the EU side the object is fixed by Art. 6(2) and the list in Annex III; on the Colorado side it is covered ADMT under section 6-1-1701(5), which turns on the materially influence test in 6-1-1701(13) and the covered domain list in 6-1-1701(6). The lists overlap in education, employment, credit, insurance and essential public services, which are Annex III points 3, 4 and 5, and diverge elsewhere: Annex III points 1, 2, 6, 7 and 8 on biometrics, critical infrastructure, law enforcement, migration and justice have no covered domain, while the lease or purchase of residential real estate under 6-1-1701(6)(c) and health-care services under 6-1-1701(6)(f) have no Annex III entry beyond the public healthcare services named in Annex III point 5(a). A recruitment ranking function is inside both; a biometric identification function is inside Annex III only; a tenant screening function is inside Part 17 only. A matrix that carries one "high-risk" column for both regimes records the wrong answer for the second and third function.

The second confusion is "human review". Art. 14 requires the provider to design oversight measures into the system and Art. 26(2) requires the deployer to assign oversight to natural persons before use, which is why the Art. 26 record tests that a stop or override instruction from an assigned person takes effect. Section 6-1-1701(15) defines meaningful human review as a review by a designated individual with authority to approve, modify or override the decision, and section 6-1-1705(1)(a)(II) makes it a right the consumer requests after an adverse outcome, to the extent commercially reasonable. The Colorado review happens after the decision, on request, once; the EU oversight is in place before the first decision and for every decision. A vendor feature described as human-in-the-loop answers neither on its own: the EU side asks whether the assigned person can stop the system in a test, which is the override test in the guide on Article 14 override testing, and the Colorado side asks whether the designated individual considers primary evidence and does not default to the system output under 6-1-1701(15)(a) and (c).

The third confusion is the carve-out. Art. 6(3)(a) removes a system that performs a narrow procedural task, and 6-1-1701(3)(b)(V) excludes narrow procedural tasks that do not generate a prediction about a consumer. The words match and the effect does not: the Art. 6(3) third subparagraph keeps a system high-risk whenever it performs profiling of natural persons, and Part 17 has no profiling rule, so a function that scores applicants on inferred traits fails the EU carve-out and can still fall inside a Colorado exclusion where its output is not a non-de minimis factor. Step 6 and step 7 therefore run separately, and the crosswalk row for carve-outs is partial in both directions.

Neither regime sets a numeric threshold for any determination in this guide. "Non-de minimis factor" in 6-1-1701(13) carries no number; section 6-1-1706(5)(b) lets the attorney general adopt rules with presumptions, illustrative examples and objective indicators, and a rule adopted under it changes the reading. On the EU side, no harmonised standard is cited in the Official Journal as of the anchor date, so no presumption of conformity under Art. 40 is available and the standards page tracks the count; the Art. 6 criteria come from Commission guidelines on high-risk classificationDraft, a Commission guideline at draft stage, and the reasoning is the provider's own, recorded in step 10. The rebuttable presumption that the text enacted by Senate Bill 24-205 attached to a recognised framework such as NIST AI RMF 1.0Published, a published voluntary framework, is not in the reenacted Part 17, so a NIST-structured risk file earns no presumption on either side; it is reusable as Art. 9 evidence only through the mapping that the compliance matrix guide builds.

What the result shows and what it does not

The result is a technical assessment of scope, role and classification against the text of Regulation (EU) 2024/1689, the draft Commission guidelines and the reenacted Part 17. It does not give a legal opinion on classification under either regime, and a market surveillance authority, the AI Office, the Colorado attorney general or a court can reach a different result. The Colorado determinations rest on statutory text whose implementing rules under sections 6-1-1704(4)(b), 6-1-1705(3) and 6-1-1706(5) are adopted by the attorney general, so a determination made before a rule is re-run after it, as the protocol's revision history requires for a change on the EU side. The crosswalk shows where an obligation has a counterpart and where it has none; it does not show that any obligation is met; the tests that show it run under the protocols named on the obligation pages. The result is evidence for the provider's or deployer's own file under Annex IV or under section 6-1-1702(4) and 6-1-1703; the decision remains with the organisation, its notified body where one is required, and its counsel. The risk classifier runs the EU-side triggers on the published logic and stops there: it has no Colorado question set. The classification and readiness assessment service runs PR-CLS v1.0 and delivers the classification memo and the obligation register specified on the deliverables page; its scope limits are on what we cannot do.

Related pages

The two obligations, the protocol, the related guides and the hubs for the two audiences this guide serves are listed below; every protocol on the site is on the methodology index, and the scenario on whether the Act applies to US companies runs the EU-side scope steps in full.

Obligations

• Art. 9
• Art. 26

Protocols

• PR-CLS v1.0

Related guides

• Building an EU AI Act compliance matrix: traceability from obligation to evidence
• Override testing: what AI human oversight under Article 14 looks like in a test

ICP hubs

• Non-EU providers
• Enterprises

Every inquiry receives a reply within 24 hours. Scope and availability are discussed per request.

Ask about scopehello@aiassurancelabs.com