How to Run an AI Risk Assessment: Free Template for UK Employers

Last updated: 15 July 2026

Download the Free AI Risk Assessment Template

Start with the free AI risk assessment template for UK employers. The CSV includes 41 fields, inherent and residual risk formulas and six fictional worked rows covering CV screening, customer reply drafting, workforce training analytics and AI-assisted learning content.

An AI risk assessment is useful only if it changes a decision. It might narrow a use case, require stronger testing, define a real human-review point, create role-specific training, delay deployment, establish a pause threshold or stop a system that cannot be made acceptable. A polished document that approves the original plan without challenge is governance theatre.

What an AI Risk Assessment Is—and Is Not

An operational AI risk assessment records how a specific system, in a specific organisational use, could cause harm or failure and what the organisation will do about it. The words specific organisational use matter. A general-purpose model used to draft internal meeting agendas has a different risk profile from the same model used to summarise candidate interviews or recommend customer eligibility.

The UK government's 2026 consultation version of AI Management Essentials asks organisations about maintaining AI system records, impact and risk assessments, organisational risk thresholds, monitoring, failure response, data protection and communication. The ICO's AI guidance focuses in more depth on risks to people, governance, data flows, accountability, human involvement and meaningful review. Together, those themes point to an assessment that is owned, evidenced and maintained across the system lifecycle.

An AI risk register should sit alongside, and link to, the rest of the organisation's controls:

• enterprise and operational risk management
• data protection and DPIA processes
• equality, accessibility and human-rights review
• information security and supplier assurance
• legal, HR, safety and sector-specific governance
• workforce policy, training and incident response

Step 1: Scope the Actual Use Case

Do not begin with “We use Copilot” or “We use an applicant tracking system.” Those are products, not use cases. Start with the action and outcome:

• draft customer replies from case notes for an adviser to review
• rank applications against published job criteria before recruiter shortlisting
• flag employees who may not complete mandatory learning for manager follow-up
• draft internal compliance training from an approved source pack

Then record the system owner, supplier, lifecycle stage, decision or output, people affected and data involved. Ask what happens immediately before and after the AI step. A model may only produce a recommendation, but that recommendation can still shape who receives scrutiny, opportunity, service, work or support.

Map the people, not just the user

The person operating the system is not always the person exposed to risk. A recruiter uses a ranking tool; an applicant is affected. An L&D analyst uses a completion predictor; an employee may receive a manager intervention. A customer-service adviser uses a reply copilot; the customer relies on the resulting information.

Include people who could be affected indirectly, people who may face accessibility barriers and people who need a route to question or correct an outcome.

Record the lifecycle stage

Design, procurement, pilot and live operation require different evidence. Before procurement, the organisation may be assessing supplier claims and data flows. During a pilot, it should be generating its own performance evidence. In live use, it needs monitoring, incident response and review triggers. A register that says “approved” without lifecycle context becomes stale quickly.

Step 2: Write One Testable Risk per Row

A useful risk statement connects a cause, an event and a possible harm:

Because historic or proxy data is used, the system may rank otherwise suitable applicants differently between groups, leading to lost opportunity, discrimination, complaint and regulatory or reputational harm.

Compare that with “Risk of bias.” The shorter statement names a topic but does not tell the team what to test, control or monitor.

Common AI risk categories

• Fairness and discrimination: unequal performance, proxy variables, inaccessible processes or amplified historic patterns.
• Privacy and confidentiality: excessive data, unclear supplier processing, insecure prompts, retention or unintended disclosure.
• Accuracy and safety: invented facts, missed cases, unreliable classifications or confident output outside the intended domain.
• Transparency and contestability: people do not understand AI involvement, cannot correct input or cannot challenge an outcome.
• Human autonomy and oversight: automation bias, reviewer fatigue, unclear responsibility or nominal sign-off without power to intervene.
• Security and misuse: prompt injection, data exfiltration, unauthorised access, harmful use or model and supplier compromise.
• Intellectual property and provenance: unlicensed inputs, untraceable claims or output that cannot be attributed or verified.
• Operational resilience: supplier outage, model change, silent degradation or loss of the manual fallback.

Use the same system ID on multiple rows. The free template demonstrates this with separate privacy and accuracy risks for one customer-reply copilot. Different harms usually need different owners, controls, metrics and decisions.

Step 3: Score Inherent Risk Before Controls

The template multiplies likelihood and impact on a 1-to-5 scale. That gives an inherent score before controls and a residual score after controls. Its default ranges are:

• 1–4: Low
• 5–9: Medium
• 10–14: High
• 15–25: Critical

These ranges are a configurable starting point, not an official UK regulator rating system. Map them to your existing enterprise risk language, approval authority and appetite.

Score harm to people as well as the organisation

Reputational, financial and operational impact matter, but they are not the whole assessment. Consider lost opportunity, discrimination, privacy intrusion, distress, unsafe service, inability to challenge a decision and effects on vulnerable people.

Do not let false precision hide uncertainty

A score of 12 is not scientifically more certain than a score of 15 because it appears in a spreadsheet. Record assumptions and evidence. If the team lacks representative test results or reliable incident data, say so and treat the uncertainty as an action rather than inventing confidence.

Step 4: Design Controls, Human Oversight and Training Together

A control should be specific enough to test. “Staff will check the output” is weak. “The panel chair compares every AI-generated interview summary with the original notes before the panel scores the candidate, can correct or reject the summary and records material changes” is testable.

Make human oversight meaningful

The ICO says a DPIA should identify and record the degree of human involvement and the stage at which it occurs. Where automated decisions are reviewed, processes should make that review meaningful and reflect that decisions can be overturned.

For each human-review control, define:

• Who: a named role with appropriate competence and independence.
• When: before the output affects a person, not as a retrospective sample after harm.
• What evidence: original source material, uncertainty, model or supplier information and relevant policy.
• What authority: ability to correct, reject, pause, escalate or use a manual route.
• What time: a workload that permits actual review rather than automatic acceptance.
• What record: overrides, reasons, incidents and patterns that can improve the control.

Turn every people-dependent control into a training requirement

If a control depends on employee judgement, the risk assessment should state who needs which capability. Training should cover the particular use case rather than generic AI awareness.

For a recruitment ranking tool, recruiters and hiring managers may need training on intended use, prohibited use, proxy discrimination, reasonable adjustments, output interpretation, evidence-based override and applicant escalation. For a customer reply copilot, advisers may need approved-data boundaries, source verification, restricted topics, uncertainty, safety escalation and incident reporting.

Record the training audience and content in the AI register, then use the employee training matrix template to track completion, evidence, renewal and action. This creates a traceable path from identified risk to workforce capability.

Choose monitoring that could prove the control failed

“Monitor performance monthly” is not a metric. Examples include:

• selection and override rates reviewed for material differences between applicant groups
• substantive error rate in a random sample of AI-drafted replies
• recall of safety escalations in a controlled test set
• false-positive and override rates for a workforce risk flag by role and site
• percentage of compliance claims linked to approved, current sources

Step 5: Route the Other Assessments

The template includes fields for DPIA and equality-assessment status because these processes need to be visible. A status field is not the assessment itself.

Data protection

Use the ICO's AI and data protection risk toolkit and current DPIA guidance to decide and document the appropriate process. AI systems may involve complex data flows, supplier roles, profiling, sensitive data, explainability and decisions that affect people. Link the completed or in-progress DPIA from the register and record who owns unresolved privacy actions.

Recruitment and employment

DSIT's Responsible AI in Recruitment guidance highlights risks including bias, digital exclusion and discriminatory targeting. It recommends considering impact assessments, data protection, employee capability and effective human oversight. Recruitment AI should therefore involve appropriate HR, equality, accessibility, privacy, legal and applicant perspectives rather than being treated as an IT purchase alone.

Security, supplier and sector assurance

Link threat modelling, access and data-flow review, supplier documentation, incident terms, business continuity and performance testing. Add any sector regulator, professional, safety or procurement process that applies to the use case. If an assessment is screened out, record the reason and approver; do not leave the field blank and assume it was considered.

Step 6: Score Residual Risk and Make a Real Decision

Reassess likelihood and impact after controls are operating and evidenced. Planned training, an unsigned supplier addendum or an unbuilt appeal route should not reduce the residual score yet.

Choose an explicit treatment:

• Reduce: add or strengthen controls and test their effectiveness.
• Avoid: do not start, narrow or pause the use while unacceptable risk remains.
• Transfer: contract or insure part of the exposure without assuming accountability disappears.
• Accept: a properly authorised decision within the organisation's appetite, with reasons and monitoring.

The approval should say more than yes or no. Useful outcomes include approved for a time-limited pilot, approved with controls, awaiting privacy review, not approved or paused after a threshold breach. Record who approved it, the evidence they saw and the date of the next review.

A worked decision: customer reply copilot

The template treats one reply copilot as two risks. The privacy row controls approved tenancy, supplier terms, access, retention, data minimisation and logging. The accuracy row controls source grounding, restricted topics, adviser review, quality sampling and safety escalation.

That separation matters. A strong data-processing agreement does not stop a fluent but wrong refund answer. Human review does not by itself resolve excessive supplier data retention. Each risk needs the control that addresses its cause and harm.

Step 7: Monitor, Review and Know When to Stop

AI systems, suppliers, models, users, data and organisational workflows change. Review on a calendar and when an event changes the risk.

Useful review triggers include:

• a new model, supplier, data source, integration or purpose
• material performance drift or unexplained group differences
• a complaint, appeal, override pattern, privacy incident or harmful output
• employees using the system outside its intended scope
• control evidence missing or mandatory training becoming overdue
• new law, regulator guidance, contract or sector requirement
• loss of a fallback, reviewer capacity or key supplier assurance

Define thresholds that trigger escalation or pause. Examples might include a safety-critical miss, unauthorised sensitive-data disclosure, an unresolved material performance difference or loss of meaningful human review. The correct threshold depends on the use case and your obligations, but it should exist before an incident tests it.

AI Risk Assessment Checklist

• The use case describes an action and outcome, not just a product name
• A named business owner is accountable across the lifecycle
• People affected include non-users and those needing accessibility or challenge routes
• Each row contains one cause-event-harm risk statement
• Inherent risk is scored before controls
• Human review has a role, stage, evidence, time and authority
• People-dependent controls create specific training requirements
• DPIA, equality, security, supplier and sector reviews are linked where relevant
• Monitoring uses a defined metric and cadence
• Residual scores reflect operating controls, not promises
• Approval, treatment, action owner, due date and review date are recorded
• Pause and escalation conditions are known before deployment

A good AI risk assessment does not prove that a system is risk-free. It gives the organisation a defensible way to decide what it will use, what it will not use, how people remain protected and capable, and what evidence will cause the decision to change.