How to run an AI impact assessment

When an AI system needs an impact assessment

Not every system warrants a full assessment, so the first judgment is proportionality. A system that makes or materially informs a decision about a person, that processes sensitive data, that operates with limited human oversight or that carries reputational or safety exposure warrants a full assessment. A low-stakes internal tool may warrant a short one. Guardrail 2 of the Voluntary AI Safety Standard asks you to run a risk management process across the AI lifecycle, and the impact assessment is where that process produces a decision on the record. Deciding the depth is itself a governance call, so record why a system was scoped up or down.

Step 1: Describe the system and its purpose

An assessment that starts vague ends vague. Write down what the system is, what it does, the decision or task it supports, the data it uses and the context it runs in. ISO/IEC 42005 frames this as establishing the scope and the intended use before you weigh anything, because the same model carries different risk in a marketing tool and in an eligibility decision. Name the model or vendor, the version and where the system sits in a process, so the reader of the assessment knows exactly what was assessed.

Step 2: Identify who is affected and how

Impact runs to people, not only to the organisation. List the groups the system touches, meaning the customers, the employees, the applicants and the members of the public, and describe how each could be affected if the system works as intended and if it fails. Guardrail 7 asks you to give people affected by AI a way to challenge its use or its outcomes, which starts with knowing who they are. Pay particular attention to groups who could be affected unequally, because a system that performs well on average can still fail a subgroup, and that failure is where the harm and the exposure concentrate.

Step 3: Weigh the risks against the benefit

For each way the system could cause harm, describe the harm, judge how likely and how serious it would be, then set that against the benefit the system delivers. This is the core of the assessment and it is a judgment, not a calculation. Do not reduce it to a number that hides the reasoning. ISO/IEC 23894 describes AI risk in terms of both the likelihood and the severity of consequences, and an assessment that records both, in plain terms, is one an outside reader can follow and challenge. Where a risk is material and unmitigated, say so plainly rather than softening it.

Step 4: Decide the controls the use needs

An assessment that identifies risk and stops is half done. For each material risk, decide the control that brings it to an acceptable level, whether that is human review of the system’s output, a limit on what it can do, a monitoring measure, a disclosure to affected people or a decision not to proceed. Guardrail 5 asks for meaningful human oversight, so be specific about where a person sits in the loop and what they can actually change. The test of a control is whether it would work in practice, not whether it reads well on the page.

Step 5: Record the decision, its owner and its review point

The assessment is only a control once someone owns the decision it produced. Record who assessed the system, who accepted the residual risk on behalf of the organisation and when the assessment falls due for review. Guardrail 9 asks you to keep records that let a third party assess how you have governed the system, and the impact assessment is one of the records that matters most. A system changes, its data drifts and its context moves, so an assessment with no review date is a snapshot that quietly goes stale.

What a defensible AI impact assessment contains

• A clear description of the system, its purpose, its version and where it runs.
• The people and groups affected, and how each could be affected if the system works and if it fails.
• The risks and harms, each with a judgment on likelihood and severity, set against the benefit.
• The controls chosen for each material risk, specific enough to be tested.
• The named owner of the decision, the residual risk accepted and the review date.

Frequently asked questions

Is an AI impact assessment the same as a privacy impact assessment? No, though they overlap. A privacy impact assessment, which the OAIC describes in its guidance, looks at how a project handles personal information. An AI impact assessment is broader, covering safety, fairness, oversight and the effect on people beyond privacy. Where an AI system processes personal information you may need both, and they should reference each other rather than repeat.

Do we need to assess vendor AI we did not build? Yes. The obligation attaches to the organisation deploying the system, not only to the one that built it. A model embedded in vendor software still makes or informs decisions in your process, so it warrants the same assessment as a system you built, adjusted for what the vendor will tell you about it.

How often should an assessment be revisited? On a set cadence and on a trigger. Set a review date proportionate to the system’s risk, and revisit sooner when the system, its data or its context changes materially. An assessment done once at procurement and never revisited is the finding an auditor lands on most often.

Does Aicura decide whether a system is acceptable? No. Aicura carries the assessment and holds the record of the decision. It does not assess your systems for you, score the risk or decide whether a use is acceptable. The accountable owner makes that call and answers for it.

Where Aicura fits

Aicura is your AI Register. It holds the AI systems in use as the record and versions each one as it changes, so the assessment starts from a real population rather than a list someone remembered to keep. Impact Assessments carry the risk work for the systems that warrant it and sit against each system as the record of the decision, its owner and its review date, and Aicura prompts you when a review falls due. Incidents give you the place to log when a governed system behaves in a way the assessment did not anticipate, so the assessment and the reality stay connected.

The Evidence Vault seals each assessment so it can be shown unchanged since the date on it, evidence you don’t have to trust us for, cryptographically anchored and verifiable without Aicura in the loop. Attestation lets the accountable owner sign the decision against the record. Aicura carries the work and holds the evidence. It does not assess your systems, score the risk or decide whether a use is acceptable. You make the call.

For the related work, read how to govern AI that acts and what counts as AI audit evidence. If you are measuring the wider program, ISO 42001 readiness sets out where impact assessments sit in the management system. The AI governance software overview sets out what Aicura supports.

Sources

• ISO/IEC 42005, AI system impact assessment, International Organization for Standardization, iso.org
• Voluntary AI Safety Standard, Department of Industry, Science and Resources, industry.gov.au
• ISO/IEC 23894:2023, AI risk management guidance, International Organization for Standardization, iso.org
• NSW Government AI Assessment Framework, digital.nsw.gov.au
• Guide to undertaking a privacy impact assessment, Office of the Australian Information Commissioner, oaic.gov.au

A note on this page

This guide is general information on how to run an AI impact assessment against current Australian and international guidance. It is not legal advice and it does not tell you whether a particular system or use meets a particular obligation. For how the guidance applies to your organisation, read the primary sources above and take your own professional advice.