Guide · Published November 8, 2026
AI Impact Assessment: What the Rules Actually Require
An AI impact assessment is a written record of how one AI system will affect people, done before launch and updated when it changes. Two rules here require one: EU AI Act Article 27 (a “fundamental rights impact assessment”), from December 2, 2027, for public bodies and public-service providers using high-risk systems, and for credit scoring and life or health insurance pricing; and OMB M-25-21, for high-impact AI at US federal agencies. Both have exceptions, listed below. Colorado’s SB 26-189 no longer requires one. California’s “risk assessment” covers similar ground.
Does it apply?
Seven sources, in the order to check them
Whether you must run one depends on which rule reaches you.
Stop at the first row that binds you, then use the next table to see what that rule asks for. A deployer is the organization using a system under its own authority, as Article 3(4) of the EU AI Act defines it. Sources were read on November 8, 2026. This page does not cover every jurisdiction or sector regulator.
| Source | Status | Who it reaches | When | What it calls it |
|---|---|---|---|---|
| EU AI Act, Article 27 | Binding law, narrow scope | Deployers of Annex III high-risk systems that are bodies governed by public law or private entities providing public services, except for critical infrastructure systems (point 2). Also deployers of systems that score people’s creditworthiness, other than systems used to detect financial fraud (point 5(b)), and of life and health insurance risk and pricing systems (point 5(c)). | Before first use, from December 2, 2027 (Article 113(c)(i), as amended). Systems placed on the market or put into service before that date are covered only after a significant design change, and those intended for public authorities must comply by August 2, 2030 (Article 111(2), as amended). | Fundamental rights impact assessment |
| OMB M-25-21, Section 4(b)(ii) | Binding on US federal agencies | Agencies, other than elements of the Intelligence Community, for high-impact AI: output that is a principal basis for decisions or actions with a legal, material, binding, or significant effect on rights, access to programs or services, health and safety, critical infrastructure, or strategic assets. It does not cover AI used as a component of a National Security System (Section 1(c)). | Before deploying any high-impact use. Agencies had 365 days from the April 3, 2025 memorandum to document the minimum practices, and a use that does not comply must be safely discontinued. Exceptions: pilots of limited scale and duration that the Chief AI Officer certifies (Section 4(a)(i)), and written waivers by the Chief AI Officer, reported to OMB (Section 4(a)(ii), (iii)). | AI impact assessment |
| California CCPA regulations, §§ 7150 to 7157 | Binding on CCPA businesses, under another name | Businesses using automated decision-making technology (ADMT) for a significant decision about a consumer, among other listed processing (§ 7150(b)). | Before the processing starts. Processing begun before the January 1, 2026 effective date that continues after it: by December 31, 2027 (§ 7155(b)). Assessments from 2026 and 2027 are reported to the agency by April 1, 2028 (§ 7157(a)(1)). | Risk assessment |
| ISO/IEC 42001:2023 | Voluntary standard; applies if you adopt or certify to it | Organizations providing or using AI-based products or services, in ISO’s description. | Clauses 6.1.4 and 8.4 are titled “AI system impact assessment” in NIST’s crosswalk. Timing detail is in the paid text. | AI system impact assessment |
| ISO/IEC 42005:2025 | Guidance, not a requirement | “Any organisation developing, providing or using AI systems,” in ISO’s description. | ISO says the standard recommends assessing throughout the lifecycle, from design and development to deployment and post-market monitoring, and updating as needed. | AI system impact assessment |
| NIST AI RMF 1.0 | Voluntary; NIST says it is being revised | Any organization that chooses to use it. NIST states it is intended for voluntary use. | The Map function informs “an initial go/no-go decision,” and NIST says to keep applying it as impacts evolve. | AI impact assessment tasks |
| Colorado SB 26-189 | No impact assessment required | A person doing business in Colorado that develops or deploys covered ADMT. | Applies to consequential decisions made on or after January 1, 2027 (Section 5). Deployers keep records of compliance for at least three years after each consequential decision (6-1-1703). | None |
EU dates come from Regulation (EU) 2026/1744, the amending regulation, and match the Commission’s AI Act page. Article 27 scope is in Annex III. The AI Act Explorer also lists August 2, 2028 for Annex I products, which does not change the answer because Article 27 covers only Article 6(2) systems. Article 27(3) has deployers file a template the AI Office is to develop under Article 27(5). The Institute found no published template on the Commission’s page on November 8, 2026, so check before you file.
Colorado changed course. The SB 24-205 summary listed completing an impact assessment among the steps behind a deployer’s presumption of reasonable care. The signed text of SB 26-189 contains no impact assessment requirement, so guides written against the 2024 law are out of date. Who is covered and what is required instead is on the Institute’s Colorado AI Act page.
California’s rules took effect January 1, 2026. ISO’s paid text was not read. Statements about ISO/IEC 42001 and 42005 come only from ISO’s public product pages and the clause titles listed in NIST’s crosswalk. The Annex A impact controls are listed in the Institute’s ISO 42001 controls list. NIST’s voluntary status and revision note are on its AI RMF page.
What it must contain
Requirement by requirement
What each source asks the assessment to cover.
Each cell paraphrases the provision cited in it. Sources: EU AI Act Article 27 and Recital 96, OMB M-25-21 Section 4(b)(ii) (letters A to G), California CCPA regulations, NIST AI 100-1, and the public pages for ISO/IEC 42001 and ISO/IEC 42005. Colorado has no column because SB 26-189 requires none of it.
| Requirement | EU AI Act, Art. 27 | OMB M-25-21 | California regulations | NIST AI RMF | ISO/IEC 42001, 42005 (public text only) |
|---|---|---|---|---|---|
| When | Before first use (27(1), 27(2)). | Before deploying; updated periodically and across the lifecycle. | Before the processing starts (§ 7155(a)(1)); older processing by December 31, 2027 (§ 7155(b)). | MAP informs “an initial go/no-go decision”; keep applying it as impacts evolve. | ISO says 42005 recommends assessing throughout the lifecycle. |
| The use | The deployer’s processes, in line with the intended purpose (27(1)(a)); how long and how often it runs (27(1)(b)). | Intended purpose and expected benefit, with metrics or qualitative analysis against current processes (A). | A specific purpose, not “to improve our services” (§ 7152(a)(1)); operational details (a)(3); for ADMT, its logic and how the output is used (a)(3)(G). | MAP 1.1: intended purposes, context-specific laws, norms, and settings. MAP 3.3: application scope. | Not in the public text. |
| Who is affected | Categories of people and groups likely to be affected in the specific context (27(1)(c)). | The public, whose privacy, civil rights, and civil liberties the use may affect (C). | Consumers whose personal information is processed (§ 7150(a), § 7152(a)(5)). | MAP 5: individuals, groups, communities, organizations, and society. | “Individuals, groups, or society at large” (ISO on 42005). |
| Harms and benefits | Specific risks of harm to those groups, using the provider’s Article 13 information (27(1)(d)). | Potential impacts of using and of not using the AI (C); benefits (A); direct costs and expected savings (E). | Benefits in specific terms (§ 7152(a)(4)); negative impacts and their causes, from discrimination to economic and psychological harm (a)(5). | MAP 5.1: likelihood and magnitude of each impact, beneficial and harmful. MAP 3.1, 3.2: benefits and costs. | NIST’s crosswalk lists B.5.4 (individuals and groups) and B.5.5 (societal impacts). |
| Data | Not listed in Article 27. | Quality and appropriateness of data and model, with a summary, including protected-class information where applicable (B). | Categories of personal and sensitive information, and the minimum necessary (§ 7152(a)(2)). | MAP 4.1: legal risks of components, including third-party data. | Not in the public text. |
| Human oversight | How oversight measures are implemented, per the instructions for use (27(1)(e)). | A separate minimum practice, outside the assessment (Section 4(b)(v)). | Not a named field. Safeguards can include policies and training for ADMT (§ 7152(a)(6)). | MAP 3.5: human oversight processes defined, assessed, and documented. | Not in the public text. |
| If harm occurs | Measures if the risks materialise, including internal governance and complaint mechanisms (27(1)(f)). | Planned mitigations (C). Human review and appeals are a separate minimum practice (Section 4(b)(vi)). | Planned safeguards against the negative impacts (§ 7152(a)(6)). | MANAGE 1.3: responses to high-priority risks. MEASURE 3.3: ways for impacted communities to report problems and appeal. | Not in the public text. |
| Who contributes | Deployers could involve representatives of affected groups, independent experts, and civil society (Recital 96). | Feedback from end users and the public (Section 4(b)(vii)). | Employees involved in the processing must take part (§ 7151(a)); outside parties may (§ 7151(b)); contributors are named (§ 7152(a)(8)). | MAP 1.2: interdisciplinary team, participation documented. MAP 5.2: regular engagement on impacts. | Not in the public text. |
| Review and sign-off | Names no reviewer or signer. The duty sits with the deployer. | Independent reviewer not involved in development; comments stay in the record (F). “A signature from the individual accepting the risk” (G). | Someone with authority to take part in deciding whether to proceed must review and approve; names, positions, and date are recorded (§ 7152(a)(9)). | GOVERN 2.3: executive leadership takes responsibility for risk decisions. MANAGE 1.1: decide whether deployment should proceed. | Not in the public text. |
| Keep it current | Update if an element changes or is no longer up to date (27(2)). | Reassessment schedule, and reassessment after significant modifications (D). | Review at least every three years; update within 45 calendar days of a material change (§ 7155(a)(2), (3)). | GOVERN 1.5: periodic review, with the frequency set in advance. | ISO says assessments are updated as needed. |
| Where it goes | Notify the market surveillance authority with the filled-out template (27(3)); possible exemption in Article 46(1) cases. | Documented; agencies must be prepared to report implementation to OMB (Section 4(a)(i)). | Counts, data categories, and an executive attestation go to the agency (§ 7157(a), (b)); full reports within 30 days if the agency or Attorney General asks (§ 7157(e)); kept while processing continues or five years after completion, whichever is later (§ 7155(c)). | No filing. GOVERN 4.2: teams document impacts and communicate about them. | Not in the public text. |
The California text calls this a risk assessment and it covers privacy risk from processing personal information. The Article 27 assessment covers fundamental rights. California accepts an assessment made for another purpose only if it contains, or is paired with, everything § 7152 requires (§ 7156(b)). Under Article 27(4), as replaced by Regulation (EU) 2026/1744, where a data protection impact assessment already meets an Article 27 obligation, the deployer may cross-reference it or include parts of it.
Working field list
Nineteen fields, in working order
Fill these in order, then cut the ones no rule asks you for.
Each field names who calls for it, so you can keep what binds you and defend what you add. EU means Article 27, OMB means M-25-21 Section 4(b)(ii) letters unless a section is given, and CA means the California regulations. This is a list of fields, not a form: the answers depend on your system and your rules.
| Field | What to write | Called for by |
|---|---|---|
| System and use | ||
| 1. System, version, and your role | Name, version, supplier, and whether you are the provider, the deployer, or both. | EU Article 3(3), 3(4); NIST MAP 3.3 |
| 2. Rules that apply | Which rows of the first table bind this system, and why. | NIST MAP 1.1 |
| 3. Process and decision | The business process it sits in and the decision it makes or informs. | EU 27(1)(a); CA § 7152(a)(3)(G) |
| 4. Purpose and expected benefit | A specific purpose and a measurable benefit, compared with how the work is done now. | OMB A; CA § 7152(a)(1), (a)(4); NIST MAP 3.1 |
| 5. Period and frequency | When it runs, how often, and for how long. | EU 27(1)(b) |
| People | ||
| 6. Affected people and groups | Everyone the output reaches, including people who never touch the system themselves. | EU 27(1)(c); NIST MAP 5; ISO 42005 summary |
| 7. Input from those affected | Who was consulted, including representatives of affected groups or independent experts. | EU Recital 96; CA § 7151(b); OMB 4(b)(vii); NIST MAP 5.2 |
| 8. Contributors | Who supplied each piece of information in this record. | CA § 7152(a)(8); NIST MAP 1.2 |
| Effects | ||
| 9. Data used | Inputs and their sources, personal and sensitive categories, quality, and fitness for this purpose. | OMB B; CA § 7152(a)(2), (a)(3) |
| 10. Harms, by group | The specific harms for each group in field 6, with likelihood and severity where you can estimate them. | EU 27(1)(d); OMB C; CA § 7152(a)(5); NIST MAP 5.1 |
| 11. Effect of not using it | What happens to the same people if the AI is not used. | OMB C |
| 12. Costs | Direct costs, expected savings, and non-monetary costs of errors. | OMB E; NIST MAP 3.2 |
| Controls | ||
| 13. Human oversight | Who reviews what, and with what authority to override, following the provider’s instructions for use. | EU 27(1)(e); OMB 4(b)(v); NIST MAP 3.5 |
| 14. Mitigations and safeguards | The planned measure for each harm, with an owner. | OMB C; CA § 7152(a)(6); NIST MANAGE 1.3 |
| 15. Complaints and redress | How a person challenges an outcome and reaches a human, and who handles it internally. | EU 27(1)(f); OMB 4(b)(vi); NIST MEASURE 3.3 |
| Decision | ||
| 16. Independent review | Reviewer’s name, confirmation they were not involved in development, and their comments in full. | OMB F |
| 17. Decision and sign-off | Go or no-go, by whom, with name, position, date, and signature. | OMB G; CA § 7152(a)(7), (a)(9); NIST GOVERN 2.3, MANAGE 1.1 |
| Upkeep | ||
| 18. Reassessment | The next scheduled review and the changes that force an earlier one. | EU 27(2); OMB D; CA § 7155(a)(2), (3); NIST GOVERN 1.5 |
| 19. Filing and retention | Where it is filed, any regulator notification, and how long you keep it. | EU 27(3); CA § 7155(c), § 7157; Colorado 6-1-1703 |
Who signs it
Only one source names a signature
Decide who signs before you fill in the first field.
The sources disagree on who answers for the assessment. Four positions, from most specific to least.
- 01
US federal agencies: the person accepting the risk
The assessment must include “a signature from the individual accepting the risk.” An independent reviewer who has not been involved in development adds comments, and those comments go to that person when the decision is made. OMB encourages giving risk responsibilities to officials accountable for the mission outcome of the use case.
OMB M-25-21, Section 4(b)(ii)(F), (G) - 02
California: a decision-maker, then an executive
Someone with authority to take part in deciding whether the processing goes ahead must review and approve the assessment, with names, positions, and date on record. The submission to the agency is attested under penalty of perjury by a member of the executive management team.
§ 7152(a)(9), § 7157(b), (c) - 03
EU AI Act: the deployer, with no role named
Article 27 puts the duty on the deployer and names neither a job title nor a signature. Your own governance has to say who owns the assessment and who files it.
EU AI Act, Article 27 - 04
NIST and ISO: leadership, in general terms
NIST’s GOVERN 2.3 says executive leadership takes responsibility for decisions about AI risks, without describing a signature. ISO’s public pages do not say who signs, and the Institute has not read the paid text.
NIST AI 100-1, Table 1
Where your rule names no one, the Institute’s suggestion is to copy the federal structure: a preparer, an independent reviewer, and one named person who accepts the risk and can stop the launch. That is a suggestion, not a legal requirement.
Impact vs risk
AI impact assessment vs AI risk assessment
One asks who is affected. The other asks how likely and how bad.
The two overlap, and the sources do not keep them fully apart. NIST writes risk as a function of negative impact and the likelihood of it occurring, so what you find in an impact assessment feeds the risk score.
| Aspect | AI risk assessment | AI impact assessment | Source |
|---|---|---|---|
| The question | How likely is the event, and how bad would it be? | Who is affected, and how? | NIST AI 100-1, 1.1; ISO/IEC 42005 |
| What it centers on | The event: NIST’s “composite measure of an event’s probability of occurring and the magnitude or degree of the consequences.” | The people who bear the effects: “individuals, groups, or society at large.” | NIST AI 100-1, 1.1; ISO/IEC 42005 |
| ISO family | ISO/IEC 23894 on AI risk management; clause 6.1.2 of 42001, “AI risk assessment.” | ISO/IEC 42005, “focusing specifically on the societal and human impacts of AI”; clauses 6.1.4 and 8.4 of 42001. | ISO/IEC 42005; NIST crosswalk |
| EU AI Act | Article 9 risk management system, which providers must meet through Article 16(a). | Article 27 assessment, a deployer duty. | Article 9; Article 16; Article 27 |
| OMB M-25-21 | Pre-deployment testing and risk mitigation plans (Section 4(b)(i)). | AI impact assessment (Section 4(b)(ii)). | OMB M-25-21 |
To score the harms from field 10, use the Institute’s AI risk assessment method, which tiers a use case and rates likelihood and severity. Its step three maps affected people, so one record can support both.
If you need outside help
Before you hire anyone
Know which part you are paying someone else to do.
With the rows from the first table and the fields filled in as far as you can, you can say what is missing: legal scoping, assessment facilitation, or an independent review. The Institute’s AI governance consulting guide compares what firms publish about scope, timelines, and fees, and shows the groundwork you can finish first. The Institute does not perform, review, or certify these assessments, and it does not sell consulting.
Common questions
AI impact assessment FAQ
Answers to the questions people search for.
What is an AI impact assessment?
It is a written record of how an AI system may affect people, groups, and society, done before launch and updated when the system changes. ISO describes the purpose of ISO/IEC 42005 as understanding how AI systems and their foreseeable applications may affect individuals, groups, or society at large.
Is an AI impact assessment legally required in the US?
Not generally. US federal agencies must complete one before deploying high-impact AI under OMB M-25-21, unless a certified pilot exemption or a written waiver applies. California requires businesses to complete a risk assessment before using automated decision-making technology for a significant decision about a consumer. Colorado’s SB 26-189 does not require an impact assessment. Other laws or contracts may apply, so confirm with counsel.
Does the EU AI Act require one for every high-risk system?
No. Article 27 covers deployers of Annex III high-risk systems that are bodies governed by public law or private entities providing public services, plus deployers of credit-scoring systems (other than fraud detection) and life or health insurance pricing systems. It excludes critical infrastructure systems under Annex III point 2. It applies from December 2, 2027; systems already in service before then are covered only after a significant design change, except that those intended for public authorities must comply by August 2, 2030.
How is it different from an AI risk assessment?
A risk assessment asks how likely and how severe an event is, and decides controls. An impact assessment asks who is affected and how. They connect: NIST describes risk as a function of negative impact and likelihood. ISO separates them into ISO/IEC 23894 for risk and ISO/IEC 42005 for impacts.
How is it different from a data protection impact assessment?
A data protection impact assessment is the assessment made under Article 35 of the GDPR. The EU fundamental rights impact assessment looks at the effect of using a high-risk AI system on fundamental rights. Since Regulation (EU) 2026/1744, where a data protection impact assessment already meets an Article 27 obligation, the deployer may cross-reference its relevant sections, or include parts of it, in the fundamental rights impact assessment.
Who should sign an AI impact assessment?
Among these sources, only OMB M-25-21 requires a signature on the assessment itself, from the individual accepting the risk. California requires review and approval by someone with authority to take part in deciding whether the processing goes ahead, plus an executive attestation to the agency. Where no one is named, the Institute suggests one named person who accepts the risk and can stop the launch.
Can we rely on our AI vendor’s assessment?
In part, under the EU AI Act. Article 27(2) lets a deployer, in similar cases, rely on previously conducted fundamental rights impact assessments or on existing impact assessments carried out by the provider, and it must update the information if an element changes. Article 27(1) still asks about the deployer’s own processes, the people affected in its context, and its oversight.
Is there an AI impact assessment template we can copy?
Not one that satisfies all of these sources. The EU template is for the AI Office to develop under Article 27(5), and the Institute found none on the Commission’s AI Act page on November 8, 2026. The field list on this page names what each source asks for, but the answers have to come from your own system.
Does LA Global Institute perform, review, or certify AI impact assessments?
No. LA Global Institute publishes governance documents and explanations. It does not perform, review, or certify AI impact assessments, give legal advice, sell consulting, or operate a certification, accreditation, audit, or regulatory program. Organizations named on this page are cited for what they publish; none is endorsed.
Sources were read on November 8, 2026 and change: NIST says the AI RMF 1.0 is being revised, and OMB memoranda are replaced from time to time. References do not imply affiliation with, or endorsement by, the European Commission, OMB, NIST, ISO, IEC, the California Privacy Protection Agency, the Colorado General Assembly, or any other organization.
Next step