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 judgement 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. ISO/IEC 42001 requires an AI system impact assessment as part of an AI management system (clause 6.1.4), and ISO/IEC 42005:2025 gives the guidance on how and when to do it across the life cycle. 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, along with reasonably foreseeable misuse, 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. Note whether the people affected have a way to challenge the outcome, because that is often the control that matters most. Pay particular attention to groups who could be affected unequally. 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 harms 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 judgement, 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 harm is material and unmitigated, say so plainly rather than softening it.

Step 4: Decide the controls the use needs

An assessment that identifies harm and stops is half done. For each material harm, decide the control that brings it to an acceptable level. That might be 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. Be specific about where a person sits in the loop and what they can actually change, because “human oversight” with no authority to override is not oversight. 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. ISO/IEC 42005 expects the result to be documented and retained, and it is one of the records an auditor or regulator asks for first. 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 harms, each with a judgement on likelihood and severity, set against the benefit.
• The controls chosen for each material harm, specific enough to be tested.
• The named owner of the decision, the residual risk accepted and the review date.

Where the law requires one

Some jurisdictions make an impact assessment a legal duty for certain uses. Under the EU AI Act, Article 27 requires certain deployers of high-risk systems, meaning the organisations using them, to carry out a fundamental rights impact assessment before first use. That covers public bodies, private entities providing public services, and deployers using AI for creditworthiness or for life and health insurance pricing. The Annex III high-risk obligations apply from 2 December 2027, after the Digital Omnibus amendment moved the date. Where personal data is involved, a GDPR data protection impact assessment may also be required, and the two can share a record. Check the frameworks that apply to you.

In Australia

There is no general legal duty to run an AI impact assessment in Australia, but several sources expect one. The National AI Centre’s Guidance for AI Adoption (AI6, October 2025), published by the Department of Industry, Science and Resources, makes “Understand impacts and plan accordingly” one of its six essential practices. It superseded the Voluntary AI Safety Standard. NSW Government agencies use the NSW AI Assessment Framework. Commonwealth agencies work under the DTA’s policy for the responsible use of AI in government. The OAIC’s guidance on privacy impact assessments applies where personal information is handled. See the Guidance for AI Adoption and NSW AI Assessment Framework pages.

Where Aicura fits

Impact assessments are on Aicura’s Pro tier. Each one runs against a fixed version of the system’s record in the AI register, so Step 1 is already written when you start. It opens with an accountability section naming the system owner, executive accountable, privacy lead and external review, drawn from the register or noting what the register does not name, then drafts the rights affected and their mitigations for your people to work through. The accountable owner can sign the decision as a formal statement on the assessment.

The Cadence view, Aicura’s screen for recurring work, shows how long ago each system’s impact assessment was last done and marks it Aging or Stale, which is Step 5’s review point kept visible. Aicura drafts the work and holds the record. It does not decide whether a use is acceptable. You make the call.

Sources

• ISO/IEC 42005:2025, AI system impact assessment, iso.org
• ISO/IEC 42001:2023, AI management system, clause 6.1.4, iso.org
• ISO/IEC 23894:2023, AI risk management guidance, iso.org
• Regulation (EU) 2024/1689 (EU AI Act), Article 27, as amended by the Digital Omnibus on AI, eur-lex.europa.eu
• Guidance for AI Adoption, National AI Centre, Department of Industry, Science and Resources, industry.gov.au
• NSW AI Assessment Framework, digital.nsw.gov.au
• Guide to undertaking privacy impact assessments, 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 international and national 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.