AI Vendor Due Diligence: 12 Questions to Ask Before You Deploy

Why does the buyer own the risk when an AI vendor's tool makes a decision?

Under the Colorado ADMT Act, the business that uses an AI tool to make a consequential decision is the "deployer," and the deployer owes the consumer-facing duties even when a vendor built the tool. Those duties take effect January 1, 2027: a pre-use notice, an adverse-outcome disclosure within 30 days, data access and correction, meaningful human review "to the extent commercially reasonable," and records kept for three years after each consequential decision (C.R.S. §§ 6-1-1703 to -1705). The statute has no small-business exemption.

Several of those duties depend on facts only the vendor knows. The adverse-outcome disclosure must offer information about the tool, including its name, version, developer, and the personal data it used, "to the extent the deployer receives the necessary information from the developer in compliance with section 6-1-1702" (§ 6-1-1704(3)(b)). A human reviewer must be able to understand the output's intended use, material limitations, input categories, and principal factors (§ 6-1-1701(15)(d)). If the vendor never tells you those things, you cannot pass them on.

What does the statute require developers to hand over?

Section 6-1-1702(1) requires a developer to make available to each deployer, in a reasonably understandable form:

• "a general statement describing the intended uses and known harmful or inappropriate uses of the covered ADMT" (§ 6-1-1702(1)(a));
• a description of the categories of data, including personal data, used to train it, "to the extent known" (§ 6-1-1702(1)(b));
• known limitations, including known risks and circumstances in which it should not be used (§ 6-1-1702(1)(c));
• "instructions for the deployer's appropriate use, monitoring, and meaningful human review, where applicable" (§ 6-1-1702(1)(d)); and
• information reasonably necessary for the deployer's disclosures. "If information is withheld, the developer shall notify the deployer" (§ 6-1-1702(1)(e)).

Developers must also send notice of material updates "within a reasonable time" (§ 6-1-1702(2)(a)) and keep records for three years, including "system version identifiers, changelogs" (§ 6-1-1702(4)). There is a catch: these duties apply only where the tool was "marketed, advertised, configured, contracted, sold, or licensed to be used to materially influence a consequential decision" (§ 6-1-1702(3)). If you repurpose a general-purpose tool for hiring or tenant screening, the vendor may owe you nothing, and § 6-1-1707(6) keeps the deployer answerable for its own independent acts, including off-label use where the developer complied with § 6-1-1702.

Can an indemnity clause shift the risk back to the vendor?

Only partly. In discrimination claims arising from a consequential decision materially influenced by covered ADMT, fault is allocated between developers and deployers by relative fault (§ 6-1-1707(2)). A contract clause that indemnifies or holds harmless a developer or deployer for its own acts or omissions in violation of Colorado anti-discrimination law is "contrary to public policy and void" (§ 6-1-1707(7)(a)). Other commercial terms between businesses stay enforceable (§ 6-1-1707(7)(c)), so the contract still matters. It just cannot buy you out of your own conduct.

What if the vendor built its product on someone else's model?

Proposed AG Rule 4.2 addresses this. It would require a "Midstream Developer," meaning a company that integrates covered ADMT, such as a third-party foundation model, into its own product, to reasonably obtain the upstream developer's documentation and to "Make all upstream Developer documentation available to any downstream Deployer or Developer." The rules are proposed, not final; written comments run through October 26, 2026, and the current draft is posted at coag.gov/ai.

What are the 12 questions to ask an AI vendor before you deploy?

Ask these in writing and keep the answers. Each one lists why it matters, what a good answer looks like, and the FAIIR control the answer helps evidence. Where the answer is "no" or "we don't know," that is still useful: it tells you to restrict the use case or keep the tool out of consequential decisions.

1. What is this tool intended for, what uses should we avoid, and what are its known limitations?

• Why it matters: This is the core of § 6-1-1702(1)(a) and (c), and your out-of-scope rules depend on it.
• Good answer looks like: A written statement naming the decision types the tool is built for, the uses it should not be put to, and known failure conditions.
• FAIIR control: Developer documentation; feeds F2 — Out-of-Scope Boundaries.

2. What categories of data, including personal data, were used to train it?

• Why it matters: § 6-1-1702(1)(b) requires this "to the extent known," and it tells you whether the training data resembles your population.
• Good answer looks like: Named data categories and sources at a level a non-engineer can follow, with gaps stated rather than hidden.
• FAIIR control: Developer documentation.

3. What are your instructions for monitoring the tool and for meaningful human review?

• Why it matters: § 6-1-1702(1)(d) requires them, and your reviewer needs the output's principal factors to satisfy § 6-1-1701(15)(d).
• Good answer looks like: Written monitoring steps and a way for a reviewer to see the main factors behind a specific output, without source code or model weights.
• FAIIR control: Developer documentation; feeds F5 — Human-in-the-Loop Defined.

4. Will you give us what we need for adverse-outcome disclosures, and tell us if you withhold anything?

• Why it matters: Your 30-day disclosure under § 6-1-1704(3) needs the tool's name, version, developer, and the types and sources of personal data used.
• Good answer looks like: A disclosure data sheet per version, plus a commitment to notify you, with the reason, if any item is withheld.
• FAIIR control: Developer documentation (§ 6-1-1702(1)(e)).

5. Do you build on third-party models, and will you pass their documentation through?

• Why it matters: Proposed Rule 4.2 would make pass-through expected; without it, you are blind to the layer doing the work.
• Good answer looks like: A list of upstream models and providers, and copies of or links to their developer documentation.
• FAIIR control: Developer documentation; F6 — Model/Version Tracking.

6. How will you notify us of material updates, and how can we tell which version produced a given output?

• Why it matters: § 6-1-1702(2) requires update notices, and your own records "may include" version identifiers and changelogs (§ 6-1-1703).
• Good answer looks like: Direct notice of material updates (public release notes plus a direct notice to you is allowed under § 6-1-1702(2)(b)) and a version stamp on outputs or logs.
• FAIIR control: F6 — Model/Version Tracking.

7. Will you sign a data processing agreement that covers the personal data we submit?

• Why it matters: Covered ADMT processes personal data by definition. Without a DPA, you have no written limits on what the vendor does with it.
• Good answer looks like: A DPA, current terms of service, and a security addendum you can review and file before go-live.
• FAIIR control: A3 — Vendor Contract Review; I3 — No-PII Default.

8. Who is liable for what, and does your indemnity survive § 6-1-1707?

• Why it matters: Indemnity for a party's own discriminatory acts is void, so you need to know what protection actually remains.
• Good answer looks like: A plain summary of indemnity scope, liability caps, and carve-outs, reviewed by your counsel against § 6-1-1707.
• FAIIR control: A4 — Liability Allocation Understood.

9. Do you train on our inputs or outputs, and how do we opt out?

• Why it matters: Many tools train on customer inputs by default, which can move your applicants' or patients' data into someone else's model.
• Good answer looks like: Training off by default for business accounts, or a documented opt-out you can configure and screenshot.
• FAIIR control: I4 — Training Data Opt-Out.

10. How long do you keep our inputs, outputs, and logs?

• Why it matters: You need three years of decision records yourself, but you may not want the vendor holding raw personal data that long.
• Good answer looks like: Stated retention periods per data type and a way to change them.
• FAIIR control: I5 — Retention Terms Documented.

11. Where is our data stored and processed, and by which subprocessors?

• Why it matters: Location and subprocessors affect which privacy regimes apply and who else touches your data.
• Good answer looks like: Named hosting regions, a current subprocessor list, and notice before changes.
• FAIIR control: I6 — Export Controls (data location).

12. What happens when we leave, or when you go down or retire the model?

• Why it matters: A deprecated model or an outage can stall decisions you are still obligated to explain, and leftover data is leftover risk.
• Good answer looks like: Export of your records, written confirmation of deletion on exit, and advance notice of deprecations and pricing changes.
• FAIIR control: I9 — Secure Deletion Confirmed; R5 — Vendor Uptime & Failure Plan.

How do you score a vendor's answers?

Score each question pass or fail. One red flag does not have to end the deal, but it should change what you let the tool do. Record the result next to the tool's entry in your use-case register.

What should you do with the answers?

File them where you can find them in three years. Re-ask questions 1 through 6 whenever the vendor sends a material-update notice, and all 12 at least annually. If a vendor cannot answer the documentation questions, keep the tool to uses that fall outside the Act, such as tools used solely to summarize, organize, translate, draft, route, or present information for human review of administrative processing (§ 6-1-1701(2)(b)(II)), and write that limit into your policy. For a wider checklist of deployer duties, see the Colorado ADMT Act compliance checklist; for building the surrounding program, see an AI governance framework for small businesses. Contract negotiation is legal work, so talk to counsel about your specific agreements.

Where FAIIR fits

The FAIIR standard, published by FAIIR, LLC, turns vendor diligence into evidence: A3, A4, I3 through I6, I9, F6, and R5 are pass/fail controls among the 41 in the framework, benchmarked to the NIST AI Risk Management Framework. Colorado law does not require, create, or recognize any third-party AI certification; a FAIIR certification is documented proof of reasonable care, not a guarantee of compliance. FAIIR, LLC is not a law firm and this post is not legal advice.

This article is general information from FAIIR, LLC, which is not a law firm, and is not legal advice. Colorado law does not require or recognize any third-party AI certification, and FAIIR certification is not a government approval or a guarantee of compliance. For advice about your situation, consult a licensed attorney.