How to Document AI Decision-Making for Colorado AI Act Compliance

The single most common compliance gap we see at Available Law is not a missing policy or a bad contract — it is the absence of any real record of what the business's AI tools actually did. Documentation is the quiet half of AI compliance. It is also the half that determines whether a regulator, auditor, or plaintiff's lawyer walks away satisfied or starts asking harder questions.

This article is the practical guide to building an AI decision-making paper trail that will hold up under scrutiny — without drowning your team in process. It is written for the person who is going to have to actually implement the logging and retention, not just approve the policy.

Why documentation is the load-bearing beam

Colorado SB 26-189, like most emerging AI regulation, imposes duties that are difficult to prove you met without a paper trail. You have to show you posted a clear and conspicuous pre-use notice. You have to prove you sent a 30-day adverse-outcome notice when ADMT contributed to a denial. You have to prove the meaningful human review process actually happened when a consumer asked for it. You have to be able to explain, after the fact, why a specific decision was made — and you have to keep the records for three years.

Documentation is how you do all of those things. It is the difference between “we have a governance program” and “here is the governance program, here is the date it was adopted, here are the assessments we ran, here are the decisions we logged, and here is the incident report from the one time something went wrong.” One of those is a defense. The other is a hope.

What you actually need to document

There are seven categories of documentation every deployer of covered ADMT should maintain. The first four track statutory duties under SB 26-189. The last three aren't strictly required by the AI statute but reflect what a reasonable business would want for its own risk management — and what state anti-discrimination law and the Attorney General will look for during a 60-day cure window.

1. The ADMT inventory

A written list of every AI system your business uses, including third-party tools. For each entry, record the vendor, the product name and version, the business function it serves, the decisions it influences, the categories of data it touches, the department that owns it, and the date it was added. An inventory is the backbone that everything else hangs off of — if a system is not in the inventory, no one is auditing it, documenting it, or monitoring it.

2. System reviews and covered-ADMT classifications

For each ADMT, a written review that describes the system, the data it uses, the decisions it influences, the foreseeable harms, the mitigations in place, and the basis for classifying it as either in-scope or out-of-scope “covered ADMT” under SB 26-189. These have to be dated and signed. They should be refreshed any time the system is meaningfully changed. SB 26-189 dropped the prior law's mandatory annual impact assessment — but a current, honest system review is still the single most useful artifact you can produce when a regulator or plaintiff asks how your AI works.

3. Decision logs

For every consequential decision the system influences, a log entry that captures what the system considered and what it produced. You do not have to store every intermediate neural network activation — you have to be able to reconstruct, after the fact, what inputs the system saw and what output it produced. At a minimum: timestamp, system version, a reference to the inputs, the output, and a reference to whatever downstream action the business took as a result.

4. Human review records

When a consumer asks for human review of an adverse decision, the request, the review, the reviewer, the outcome, and any data corrections have to be logged. This is one of the most visible surfaces of your compliance program because it is consumer-facing — if a complaint eventually lands at the Attorney General's office, the human review log is often the first artifact requested.

5. Bias audits and fairness testing

Any testing you run — whether on your own or through the vendor — should be logged with the date, scope, methodology, results, and remediation actions. If you rely on the vendor's bias audits, keep copies of the vendor's reports and note when you received them. If you ran your own disparate-impact testing, keep the raw data, the analysis, and the written conclusions.

6. Vendor attestations and contract artifacts

Vendor data sheets, model cards, DPAs, SOC 2 reports, indemnification confirmations, and any written commitments the vendor has made about training data, opt-outs, or bias testing. When a regulator asks how you diligenced a vendor, these are the documents you point to. For more on what to negotiate into these contracts, see our guide on the five AI vendor contract clauses every business should pay attention to.

7. Incident reports

When something goes wrong — a harmful output, a disparate impact finding, a data exposure, a vendor compromise — you open an incident record. It captures what happened, when it was detected, who was notified, what the triage looked like, what remediation was performed, and when the incident was closed. SB 26-189 removed the prior law's AG-notification obligation for algorithmic discrimination — but the AG can still demand records during a cure window, and an honest incident record is the cleanest defense.

How to actually build the logging system

You do not need a purpose-built AI governance platform. Most small businesses can stand up a perfectly adequate documentation system with tools they already have. What matters is the structure, not the software.

Pick a single source of truth

Everything above should live in one place. A shared drive with a well-structured folder tree is fine. A Notion or Confluence workspace is fine. A GRC tool is fine. What is not fine is having the inventory in one place, the impact assessments in another, the decision logs in a third, and the incident reports scattered across Slack. Fragmented documentation is the most common way we see compliance programs fail under scrutiny.

Make logging automatic wherever you can

The single biggest predictor of whether a logging system survives its first year is whether the logging is automatic or manual. Decision logs, in particular, should be captured by the system itself — not typed in by a human after the fact. If your AI vendor does not give you a way to pull logs, that is a red flag and a negotiation point at renewal. For internal systems, build logging into the code path that calls the model, not as a separate step.

Set retention periods in writing

Documentation is only useful if it exists for as long as you might need it. SB 26-189 sets a hard floor of three years from the date of the consequential decision. For most artifacts, a more conservative default is the longer of the applicable statute of limitations for the underlying claim or the regulator's explicit retention requirement. For consequential decisions in employment, credit, housing, and healthcare, four to six years is a sensible practical floor. Write the retention schedule down, apply it consistently, and do not delete early just to save storage.

Appoint a human owner

Every artifact category needs a named owner. The inventory might be owned by the operations lead. The impact assessments might be owned by the compliance officer or fractional general counsel. The decision logs might be owned by the engineering manager responsible for the system. The point is not to create bureaucracy — it is to make sure that when something needs updating, a specific person's name is on the hook. Systems without owners decay.

What a minimum viable paper trail looks like

If you are starting from zero and you want to know what the smallest defensible version of this looks like for a Colorado small business, here is our current working answer:

1. A one-page ADMT inventory listing every tool, owner, and whether it is classified as covered ADMT under SB 26-189.
2. A two-to-three-page system review for each covered ADMT, using a consistent template, dated and signed.
3. An automatic decision log for each covered ADMT capturing timestamp, system version, a reference to inputs, and the output. Retained for at least three years (longer if a related claim has a longer limitations period).
4. A pre-use notice posted at points of consumer interaction and a templated 30-day adverse-outcome notice ready to send.
5. A meaningful human review workflow naming authorized reviewers, training, a defined response time, and a log that captures each request and its resolution.
6. A vendor file for each ADMT vendor holding the developer documentation SB 26-189 requires (intended uses, training data categories, limitations, human-review instructions), plus the DPA and any disparate-impact monitoring the vendor has shared.
7. An incident response runbook, even if it is a one page document, naming the triage lead, escalation contacts, and any reporting obligations under state anti-discrimination or privacy law.

If all seven of those exist, are current, and are actually used, you have a defensible compliance posture. You do not need a consultant, a platform, or a committee. You need the seven artifacts, honestly maintained.

Common failure modes to avoid

• Drafting without adopting. A policy or assessment that lives in a draft folder and has never been formally adopted by the business is not documentation — it is a writing sample. Adoption needs a date, a signer, and a place it lives.
• One-time assessments. An impact assessment you wrote in 2026 and never touched again will be worse than useless in 2028. Annual review, with the date of review on the document itself, is the minimum.
• Copy-paste boilerplate. Templates are fine as a starting point but the content has to reflect your actual systems. A regulator who reads three impact assessments and sees identical risk language is going to get suspicious.
• Logging without retention. Capturing decision logs and deleting them after 30 days to save storage defeats the purpose. Set the retention period before you turn the logging on.
• Hiding incidents. An incident that is not documented because no one wants it on the record is the worst possible combination — the harm still happened, but now there is no paper trail showing you responded to it. Honest incident records, even embarrassing ones, are an asset in an enforcement action.

How this fits with the rest of your compliance program

Documentation is not a freestanding workstream. It works because it connects everything else: the statute (which creates the duties), the vendor contracts (which allocate the risk), and the operations team (who actually runs the systems). If you have not yet read our plain-language walkthrough of the Colorado AI Act or our guide to AI vendor contract clauses, those are the other two legs of the same stool. Documentation is how the duties and the contracts become something you can actually defend.

Available Law builds and maintains this documentation system for clients as part of FAIIR certification. If you want a fast readout of which of the seven artifacts you have today and which ones you are missing, our free Colorado AI Act Readiness Checker will walk you through the gap in about two minutes.