AI Impact Assessment Template & Methodology
Last verified: 2026-06-26 - refreshed against Colorado SB 26-189, NIST AI RMF, and ISO/IEC 42001. The former Colorado SB 24-205 annual impact-assessment mandate is no longer the current scheduled Colorado duty; SB 26-189 replaced it with an automated-decision-making-technology (ADMT) regime centered on documentation, records, notice, correction, and human-review evidence.
As of June 26, 2026, an AI impact assessment is best treated as a reusable evidence file: it records the system's purpose, decision role, data, affected stakeholders, measured risks, mitigations, monitoring plan, and sign-off history. That file can support voluntary frameworks such as NIST AI RMF, management-system evidence under ISO/IEC 42001, and state-law duties that require documentation, audit, notice, or review.
Teams looking for the practical generator can use the Impact Assessment Template Generator tool. It produces a Markdown template tailored to jurisdictions and role, but the template still needs source-specific legal review before use.
Quick answer
An AI impact assessment should answer five questions before an AI system is approved or materially changed:
| Question | Evidence to capture | Why it matters |
|---|---|---|
| QuestionWhat does the system do? | Evidence to capturePurpose, intended uses, out-of-scope uses, decision domain, and user groups | Why it mattersScopes the legal and operational review |
| QuestionWho is accountable? | Evidence to captureSystem owner, developer/deployer role, vendor owner, risk owner, and sign-off approvers | Why it mattersPrevents unmanaged handoffs between legal, product, and engineering |
| QuestionWhat data and model behavior are known? | Evidence to captureTraining/operational data classes, performance metrics, limitations, monitoring signals, and known failure modes | Why it mattersCreates the technical record needed for documentation and review |
| QuestionWho can be affected? | Evidence to captureStakeholder groups, consequential-decision domains, bias-testing slices, and adverse-outcome paths | Why it mattersIdentifies discrimination, access, safety, and consumer-impact risks |
| QuestionWhat evidence stays current? | Evidence to captureMitigations, notices, human-review workflow, incident log, refresh date, and material-change trigger | Why it mattersKeeps the record usable after launch |
Why impact assessments matter in 2026
Impact assessments matter because the same evidence file can serve multiple layers, but those layers are not identical.
| Source | Current role of the assessment file | Primary source |
|---|---|---|
| SourceColorado SB 26-189 ADMT regime | Current role of the assessment fileColorado's current enacted ADMT framework does not use SB 24-205's standalone annual impact-assessment mandate. It requires covered-ADMT technical documentation, at least 3 years of compliance records, consumer notice, post-adverse-outcome descriptions, correction rights, and meaningful human review. An impact-assessment file is still useful as the internal evidence binder for those duties. | Primary sourceColorado SB 26-189, retrieved 2026-06-26 |
| SourceNIST AI RMF | Current role of the assessment fileNIST describes AI RMF 1.0 as voluntary and designed to help organizations manage risks to individuals, organizations, and society. MAP, MEASURE, and MANAGE provide the structure for purpose, impact, measurement, mitigation, and monitoring evidence. | Primary sourceNIST AI Risk Management Framework, retrieved 2026-06-26 |
| SourceISO/IEC 42001 | Current role of the assessment fileISO describes ISO/IEC 42001:2023 as a standard for establishing, implementing, maintaining, and continually improving an AI management system. An assessment file supports the management-system evidence trail, especially for risk treatment, monitoring, and continual improvement. | Primary sourceISO/IEC 42001:2023, retrieved 2026-06-26 |
The practical conclusion: do not build one "Colorado annual assessment" form and assume it covers every regime. Build a modular evidence file that can attach Colorado ADMT records, NIST risk-management analysis, ISO management-system evidence, and state or sector overlays where they apply.
Who runs the assessment
- System owner: accountable for purpose, decision domain, launch status, and business acceptance.
- Engineering or model owner: responsible for data lineage, model limitations, performance metrics, monitoring, and change history.
- Legal / compliance: responsible for jurisdiction, role, statutory trigger, source citation, and evidence-retention mapping.
- Risk / privacy / security: responsible for impact severity, protected data, vendor controls, incident paths, and escalation thresholds.
- Affected business unit: validates whether the assessment describes the real workflow, not only the intended product design.
Structure of a defensible impact assessment
1. System purpose and intended use
Describe what the system does, what decision or recommendation it supports, who uses it, and which uses are explicitly out of scope.
2. Applicable jurisdictions and frameworks
List every applicable law, regulator, and voluntary framework. Separate binding obligations from voluntary control baselines. Use the AI compliance framework guide to keep source URL, date retrieved, owner, and evidence fields in one register.
3. Role classification
Record whether the organization is acting as developer, deployer, vendor, or both for this system. The deployer vs developer guide should hold the role logic; the assessment should hold the system-specific decision.
4. Data inventory
For each dataset used in training, fine-tuning, retrieval, prompting, scoring, or monitoring, record source, data class, sensitive attributes, retention period, access owner, and known limitations.
5. Stakeholder impact analysis
For each affected group, describe the impact category, severity, likelihood, and mitigation. Consequential decision domains such as employment, lending, housing, insurance, healthcare, education, government benefits, and legal services need stricter review.
6. Performance and bias measurement
Record metrics, test population, comparison groups, thresholds, known error types, and remediation steps. If bias testing is not feasible, document why and what proxy evidence is used.
7. Transparency and notices
Record what the affected person, customer, employee, regulator, or downstream deployer receives: disclosure copy, timing, channel, responsible owner, and proof that the notice remains visible in the product flow.
8. Human oversight and review
Define when humans review outputs, when a decision can be appealed or reconsidered, what data can be corrected, and who has authority to suspend the system.
9. Post-deployment monitoring
Track drift, incident count, complaint themes, performance by slice, vendor changes, prompt or model changes, and review cadence.
10. Risk register and treatment
For each risk, record likelihood, impact, treatment, owner, deadline, residual risk, and acceptance decision.
11. Sign-off and refresh trigger
Record approvals from risk, legal, engineering/product, and the business owner. Add a refresh trigger for material changes to model, data, purpose, vendor, jurisdiction, user group, or decision domain.
Colorado SB 26-189 evidence map
Colorado's current enacted ADMT framework is documentation- and notice-centered. An assessment file can still organize the evidence, but the field labels should match the current source.
| Assessment field | How it supports SB 26-189 evidence |
|---|---|
| Assessment fieldSystem purpose and intended use | How it supports SB 26-189 evidenceSupports developer technical documentation describing intended uses and appropriate use instructions |
| Assessment fieldData inventory | How it supports SB 26-189 evidenceSupports documentation of training-data categories and limitations |
| Assessment fieldPerformance and limitations | How it supports SB 26-189 evidenceSupports known-limitation documentation and post-deployment monitoring decisions |
| Assessment fieldNotice and adverse-outcome workflow | How it supports SB 26-189 evidenceSupports point-of-interaction notice and the plain-language post-adverse-outcome description |
| Assessment fieldCorrection and human-review process | How it supports SB 26-189 evidenceSupports consumer requests to correct factually incorrect personal data and request meaningful human review |
| Assessment fieldRecord-retention owner | How it supports SB 26-189 evidenceSupports the requirement to retain compliance records for at least 3 years |
Source: Colorado SB 26-189, retrieved 2026-06-26.
Practical methodology
Step 1: Start from the system inventory
Pull system name, owner, vendor, purpose, data classes, decision domain, users, jurisdictions, and production status from the inventory. If those fields are missing, pause the assessment and fix the inventory first.
Step 2: Scope legal and framework overlays
Attach NIST AI RMF or ISO/IEC 42001 as the control baseline, then add jurisdiction rows for the exact state, municipal, or sector rule triggered by the system. The assessment should not state that a voluntary framework replaces a statute.
Step 3: Gather technical evidence
Engineering should provide model architecture, training or retrieval sources, performance metrics, test slices, monitoring instrumentation, and known limitations. Product should provide the real user workflow and escalation paths.
Step 4: Review stakeholder and discrimination risk
Run protected-class, access, safety, and consumer-impact analysis. Employment, lending, housing, insurance, healthcare, education, government benefits, and legal-service uses should receive heightened review because they map to consequential-decision concepts in several regimes.
Step 5: Finalize treatment and sign-off
Convert risks into owners and deadlines. Approval should record who accepted residual risk, which mitigations must ship before launch, and what evidence must be refreshed after deployment.
Step 6: Refresh on schedule and material change
A practical cadence is annual review for high-impact systems plus immediate review after material changes to model, data, vendor, purpose, jurisdiction, user group, or decision domain. Where a specific law or contract sets a shorter cadence, use the shorter cadence.
Common mistakes
- Using a stale statutory template: Colorado's current SB 26-189 ADMT regime should not be described as the old SB 24-205 annual impact-assessment mandate.
- Treating the assessment as a policy essay: regulators and auditors need evidence fields, source dates, owners, thresholds, and records.
- Skipping product evidence: the assessment should match the actual product flow, including notices and human-review paths.
- Writing about bias without measuring it: if quantitative testing is unavailable, document why and what alternative evidence supports the decision.
- No refresh trigger: a one-time document decays quickly when model, data, vendor, prompt, or use case changes.
Frequently asked questions
Is Colorado still an annual AI impact-assessment law?
Not in the same form as SB 24-205. The current enacted Colorado source is SB 26-189, which repeals and reenacts the earlier framework as an ADMT regime effective January 1, 2027. The bill summary describes developer documentation, record retention, consumer notice, adverse-outcome descriptions, correction rights, and human review, rather than the former standalone annual impact-assessment mandate.
Is an AI impact assessment still useful for Colorado?
Yes. The document remains useful as an internal evidence binder for covered-ADMT classification, technical-documentation requests, notice design, adverse-outcome workflows, correction processes, human-review procedures, and 3-year record retention.
Does NIST AI RMF require an impact assessment?
NIST AI RMF is voluntary. Its MAP, MEASURE, and MANAGE functions provide a practical structure for impact, measurement, mitigation, and monitoring evidence, but the binding duty comes from the applicable statute, contract, regulator, or internal governance rule.
Does ISO/IEC 42001 certification replace state-law impact evidence?
No. ISO/IEC 42001 can support an AI management-system audit trail, but a certificate does not by itself discharge state, municipal, or sector-specific legal duties. The statutory overlay should stay in the assessment file.
How often should the assessment be refreshed?
High-impact systems should be reviewed at least annually and whenever model, data, vendor, purpose, jurisdiction, user group, or decision domain materially changes. Shorter statutory, contractual, or regulator-imposed deadlines should control where they apply.
Cross-references
- Impact Assessment Template Generator - generates the baseline document
- NIST AI RMF - voluntary risk-management framework for MAP / MEASURE / MANAGE evidence
- ISO/IEC 42001 - AI management-system standard
- Colorado AI Act - current Colorado SB 26-189 status and ADMT duties
- AI Compliance Framework - register structure for laws, controls, owners, and evidence
- AI Governance - operating model for decision rights and lifecycle gates
- HIPAA compliance for AI - healthcare PHI/ePHI overlay for impact assessments