AI impact assessment, and its three rivals

Four different assessments get called an AI impact assessment, and they have different triggers, different readers and different legal weight. Doing the wrong one is a common and expensive way to satisfy nobody.

Last reviewed 2026-09-01Written by Jacob Masse, TrazTech Inc.

An AI system impact assessment under ISO/IEC 42001 is the documented analysis of what your AI system could do to individuals, to groups and to society, required by clause 6.1.4 and operated under clause 8.4, with four Annex A controls behind it. It is not a privacy impact assessment, it is not the fundamental rights impact assessment the EU AI Act requires of some deployers, and it is not the Algorithmic Impact Assessment the Government of Canada requires of federal institutions. The four overlap in analysis and differ in everything else. Here is which one you owe, to whom, and what goes in it.

Which impact assessment does someone actually want?

If a Canadian customer says the words "AI impact assessment", they almost always mean the first row and have read it in a questionnaire. If a European customer says it, ask which one, because a deployer subject to Article 27 needs a specific document with a specific audience and your ISO deliverable will not substitute. The EU picture as it reaches a Canadian supplier is on the EU AI Act page.

What does ISO 42001 clause 6.1.4 actually require?

The clause requires you to establish a process for assessing the potential consequences for individuals, groups of individuals and societies, of AI systems throughout their life cycle, and to keep documented information on the results. Clause 8.4 makes you actually run that process, and Annex A adds four controls: the process itself, the documentation of assessments, assessment of impact on individuals or groups, and assessment of societal impacts as a separate item.

The separation of individual and societal impact is the part people skip and the part an auditor notices. Impact on an individual is a hiring model rejecting a candidate. Societal impact is what happens if every employer in a sector uses the same model and the same candidates are rejected everywhere. The second question has no counterpart anywhere in an ISO 27001 risk assessment, which asks only what could happen to your organization and its information.

ISO/IEC 42005 is the dedicated guidance standard for AI system impact assessment. It is not required and it is worth buying if this is new to you, because it supplies the structure that clause 6.1.4 leaves open.

What goes in the document?

There is no mandated template. What follows is what a stage 2 auditor asks to see, and it is close to what ISO/IEC 42005 suggests. Work through it per AI system or per coherent group of systems that share a purpose and a population.

0 of 0 sections drafted · Reset

• The system, its intended use, and the boundary of what you are assessing
• Your role for this system: developer, provider, deployer, or more than one
• Who is affected, including people who are not your customers and never chose to interact with it
• The data behind it, its provenance, and whether personal information is involved
• Plausible harms, named specifically rather than as the word bias, with likelihood and severity
• Whether any harm falls unevenly on a group, and how you would know if it did
• Societal impact, assessed separately, including what happens at scale
• Human oversight: who can override the system, on what information, and how quickly
• Measures taken for each significant harm, and the residual position after them
• What you will monitor in production, and the threshold that triggers a review
• Legal and regulatory considerations, including Law 25 automated decision duties where relevant
• Owner, date, approver, and the review trigger. An undated assessment is not documented information

How do you run one without it taking a quarter?

1. Pick the system your customers ask about. Not the easiest one. The first assessment teaches the organization what the exercise is for, and it teaches more if the stakes are real.
2. Get the right people in the room. The product owner, the engineer who knows what the model actually does, someone from legal or privacy, and someone who knows the domain it is deployed into. A security team on its own will produce a security document.
3. Describe the intended use in one paragraph, then the plausible misuse in another. Off-label use is where most of the harm sits, and writing down the intended use is what makes off-label use detectable.
4. Name harms as events, not categories. Not "fairness risk". Rather "a qualified applicant with an employment gap is scored below threshold and never reviewed by a person". You can measure the second one.
5. For each harm, record what you did and what is left. The residual position is the part auditors read, because a document where every harm is fully mitigated is a document nobody believed.
6. Set the review trigger before you close it. A model retrain, a new deployment context, a threshold change, or a fixed interval. Then put it in the change process so the trigger actually fires.

What does an impact assessment cost in Canada?

The consulting range assumes a small number of systems and a facilitator rather than a document factory. The internal hours are the real cost and they fall on people who are not compliance staff, which is why the first one takes three times as long as the fourth. Doing them yourself is entirely reasonable once you have seen one done properly, and the templates that come with a readiness engagement are usually worth more than the assessments themselves. The wider cost picture is on the ISO 42001 certification page.

When is this not worth doing?

If your only AI is a commercial assistant your staff use internally, a formal impact assessment on it is paperwork with no reader. The system affects your own employees, the vendor has already published more about the model than you could assess, and the useful controls are an acceptable use policy and vendor terms. Write half a page recording that you considered it and why the impact is limited, and spend the time on the inventory instead. That judgement, and where it stops holding, is the subject of who needs ISO 42001.

The counter-case is worth stating plainly too. Companies that skip the assessment because their system feels low stakes are usually the ones who have not asked who is affected beyond the paying customer. A support triage model that quietly deprioritises certain accounts is affecting people. If you cannot say who is affected without looking it up, the assessment is exactly the exercise you need.

Common questions