AI Impact Assessment Checklist Template

Start about ten working weeks before the planned deployment date, the day the system is first used on real cases: every due date counts from it in working days. The first task names the five people and asks whether this is a first assessment, and whether the system processes personal data; each answer adds the tasks it needs. A later task asks whether Article 27 of the EU AI Act applies.

• Set up the AI impact assessment — the organisation, the AI system and the use being assessed, whether this is a first assessment or a reassessment, the planned deployment date, whether the system processes personal data, and the five people; later tasks are assigned from these fields
• Review the last assessment and what has changed — the last assessment and its decision, conditions still open, incidents, complaints and monitoring results since, and what has changed in the model, the data, the use or the people affected
• Agree the scope and the plan — what is in and out of scope, the timetable back from the deployment date, who will be consulted, and where the evidence for each task is kept
• Check which laws, policies and frameworks apply — your AI policy and risk appetite, data protection law, whether the EU AI Act applies to this use and whether its Article 27 asks for a fundamental rights impact assessment (FRIA), sector rules, and any framework you follow, such as ISO/IEC 42001 or the NIST AI RMF
• Screen the processing for a DPIA — whether the processing is likely to result in a high risk to people’s rights and freedoms, using the regulator’s list of processing that needs a DPIA; if you decide a DPIA is not needed, record how you decided
• Get advice on whether Article 27 applies — ask your legal or compliance adviser whether the system is high-risk under Annex III, whether your organisation is a deployer that Article 27 names, and from when it would apply. Record the advice and who gave it here, complete this task, then add the advice to the laws and frameworks answer on the task above and change the Article 27 answer there: changing that answer hides this task

The AI system owner writes down what the system is for and how it will be used, before anyone judges its effects. The NIST AI Risk Management Framework starts in the same place: its MAP 1.1 asks for intended purposes, uses and settings to be understood and documented.

• Describe the system’s purpose and the problem it solves — what the system does, the task or decision it supports, why AI is being used for it, and the benefits expected, for whom
• Record the intended use and the uses ruled out — the intended users, where and when it will be used, the uses it must not be put to, and the misuse you can foresee
• Describe the process the system sits in — the steps before and after it, who acts on its output, how often it will be used and for how long, and what the process looked like without it
• Set the level of automation — whether the system suggests, drafts, ranks or decides; whether a person checks every output before it takes effect; and which outcomes could have a significant effect on someone
• Record the alternatives considered — the process without AI, a simpler model or rules, a narrower use, and why this option was chosen

Identify everyone the system could affect, including people who never use it, and hear from them or their representatives before the impacts are judged. The route for complaints and challenges is set up here so it exists before the first case.

• Identify the people and groups affected — the users, the people the output is about, groups who could be affected differently (for example by age, disability, language or where they live), and staff whose work changes
• Plan how the people affected will be heard — who will be asked (users, staff, the people the output is about or their representatives), how, in what accessible formats, and by when
• Hold the engagement and record what was said — what people said, the concerns raised, what will change because of them, and what will not, with the reason
• Set up the route to question or challenge an outcome — how someone affected can ask how an outcome was reached, ask a person to look again, or complain, and who answers and how fast

The technical lead records where the data and the model come from and what the system cannot do, then tests it for the people identified in Phase 3. Where the system processes personal data, the DPIA runs alongside.

• Record the data sources and where they came from — the data used to train, fine-tune or ground the system and the data it will see in use: the source, the owner, the licence or legal basis, its quality, and how well it represents the people affected
• Record the model and its supplier — the model and version, the supplier, the supplier’s documentation and instructions for use, what the supplier tested, and what the contract says about your data and changes to the model
• Document what the system cannot do — known limits, conditions where it performs poorly, languages or inputs it does not handle, and how its output should be read and checked by people
• Agree the tests before use — accuracy overall and for each group in Phase 3, bias, how it handles unusual inputs, security and misuse tests, and the result each test must reach before deployment
• Run the DPIA alongside this assessment — the DPIA for the personal data the system processes, run with your DPIA process; record its reference and the risks it found that this assessment should carry
• Run the tests and record the results — each test, the result for each group, whether it met the agreed result, and what will be done about any that did not

Judge the system’s effects on individuals, groups and society, harmful and beneficial, from the evidence in Phases 2 to 4. Each impact goes into one register with its likelihood, severity and owner, which Phase 6 works from.

• Assess fairness and discrimination — whether outcomes differ between groups, whether any input stands in for a protected characteristic, and the equality duties that apply to your organisation
• Assess safety and what happens when it is wrong — the errors the system can make, what each would mean for the person affected, the worst credible case, and how quickly an error would be noticed
• Assess privacy — what the system learns or infers about people, whether it uses more data than it needs, and how long inputs and outputs are kept
• Assess the effect on people’s rights and access to services — whether the system could affect someone’s access to a service, money, work or housing, their ability to understand and challenge an outcome, or other rights
• Assess transparency and explanation — whether people know AI is used, whether staff can explain an outcome in plain words, and what records show how an outcome was reached
• Assess wider effects on staff, society and the environment — changes to jobs and skills, dependence on one supplier, the energy and computing the system uses, and effects on groups beyond the people it serves
• Rate each impact in the impact register — every impact found in this phase, harmful or beneficial, with the group affected, its likelihood and severity, a rating and an owner

Decide how people will oversee the system, what reduces each significant impact, what people are told, how the system is paused, and what is watched once it is live. What is left after all of that is the residual impact the approver accepts or not.

• Design the human oversight — who checks the system’s output and when, how they overrule it, the training they need, and how you guard against people accepting its output without checking
• Agree a response for each significant impact — for each impact rated medium or high: avoid, reduce, transfer or accept it, the measure, its owner and its date
• Write what people will be told — the notice to the people affected that AI is used and how to question an outcome, and the guidance for staff who use the system
• Plan how to pause or switch off the system — who can pause it, what would make them do so, how work carries on without it, and how the people affected are told
• Set the monitoring measures and review triggers — what is measured in use (accuracy, results by group, overrides, complaints, incidents), how often, who looks, and the events that trigger a reassessment
• Bring the DPIA outcome into the decision — the DPIA signed off, its measures included in Phase 6, and, if it shows a residual high risk you cannot sufficiently reduce, prior consultation with the data protection regulator before the processing starts
• Record the residual impacts — what remains after the measures, who carries it, and why it is acceptable or not, for the approver to decide on

Applies only when the answer on Check which laws, policies and frameworks apply is Yes. Article 27 of the EU AI Act asks the deployers it names to assess the impact on fundamental rights before first using a high-risk AI system, and to notify the market surveillance authority of the results.

• Complete the six FRIA elements in Article 27(1) — the deployer’s processes, the period and frequency of use, the people and groups likely to be affected, the specific risks of harm (using the provider’s information under Article 13), the human oversight measures, and the measures if risks materialise, including internal governance and complaints
• Cross-refer the DPIA where it already covers an element — where a DPIA already meets one of the FRIA obligations, include cross-references to the relevant sections of the DPIA or the relevant parts of it, rather than writing them twice
• Fill in the AI Office’s FRIA questionnaire template — check whether the AI Office has published the questionnaire template Article 27(5) asks it to develop, and if so fill it in from the FRIA
• Notify the market surveillance authority of the results — send the results to the market surveillance authority, with the filled-out template, and record the date; Article 46(1) cases may be exempt

Someone who did not build or buy the system reviews the assessment, and the approver decides. The decision halts the checklist: nothing after it can be completed until the approver completes it. Approved with conditions adds a task to meet them before first use; Not approved shows a rework task and hides Phase 9.

• Review the assessment independently — whether every impact is evidenced, the ratings are reasonable, the measures match the impacts and nothing in Phases 1 to 7 is missing; write each point for the owner to answer
• Answer the reviewer’s points — each point answered or the assessment changed, confirmed with the reviewer
• Rework the assessment or stop the project — what the approver asked for, the changes made or the decision to stop, and a new deployment date if the system goes ahead
• Decide whether to deploy the system — Approved, Approved with conditions or Not approved, with the reasons and the residual impacts accepted; complete this task with the decision

After an approval, the owner meets any conditions, tells people, files the assessment and checks the first weeks of use. The first review about a month after deployment compares what happened with what was assessed and sets the next review.

• Meet the approver’s conditions before first use — each condition met, with its evidence, confirmed with the approver
• Brief staff, publish the notices and file the assessment — staff trained on the oversight and the pause plan, the notice live where the people affected will see it, and the assessment filed in your AI register or inventory
• Check the first two weeks of use — the monitoring measures against the assessment, overrides, complaints and incidents, and anything that needs action now
• Hold the first review after deployment — results by group, overrides, complaints, incidents and the impact register compared with what was assessed; update the register and act on anything new
• Set the next review and close this run — the date of the next periodic review, the owner of the monitoring, and the assessment and its evidence filed together