AI impact assessment

It is the intake step that lets you tier risk: routine uses pass quickly, high-stakes ones get real scrutiny. Skip it and you are approving AI by vibes, with no record of what was weighed.

The question it answers is not “is this AI safe” but “who is affected, and what happens to them when it is wrong”. That framing does most of the work. A model summarizing internal meeting notes and a model ranking job applicants may use identical technology, and the second one changes someone’s livelihood on the basis of an output nobody can fully explain. Assessing the use case rather than the tool is what separates this from vendor security review, which asks a different and less important question.

A workable assessment stays short. Name the use case and the decision it influences, identify who is affected and whether they have any recourse, describe the data going in and where it came from, state what happens when the output is wrong and how anyone would notice, and record the human oversight actually in place rather than the oversight the policy imagines. Most use cases clear that in an afternoon, which is the point: the process has to be cheap enough that teams use it rather than route around it into shadow AI.

It is also increasingly the artifact regulators ask for. The EU AI Act requires a fundamental rights impact assessment for certain high-risk deployments, and ISO/IEC 42001 expects an AI system impact assessment as part of the management system, so building the habit early tends to satisfy several obligations at once.