An AI impact assessment is a structured way to examine how an AI system could affect people, operations, rights, safety, business outcomes, and organizational risk before the deployment becomes difficult to change. It asks what the system is for, who is affected, which decisions it influences, what could go wrong, what benefits justify the design, what alternatives exist, and which controls are required.
Within AI Governance, impact assessment is the bridge between system inventory and risk management. NIST’s AI RMF playbook recommends impact assessments at key lifecycle stages and connects them to risk measurement, system context, and change over time.
This article describes a general governance pattern. Jurisdiction-specific impact assessments—such as privacy DPIAs or certain statutory fundamental-rights assessments—have their own legal scope and should be handled with the relevant legal guidance.
Start with the intended purpose and prohibited drift
The assessment should describe the purpose narrowly enough that reviewers can distinguish intended use from convenient future uses.
A system built to summarize internal documents should not silently become a decision-support tool for hiring or credit simply because the model can answer those questions.
Documenting prohibited or out-of-scope uses gives change control a baseline for detecting purpose drift.
Map affected people and organizations
Impact extends beyond the direct user. A call-center agent may use AI, while the customer is affected by the resulting recommendation. A fraud model may be used by an analyst, while account holders experience the consequences.
Identify direct users, decision subjects, data subjects, bystanders, downstream teams, external partners, and communities whose interests may be affected.
The assessment should also consider groups who may experience higher impact because of language, disability, age, location, or unequal access to appeal.
Describe the decision pathway
Explain whether the AI generates content, ranks options, recommends actions, triggers automation, or makes a final decision.
Human involvement should be described concretely: who reviews, what evidence they receive, whether they can override, and how much time they have.
“Human in the loop” is too vague if the human routinely clicks accept without meaningful authority.
Assess plausible harms and benefits together
Impact assessment should not assume deployment is always desirable or always harmful. Record expected benefits such as faster service, improved access, lower manual workload, or better detection alongside plausible harms.
This helps decision-makers evaluate whether the AI system is appropriate for the task rather than only asking how to mitigate a design whose value was never established.
NIST Manage 1.1 explicitly frames the decision as whether the system achieves its intended purpose and whether development or deployment should proceed.
Consider alternatives and narrower designs
A useful assessment compares the proposed system with less complex or less intrusive alternatives: deterministic software, workflow changes, human review, smaller model scope, reduced data use, or advisory rather than automated operation.
The comparison should focus on the business objective, not on preserving the AI solution at all costs.
If a simpler system provides similar benefit with materially lower risk, governance should be able to recommend the simpler design.
Connect impacts to controls and evidence
Each material risk should have an owner, control, evidence source, and residual-risk decision.
Examples include bias testing, privacy controls, tool authorization, red teaming, user communication, human review, incident response, fallback, audit logging, or limited deployment scope.
The assessment should not become a narrative document disconnected from the controls engineering teams actually implement.
Use risk scales consistently across the portfolio
NIST guidance notes that organizations can use qualitative scales such as red-amber-green or other methods that combine impact and likelihood.
The important point is consistency. A “high” risk in one team should mean roughly the same governance response as “high” in another team.
Building AI Risk Taxonomies provides the classification foundation for that consistency.
EU fundamental-rights assessments are a specific legal case
The EU AI Act includes a fundamental-rights impact assessment obligation for certain deployers of specified high-risk AI systems under Article 27. The required assessment covers the intended process, frequency of use, affected persons or groups, specific risks of harm, human oversight, and mitigation measures.
That obligation does not mean every organization worldwide must perform the same statutory assessment for every AI system.
Governance teams should distinguish internal impact assessment from legally required assessments and confirm applicable obligations in the relevant jurisdiction.
Reassess when assumptions change
A new user population, automated action, data source, model provider, deployment geography, tool, or business decision can materially change impact.
The assessment should include triggers for refresh rather than one annual review date unrelated to system changes.
Change control is effective when it asks whether the approved impact assessment still describes the real production system.
Impact assessment should end with a decision
The output should be actionable: proceed, proceed with conditions, pilot with monitoring, redesign, restrict scope, require additional evidence, or do not deploy.
A long assessment with no decision authority becomes documentation rather than governance.
The final record should identify who made the decision, what residual risks remain, and what evidence will be monitored after launch.
Impact assessments should include operational dependencies. A model may be safe in isolation but risky when combined with one broad service account, one unreviewed vendor API, or one automated downstream action. The assessment should describe the whole decision system rather than treating the foundation model as the only component.
Reversibility is an important design dimension. A system that only recommends text is easier to stop or correct than one that automatically changes accounts, schedules payments, or denies access. Higher-irreversibility workflows should usually require stronger evidence, oversight, and rollback controls.
Scale changes impact even when per-request behavior is unchanged. A rare error used by five researchers may become material when the same system reaches millions of customers. Assessments should include expected volume and expansion triggers.
Stakeholder input can improve the assessment where the context warrants it. Operators, domain experts, support staff, affected-user representatives, accessibility specialists, or frontline employees may identify impacts that model developers do not see from test data alone.
Monitoring plans should be part of approval. For each major assumption, define a signal that can show whether the assumption remains true after launch. Complaints, override rates, error distributions, bias metrics, safety blocks, incident counts, and drift can all serve as evidence.
Impact assessment should also document dependency on human competence. If a control assumes reviewers understand model uncertainty or can recognize unsafe output, training and workload become part of the control. A reviewer handling 500 cases per hour may not provide meaningful oversight despite the workflow technically containing a human.
A mature assessment is concise enough to use and deep enough to change a decision. Its purpose is not to predict every possible harm; it is to surface the assumptions that matter, connect them to controls, and give an accountable owner enough evidence to choose whether and how deployment should proceed.
Assessment quality improves when evidence is proportionate to uncertainty. A novel agent with external tools may require simulation, red teaming, pilot deployment, and stronger human oversight, while a low-impact summarization feature may justify lighter evidence.
The assessment should identify assumptions that cannot be validated before launch. Those assumptions should become explicit monitoring questions during the pilot rather than being left as undocumented uncertainty.
Dependency failure should be considered as an impact scenario. What happens if the model provider is unavailable, a retrieval index is stale, the guardrail service fails, or the human reviewer queue is overloaded?
Communication and appeal can be controls in their own right. If users are affected by AI-assisted decisions, clear notices, explanation channels, correction mechanisms, and escalation paths can reduce harm even when model accuracy is imperfect.
The final assessment should be understandable to both technical and business decision-makers. Dense technical appendices are useful evidence, but the approval summary should make the key impacts, uncertainties, controls, and residual risks clear enough for accountable leadership to act.
Pilot scope can be a control. Limiting geography, user count, automation level, or decision consequence gives the organization real-world evidence before broader exposure. The assessment should define what must be learned during the pilot and what results would block expansion.
Impact assessment should also consider non-use. If restricting or withdrawing the AI would create its own harm—such as reduced accessibility or service availability—that consequence should be considered alongside deployment risks.
Portfolio teams can reuse common assessment sections for shared models or platforms, but each use case still needs context-specific analysis of affected people, decisions, controls, and expected benefits.
Assessment templates should preserve room for narrative judgment. Fixed scoring fields improve consistency, but unusual harms, dependencies, or affected groups may not fit a standard dropdown.
Portfolio teams should compare assessment outcomes over time to identify recurring control gaps. If many systems need the same compensating control or pilot restriction, the organization may need a shared platform capability rather than repeated project-specific mitigation.
Document who owns the reassessment and who has authority to narrow or stop deployment if monitoring shows the original assumptions no longer hold.
Keep that authority explicit.
Keep that decision traceable.
Keep it current.
