Colorado’s AI Act: the Impact Assessment Requirement

The impact assessment is the deployer’s central artefact under Colorado’s AI Act, and the element most often described as a filing. It is not a filing. Nothing is submitted to anyone unless it is asked for, and the obligation does not end when the document is finished, because two separate triggers restart it.

Who owes one, and who does not

The obligation sits on a deployer of a high-risk artificial intelligence system, in the deployer duties section of Part 17 of Article 1 of Title 6 of the Colorado Revised Statutes, enacted by Senate Bill 24-205 — see the Colorado General Assembly’s bill page. A system is high-risk if, when deployed, it makes or is a substantial factor in making a consequential decision: one with a material legal or similarly significant effect on the provision, denial, cost or terms of education enrolment or opportunity, employment or an employment opportunity, a financial or lending service, an essential government service, health-care services, housing, insurance, or a legal service.

Two boundaries do most of the filtering. First, the statute excludes a list of technologies that perform narrow procedural tasks — anti-malware, calculators, databases, firewalls, networking, spam filtering, spell-checking, spreadsheets, web caching and hosting, and similar — unless the technology makes a consequential decision. It also excludes technology that communicates with consumers in natural language to provide information, make referrals or recommendations and answer questions, where it is subject to an acceptable use policy prohibiting discriminatory content, again unless it makes a consequential decision. A general chatbot is not high-risk because it is a chatbot; it becomes high-risk when it decides something.

Second, there is a small-deployer exemption. A deployer with fewer than fifty full-time equivalent employees is relieved of the impact assessment obligation and of the risk-management-programme obligation if it does not use its own data to train the system, uses the system for the intended uses disclosed by the developer, and makes available to consumers any impact assessment the developer has provided. Note the shape: it is not a size exemption alone. Fine-tuning on your own data takes you out of it.

What it has to contain

The statute enumerates the contents. Paraphrasing the required elements, an assessment must include:

• a statement of the purpose, intended use cases and deployment context of, and benefits afforded by, the system;
• an analysis of whether deployment poses any known or reasonably foreseeable risks of algorithmic discrimination and, if so, the nature of the risk and the steps taken to mitigate it;
• a description of the categories of data the system processes as inputs and the outputs it produces;
• if the deployer used its own data to customise the system, an overview of the categories of data used to do so;
• any metrics used to evaluate performance and known limitations of the system;
• a description of the transparency measures taken, including any measures taken to disclose to a consumer that the system is in use;
• a description of the post-deployment monitoring and user safeguards provided, including the oversight, use and learning process established to address issues arising from deployment.

Read as a set, these are the elements of a justification rather than a description. The second and the last are where assessments fail review. “No risks identified” against a hiring or lending system is not an analysis and does not sustain the presumption of reasonable care that the duty-of-care section offers — see what reasonable care asks for. And the monitoring element asks for a live process with an owner, not an intention to monitor.

The elements about inputs, outputs, metrics and known limitations map closely onto what the developer must hand you under the developer duties section. That is by design: the developer’s disclosure is the raw material for the deployer’s assessment, and a deployer who never received it has a documentation problem before it has a discrimination problem.

The two triggers that make it recurring

The assessment must be completed annually, and additionally within ninety days after any intentional and substantial modification to the system is made available. Two independent clocks, and the second is the one that catches people.

“Intentional and substantial modification” is defined in the statute as a deliberate change that materially increases the risk of algorithmic discrimination. A vendor shipping a new model version under the same product name can be exactly that, and the deployer does not always find out on the day. Practically this means a deployer needs contractual notice of model changes from its supplier, and a defined internal path from that notice to a reassessment inside ninety days. The clock runs from when the modification is made available, not from when you noticed it.

The assessment that follows a modification must additionally state the extent to which the system was used in a manner consistent with, or varied from, the developer’s intended uses. That is a pointed requirement: using a system outside its documented intended use is one of the routes out of the developer’s disclosures and into your own exposure.

Retention, and who gets to read it

The deployer must maintain the most recently completed assessment, all records concerning it, and prior assessments, for at least three years following the final deployment of the system. Nothing is filed routinely: the Attorney General may require disclosure of an assessment on request, and the statute contemplates a short window to produce it, which is a strong argument for keeping these in a form that can be produced rather than reconstructed.

Because the Act creates no private right of action and vests enforcement in the Attorney General alone, the assessment is not discoverable through a consumer suit under this Act. It is not privileged, however, and it may be reachable in litigation under other statutes. Whether to route the risk analysis through counsel is a real decision with real trade-offs, and it is one to take before the first assessment rather than after.

Reusing an assessment you already have

The statute permits a single assessment to cover a set of comparable systems, and it accepts an assessment completed for the purpose of compliance with another law or regulation, provided it is reasonably similar in scope and effect to what the Act requires. That is the provision that makes this obligation survivable for a company already doing this work elsewhere.

The obvious candidate is the fundamental rights impact assessment under Article 27 of the EU AI Act, which covers overlapping ground — see what Article 27 requires — and, for personal-data processing, a GDPR data protection impact assessment. Neither maps one-to-one. A DPIA is organised around risks to data subjects from processing and will not naturally contain the metrics and known-limitations elements. An Article 27 FRIA is closer but is scoped by the AI Act’s own high-risk classification, which is not the Colorado one. The workable approach is one underlying evidence base — purpose, inputs, outputs, testing, mitigations, monitoring — with a mapping document showing where each regime’s required element is satisfied, rather than one document pretending to be three.