AI Risk Assessment vs AI Impact Assessment: Triggers, Owners and One Workflow

Many organisations run an AI risk assessment and an AI impact assessment on the same system with different teams, different forms and no shared record, so the same questions are asked twice and the answers disagree. The two assessments look at different things: one asks what the AI system could do to the organisation, the other what it could do to people and society. This guide is for AI governance leads, risk managers, privacy officers and product owners who must decide when each is triggered, who owns it and how to run them as one workflow. It does not repeat the method in the AI Risk Assessment Guide or the fields in the AI Impact Assessment Template; it sits between them. Sources were checked on 13 November 2026.

Key takeaways

• Different subjects, shared inputs. The risk assessment's subject is the organisation and its objectives; the impact assessment's subject is affected individuals, groups and society. Both need the same system description, data flows and context of use.
• ISO/IEC 42001 keeps them separate on purpose. Clause 6.1.2 AI risk assessment and clause 6.1.4 AI system impact assessment are distinct requirements, with matching operational clauses 8.2 and 8.4; ISO/IEC 42005:2025 gives guidance for the impact assessment.
• Triggers differ. A risk assessment is triggered by the organisation's risk process for any material AI use; an impact assessment by effects on people, and by law in specific cases such as the EU AI Act Article 27 FRIA or a GDPR Article 35 DPIA.
• Owners differ, so does sign-off. The business owner accepts residual risk to the organisation; the impact assessment needs input from affected people or their representatives and an owner who can stop or change the use.
• Run one workflow with two outputs. One intake, one shared system record, two analyses in parallel, and a cross-feed so that each serious impact on people appears as a risk in the register.

The short answer

An AI risk assessment identifies, analyses and evaluates risks that an AI system poses to the organisation's objectives: security, legal, financial, operational and reputational. Its output is a scored risk list, a treatment plan and an acceptance decision, kept in the risk register. NIST AI RMF MANAGE 1.2 describes the prioritisation: treatment of documented AI risks is "prioritized based on impact, likelihood, and available resources or methods."

An AI impact assessment identifies and evaluates the consequences of the system for individuals, groups and society: rights, safety, access to services, fairness, wellbeing and the environment. ISO describes ISO/IEC 42005:2025 as guidance for assessing how AI systems and their foreseeable applications may affect individuals, groups or society, across the lifecycle. NIST AI RMF MAP 5.1 asks for the likelihood and magnitude of each identified impact, "both potentially beneficial and harmful".

The same event can appear in both. A biased screening model is a fairness impact on applicants and a legal and reputational risk to the employer. The difference is whose loss is measured and who decides whether it is acceptable.

AI risk assessment: threat model, owner and failure modes

Threat model and architecture

The risk assessment models threats to the organisation: an attacker abusing an agent's tools, data leaking through prompts or logs, a supplier changing a model without notice, a regulator finding a breach of law, or customers losing trust. It looks at the system as a set of components with owners: the model and provider, the application, retrieval sources, credentials and integrations. In the EU AI Act, providers of high-risk systems must run a risk management system under Article 9 as a "continuous iterative process" across the lifecycle, covering risks to health, safety and fundamental rights under intended use and reasonably foreseeable misuse. That provider duty already reaches beyond the organisation, which is one reason the two assessments must be connected.

Owner

The risk owner is the person accountable for the business outcome, usually the business or product owner, with the risk function setting method and scales and the security, privacy and legal functions contributing analysis. NIST AI RMF GOVERN 2.1 asks that roles, responsibilities and lines of communication for mapping, measuring and managing AI risks be documented. Sign-off follows the organisation's risk appetite: higher residual risk needs a more senior signature.

Failure modes

• People reduced to reputation: harm to an applicant or patient is scored only as "reputational impact: medium", which hides the actual harm and the people who bear it.
• Model-only scope: the assessment reviews the model card and never asks what data and tools the deployed system can reach.
• No re-trigger: a provider model update or new tool goes live without a reassessment because the trigger list only names code releases.

AI impact assessment: threat model, owner and failure modes

Threat model and architecture

The impact assessment models consequences for people in a specific context of use: wrongful denial of a service, discrimination, loss of privacy, unsafe advice, manipulation, or loss of a way to challenge a decision. It looks at the system as a decision process: who supplies inputs, what the output influences, who can override it and who is affected downstream. ISO/IEC 42005 recommends assessment from design through deployment and post-market monitoring, updated as needed.

Where the law requires one, the content is fixed. Article 27 of the EU AI Act requires certain deployers of high-risk systems to assess, before first use, the processes in which the system is used, the period and frequency of use, the categories of people likely to be affected, the specific risks of harm to them, how human oversight is implemented and the measures if risks materialise, including governance and complaint mechanisms. A GDPR Article 35 DPIA is required where processing is likely to result in a high risk to individuals; the ICO's list says innovative technology, including AI, needs a DPIA when combined with another criterion such as evaluation or scoring.

Owner

The impact assessment owner is the person who can change or stop the use: the product or service owner for a deployed system, or the head of the function that relies on it. The AI governance function runs the method; privacy, legal, HR or customer teams contribute; and NIST AI RMF MAP 5.2 asks for practices and personnel that support regular engagement with relevant AI actors and integrate feedback about impacts. In practice that means consultation with affected groups or their representatives, not only internal experts. Independence matters more here than in a risk assessment, because the people affected are not in the room.

Failure modes

• Treated as a privacy form: the DPIA is reused as the impact assessment, so effects that do not involve personal data processing, such as unequal service quality or deskilling of staff, are never assessed.
• No affected-group input: the assessment describes impacts on people who were never asked.
• Completed after launch: Article 27 requires the FRIA before first use, and Canada's Algorithmic Impact Assessment is started at the beginning of the design phase and completed again before production; an assessment written after go-live documents decisions it can no longer change.

When each is triggered

The Article 27 duty applies to systems referred to in Article 6(2), excluding critical infrastructure systems under Annex III point 2. Paragraphs 3 and 4 of Article 27 are shown as amended by the Digital Omnibus on AI on the Commission's AI Act Service Desk, and application dates have moved, so check the current text and the EU AI Act Implementation Timeline Tracker before relying on a date. The EU AI Act Fundamental Rights Impact Assessment guide covers the FRIA in depth.

Inputs and outputs: what to share and what to keep separate

Most duplication comes from both assessments rebuilding the same description of the system. Split the record into a shared core and two analysis sections.

Article 27(4) allows a FRIA to build on an existing DPIA, and Article 27(2) lets a deployer rely, in similar cases, on earlier assessments or ones carried out by the provider, updating any element that has changed. Design the shared core so the DPIA, FRIA and ISO/IEC 42001 records can point to it rather than copy it.

One workflow without duplication

1. Intake and screening: every AI use case enters through one form, such as the AI Use Case Intake Form Template. Screening questions decide the risk tier and whether a full impact assessment, a FRIA or a DPIA is required. NIST AI RMF GOVERN 1.3 calls for processes that determine the needed level of risk management activity based on risk tolerance; screening is that process.
2. Shared system record: the product owner completes the shared core once. Both analyses start only when it is complete and versioned.
3. Parallel analysis: the risk owner and the impact assessment owner work at the same time, in one review meeting where possible. Evidence such as bias tests and red team results is requested once.
4. Cross-feed: every impact rated serious becomes at least one entry in the risk register (legal, regulatory or reputational), linked back to the impact record. Every risk with a consequence for people outside the organisation is checked against the impact section.
5. Joint mitigation plan: one list of measures, each tagged with the risks and impacts it reduces, so a single change, such as adding human review, is tracked once.
6. Two decisions: the business owner accepts residual organisational risk; the impact assessment owner records whether the impacts are justified, with governance review for high-impact uses. Neither signature substitutes for the other.
7. Regulatory steps: notify the FRIA result where Article 27(3) applies, file the DPIA, and publish where a scheme requires it. Canada's Directive on Automated Decision-Making, for example, has departments publish final Algorithmic Impact Assessment results on the Open Government Portal.
8. Monitoring and re-trigger: one trigger list for both, covering model and provider changes, new tools, new user groups, incidents and monitoring thresholds. A reassessment updates the shared core first, then whichever analysis the change touches.

For agents, use the AI Agent Risk Assessment Template as the risk section; its autonomy and permission dimensions also tell the impact owner which actions can reach people outside the organisation.

Decision criteria: depth, ownership and organisation size

Small organisations can use a single document with a shared core and two clearly headed analysis sections, owned by two named people even if one team runs both. Large organisations usually keep the risk section in the enterprise GRC platform and the impact record in the AI governance system, linked by the AI inventory identifier from the AI Register and AI Inventory Template, with responsibilities set out in the AI Governance RACI Template.

Worked scenario

A housing association plans to deploy a model that prioritises repair requests by predicted urgency, and an agent that books contractors. It provides a public service.

1. Screening: output affects access to an essential service for tenants, including vulnerable people, and personal data is processed. Result: full risk assessment, full impact assessment, DPIA, and a check on whether the system falls within a high-risk category that would require a FRIA.
2. Shared core: the product owner documents the model, the repair data, the contractor booking tool and its permissions, the volume of requests and the human review step for low-priority decisions.
3. Risk analysis: the risk owner records agent misuse of the booking tool, data leakage through contractor messages, supplier model changes and regulatory exposure. Residual risk is medium after scoped credentials and spend limits.
4. Impact analysis: the impact owner, with a tenants' panel, finds that tenants who report in plain or non-native language receive lower urgency scores, and that tenants without online access cannot see or challenge the priority.
5. Cross-feed: the language effect is added to the risk register as a regulatory and reputational risk, raising the residual risk to high until fixed.
6. Joint mitigations: human review of all scores below a threshold for safety-related categories, a telephone route to challenge priority, and disaggregated monitoring of scores by reporting channel and language.
7. Decisions: the business owner accepts residual risk once mitigations are in place; the impact owner records the justification and a review after three months of monitoring data.

Run separately, the risk assessment would have passed the system as medium risk, and the impact finding would have sat in a form nobody linked to the register.

Where identity fits

For agents, the permissions held by their non-human identities decide which impacts are possible: an agent that can only draft cannot deny a service, while one that can update records or send messages can. Record the agent's identities, scopes and approval steps in the shared core so both analyses work from the same facts, and reassess when scopes change. See the Agentic AI Risk Assessment Template.

Detection and measurement

• Screening coverage: percentage of AI inventory entries with a completed screening record.
• Paired completion: percentage of systems that require both assessments where both are complete before first use.
• Cross-feed rate: share of serious impacts that have a linked risk register entry.
• Reassessment latency: days from a trigger event, such as a model change, to an updated record.
• Consultation coverage: share of full impact assessments with documented affected-group input.

Monitor the post-deployment signals that feed both: complaint and challenge volumes, disaggregated outcome data, incidents and supplier change notices. NIST AI RMF MANAGE 1.4 asks that negative residual risks to downstream acquirers and end users be documented, which is the point where monitoring feeds back into both records.

Framework mapping

See the ISO/IEC 42005 AI System Impact Assessment Guide and the ISO/IEC 23894 AI Risk Management Guide for each standard in depth.

Common failure patterns

• Two forms, two system descriptions. They drift apart, and auditors find different model versions in each. Keep one shared core.
• Impact folded into risk scoring. Harm to people becomes one line of reputational risk and loses its owner and its consultation.
• Risk folded into impact. Security and supplier risks are listed as impacts with no treatment owner or register entry.
• One signature for both. The business owner who benefits from the system also declares the impacts justified, with no independent review.
• Separate trigger lists. A model change reopens the risk assessment but not the impact record.
• Legal assessment as the only impact assessment. A DPIA or FRIA is done where required and nothing is done for systems below the legal threshold that still affect people.

Practitioner checklist

• Use one intake and screening form that decides both assessment depths and any FRIA or DPIA.
• Build a versioned shared system record and make both analyses reference it.
• Name a risk owner and an impact assessment owner for every in-scope system.
• Run both analyses in parallel and request test evidence once.
• Turn every serious impact into a linked risk register entry.
• Keep one mitigation list tagged by the risks and impacts each measure reduces.
• Record two decisions: residual risk acceptance and impact justification.
• Consult affected groups or their representatives for full impact assessments.
• Use one trigger list for reassessment, including provider model changes and new agent permissions.

Standards and references

• ISO: ISO/IEC 42005:2025 AI system impact assessment
• IEC: ISO/IEC 42001:2023 preview (clause structure)
• European Commission AI Act Service Desk: Article 27 Fundamental rights impact assessment for high-risk AI systems
• European Commission AI Act Service Desk: Article 9 Risk management system
• NIST: AI Risk Management Framework Core
• ICO: When do we need to do a DPIA?
• Government of Canada: Algorithmic Impact Assessment tool

Related NHI Mgmt Group resources: AI Risk Assessment Guide, AI Impact Assessment Template, DPIA Guide: Running a Data Protection Impact Assessment, ISO/IEC 42001 Guide, AI Governance Guide. This guide summarises legal and standards requirements and is not legal advice.