Conducting an AI system impact assessment

test1

The shift in perspective

Security risk assessment asks what could harm the organisation. Privacy risk assessment asks what could harm the data subject. AI impact assessment asks what the system could do to individuals, to groups, and to society.

Organisations extending an existing risk process usually carry over the organisational perspective, which is the defining failure. If your assessment output is a list of reputational, regulatory and financial risks, you have written a business risk register and called it an impact assessment.

Step 1: Establish what the system decides or influences

For each AI system, describe precisely what it does in terms of consequences for people.

Not classifies documents, but determines which applications proceed to interview. Not scores accounts, but influences whether a customer receives credit. Not suggests responses, but drafts communications sent to customers under our name.

The precision matters, because it determines who is affected and how much.

Step 2: Identify who is affected

Users of the system. People the system makes decisions about, who are frequently not users. Groups who may be affected differently from others. People affected indirectly.

The people the system decides about are the central subject of the assessment and the ones organisations most often omit, because they are not the customer and not in the room.

Step 3: Assess across the relevant dimensions

Fairness. Could the system produce systematically different outcomes for different groups. What data was it developed with, and is that data representative of the population it will be applied to. Has this been tested rather than assumed.

Safety. Could an incorrect output lead to physical, financial or psychological harm, and how severe.

Privacy. What personal data is used, on what basis, and could outputs reveal something about a person that was not provided.

Transparency and explainability. Do affected people know the system is being used. Can a decision be explained to the degree the consequence warrants.

Contestability. Can an affected person challenge an outcome, and to whom.

Accessibility. Does the system work for people with disabilities, and for people who differ from the population it was developed on.

Environmental impact, where the scale of the system makes it material.

Not every dimension applies to every system. Record which you considered and why any were not relevant.

Step 4: Consider severity, and who bears it

Assess consequences by severity and likelihood, as in any assessment, with one addition: record who bears the consequence.

A system where the organisation carries the risk is different from one where the affected individual carries it and has no recourse. That asymmetry is the reason the standard asks for this assessment separately, and it should be visible in the output.

Step 5: Determine controls proportionate to impact

Human oversight, calibrated to consequence. Testing for differential performance across groups. Transparency to affected people. A route to contest. Restrictions on use case. Monitoring in operation. In some cases, not deploying the system.

Controls should be traceable to the impacts they address, exactly as in any risk treatment.

Step 6: Make human oversight real

This is where most impact assessments end, and where most fail.

Oversight requires the person to have the information needed to disagree, the time to consider it, the competence to judge it, and the authority to override. A reviewer processing a hundred recommendations an hour with no visibility into why the system recommended each is not oversight, and auditors will establish this by asking them.

Specify all four elements when you define oversight for a system.

Step 7: Reassess

On change to the system, to its data, to its use case, to the population it is applied to, or after an incident. Also periodically regardless, because drift occurs without any change on your side.

Record the reassessment even when conclusions are unchanged.

Common weaknesses

1. Assessment written from the organisation's perspective
2. People the system decides about not identified as affected parties
3. Fairness assumed rather than tested against representative data
4. No route for an affected person to contest an outcome
5. Human oversight specified without information, time, competence or authority
6. No reassessment after use case expansion
7. Systems embedded in purchased tools never assessed at all
8. Assessment conducted once at deployment and never revisited

---

---

House notes

• Author on all eight: Neha Dvivedi
• No em dashes anywhere in this document
• Each piece should link to the ISO 42001 service page before publishing
• Created as draft, awaiting review
• Verification needed. News 1 describes the general shape of AI regulation, that it classifies systems by risk and attaches obligations by class and by role, without naming any statute, article or date. This is deliberate. AI legislation is being implemented in stages across several jurisdictions and the detail changes. If you want to reference the EU AI Act or any national framework specifically, have counsel write or check those lines.
• ISO 42001 is the newest standard on the site. Article 1 says so plainly and notes that fewer certification bodies offer it and that interpretation is still settling. Confirm current certification body availability before quoting timelines to a client.