Your Colorado AI Act Duties Are Non-Delegable. The Evidence Isn't Yours.
That asymmetry is the entire procurement problem. You owe the impact assessment, the consumer notice, and the adverse-decision explanation — and almost everything you need to produce them lives inside a vendor's system you cannot see. Renewal is when you fix it.
Why Procurement Is Where This Law Actually Lands
The Colorado AI Act splits duties between developers, who build high-risk AI systems, and deployers, who use them. Our Colorado AI Act compliance guide walks through what each role owes. This piece is about the gap between those two lists, because that gap is where most companies will actually fail.
A deployer must complete impact assessments, notify consumers before a consequential decision, explain adverse decisions with the principal reasons and the degree of the system's contribution, support correction and appeal, and exercise reasonable care against algorithmic discrimination. Every one of those obligations requires facts about a system the deployer did not build: how it works, what data categories it processes, how it was evaluated, what its known limitations are, and how it behaved on your own population.
So the compliance program is only as good as the contract. A deployer with a beautiful governance framework and a vendor agreement that promises nothing will produce an impact assessment full of "vendor did not disclose," which is a document that describes the problem rather than solving it. The leverage to fix that exists at exactly one moment: before you sign or renew.
The Clauses That Actually Do Work
- 1. The documentation package, itemized. Do not accept a general "vendor will provide reasonable documentation." Enumerate: intended uses, known harmful or inappropriate uses, categories of data used to train and evaluate, summary evaluation results including any performance differences across groups, known limitations, and the mitigation measures in place. These track the developer-side disclosures the Act contemplates, which makes them a reasonable ask rather than an aggressive one.
- 2. Impact assessment support. A commitment to provide the vendor's own assessment and to answer written diligence questions within a defined period. Tie it to your annual cadence so the support arrives when you need it rather than on request.
- 3. Advance notice of material modification. The clause that most agreements get exactly backwards. Carve model behavior changes out of the vendor's general right to modify the service, and require notice with enough lead time to reassess.
- 4. Outcome data access. Row-level or sufficiently granular results for your own deployment, not an aggregate dashboard. You cannot run a disparity analysis on a summary statistic, and a vendor-supplied fairness score computed on the vendor's population tells you nothing about yours.
- 5. Cooperation with testing and audit. Including the right to run or commission bias testing, and a commitment not to treat that testing as a breach of the acceptable use policy — a real trap in agreements that prohibit probing or benchmarking.
- 6. Explanation support for adverse decisions. If you must tell a consumer the principal reasons a decision went against them, you need per-decision reason codes from the system. Confirm the product actually emits them before you assume the clause is achievable.
- 7. Regulatory cooperation. An obligation to support you in responding to an Attorney General inquiry, with a defined response window.
- 8. Discrimination indemnity, or an honest allocation. If the vendor will not indemnify for discrimination claims arising from the system's design, that is a legitimate commercial position — but you should know it, price it, and stop treating the marketed IP indemnity as coverage it is not.
Reading the Indemnity Honestly
AI vendor indemnities became a marketing feature during the generative AI wave, and the version that got the attention covers copyright claims arising from model output. That is a real benefit and it is not the risk a deployer of a high-risk decision system carries.
Read the exclusions. The recurring pattern is an indemnity that applies to the output as delivered but excludes claims arising from the customer's use of that output to make decisions about individuals, or that conditions coverage on the customer having followed usage guidelines that are broad enough to be unfollowable. Both exclusions land precisely on the deployer scenario.
You will not always win this point, and with a large vendor you usually will not. The value of raising it is not the clause; it is that the answer tells you where the risk actually sits before you build a business process on top of it. A deployer who knows the discrimination risk is uninsured makes different choices about human review than one who assumed otherwise.
Questions To Put in the RFP
Diligence questions get better answers when they are specific enough that a vendor cannot answer with a compliance brochure. These are the ones that separate vendors who have done the work from vendors who have written about it.
- Which of our deployer obligations does your product help us evidence, and through which specific feature or artifact?
- Does the system emit per-decision reason codes suitable for an adverse-decision explanation? Show us a sample.
- What outcome data can we extract, at what granularity, and through what interface?
- Have you evaluated the system for performance differences across demographic groups? On what population, using which metrics, and will you share the results under NDA?
- How will we learn that the model has materially changed, and how much notice will we get?
- Does your acceptable use policy permit us to independently test the system for disparate outcomes?
- Which claims does your indemnity exclude? Point us at the exclusion list rather than the summary.
- Have you produced an impact assessment we can rely on, and will you keep it current?
The Leverage Problem, Realistically
A 300-person company is not going to redline a major platform's standard terms. That is true and it does not make this exercise pointless, for two reasons.
First, most high-risk AI in the mid-market does not come from the largest vendors. It comes from specialist tools in hiring, lending, screening, and benefits administration, sold by companies of comparable size to their customers, who negotiate. Those are the systems in scope, and those contracts are winnable.
Second, where you genuinely cannot negotiate, the diligence still pays. Documenting that you asked, recording what the vendor would and would not provide, and adjusting your own controls to compensate — more human review, tighter monitoring, a narrower deployment — is itself evidence of reasonable care. The standard asks what a reasonable company in your position would do, and a reasonable company with limited leverage compensates rather than pretending the gap does not exist.
Frequently Asked Questions
We already signed a multi-year agreement with none of this. Are we stuck until renewal?
Not entirely. Most agreements have amendment mechanics, and vendors are frequently willing to add a compliance addendum mid-term because it costs them little and helps them sell to the next customer with the same concern. Ask for the documentation package as a standalone deliverable rather than a contract change — many vendors will simply provide it. Where you get nothing, document the request and the refusal, and compensate through your own controls.
Does an existing DPA cover any of this?
Partially and incidentally. A data processing agreement addresses privacy obligations — purpose limitation, security, subprocessors, transfer mechanics — and those overlap with the data-handling edges of an AI deployment. It says nothing about evaluation results, disparity testing, model change notice, reason codes, or discrimination indemnity. Treat the AI terms as a distinct addendum rather than assuming the privacy paper reached them.
Should we require a specific framework like NIST AI RMF or ISO/IEC 42001 in the contract?
Referencing a recognized framework is useful and increasingly common, and the Act's presumption mechanics point at framework alignment. But a certification is not a substitute for the specific deliverables above — a vendor can be aligned to a governance standard and still refuse to give you outcome data. Ask for the framework alignment and the itemized artifacts. The first tells you about their process maturity; the second is what you actually file.
Our tool is one feature inside a larger platform we cannot replace. What is the realistic move?
Separate the compliance question from the procurement question. Determine whether that feature is a substantial factor in a consequential decision — often it is not, and the analysis ends there in writing. If it is, and you cannot obtain what you need from the vendor, your remaining levers are on your side of the line: increase the weight of human review so the system is no longer the substantial factor, restrict the feature's use for Colorado decisions, or turn it off for the affected workflow. Those are legitimate answers and worth documenting as deliberate choices.
How do we handle a vendor that claims their system is not high-risk?
Ask them to say it in writing with reasoning, then form your own view. The classification depends on how you use the system, which the vendor does not fully know — the same screening tool is out of scope for one customer's internal workflow and squarely in scope for another's hiring funnel. A vendor's assurance is useful evidence of what they intended, and it is not a determination you are entitled to rely on. The classification is yours to make and yours to defend.
Put the Renewal Dates on the Compliance Calendar
The practical starting move is not a policy. It is a two-column list: every AI system that touches a consequential decision, and the date its agreement comes up for renewal. That list tells you when each negotiation window opens, and it is the only artifact that converts this into scheduled work rather than an intention.
Ninety days before each renewal, send the diligence questions above. The answers will resolve whichever of your impact assessments currently reads "vendor did not disclose" — and where a vendor will not answer, you will have learned something worth knowing well before the regulator asks you the same question.