An AI risk assessment is a written review of what could go wrong when a named team uses a named AI tool for a named task, who owns each risk, and what would show that it had gone wrong. It is not the same exercise as classifying a system under the EU AI Act, which tells you which rules apply, not whether the tool will send a client file to the wrong person on Thursday.
To run one, assess each use case separately, not each tool. For every use case, check seven risks: confidentiality, accuracy, bias, over-reliance, review cost, vendor continuity and reputation. Give each risk one owner, a mitigation that changes how the work is done, and a signal you can observe. One page per use case is enough.
Search the term and nearly everything that ranks is about classification: is this system prohibited, high risk or minimal? That is a real question, and most UK companies answer it once. It is not the question an ops lead or COO is asking when a team wants Copilot switched on for Monday. This post covers the second exercise, the operational one, which is the one that prevents incidents.
What is the difference between a regulatory and an operational AI risk assessment?
A regulatory assessment asks which legal category an AI system falls into, and an operational assessment asks what could go wrong when a particular team uses it for a particular task. The EU AI Act sorts systems into risk tiers and attaches obligations to each tier. ivee covers those tiers in its guide to developing an AI policy, so they are not restated here.
The operational exercise is the one nobody forces you to do. The NIST AI Risk Management Framework, published on 26 January 2023 and intended for voluntary use, is organised around four functions: Govern, Map, Measure and Manage. It is a sound vocabulary, but it is written for organisations building and deploying AI systems, and a team buying Microsoft Copilot or ChatGPT Enterprise needs a shorter version at the level of a single use case.
In the UK there is a third exercise to be aware of. The ICO lists processing involving new technologies, including AI, among its examples of processing likely to result in high risk, and a data protection impact assessment is required where that is combined with another high-risk criterion. Whether one applies to your use case is a question for your data protection officer or counsel, and this post is not legal advice. The ICO's own guidance on AI and data protection, last updated on 15 March 2023, is under review following the Data (Use and Access) Act, so check the current version.
Why is the use case the unit of an AI risk assessment?
You cannot assess a tool in the abstract, only a tool used for a named task by a named role, because the same tool carries different risks in different hands. Microsoft Copilot summarising a published annual report and Microsoft Copilot drafting disciplinary letters from HR case notes are the same licence and the same model. The data, the consequences and the person who should be worried are completely different.
Write each use case as four parts: tool, task, role and data. “ChatGPT Enterprise, drafting renewal quotes, account managers, customer pricing” is a use case. “ChatGPT” is a product. If you cannot fill all four parts, you are not ready to assess it, and finding that out takes five minutes instead of a quarter.
How do you choose which AI risks to assess?
Choose risks that pass four tests: they occur in ordinary use, one named role can own them, a mitigation changes how the work is done, and something observable tells you when they have happened. A risk that fails the fourth test goes on a register and stays there, because nobody can tell whether it has materialised.
It happens in ordinary use, without an attacker or a rogue model.
One role can own it, not a committee.
The mitigation changes a step in the work, rather than adding a sentence to a policy.
There is a signal you can see, such as a log, a near-miss report or a client reply.
Seven risks pass all four. The table is the whole assessment at a glance, and the sections below take each one in turn.
Risk | Usual owner | First sign it has gone wrong |
|---|---|---|
1. Confidentiality | Owner of the data involved | A near-miss report about a wrong recipient or wrong document |
2. Accuracy | Person accountable for the decision | A downstream error traced back to an AI summary |
3. Bias | Head of the function making the decision | Outcomes that skew, or a decision nobody can explain |
4. Over-reliance | Team lead who sets the workload | Approvals getting faster while edits fall to zero |
5. Review cost | Team lead or budget holder | People redoing the work after the AI draft |
6. Vendor continuity | Whoever signs the contract | Changed terms or price that nobody was assigned to read |
7. Reputation | Client relationship owner | A client asking whether AI wrote it |
1. Confidentiality: what leaves the building
Confidentiality risk is anything leaving the organisation that should not, and the version that turns up in practice is mundane: the wrong document pasted in, or the right document sent to the wrong person. It is how buyers describe the worry on ivee's sales calls. Nobody says “a clever attack”. They say the wrong thing reached the wrong person. A data policy does not stop that, because the mistake happens inside a permitted use.
Check: what data the use case touches, what the account tier does with it, and where the output can go afterwards, including shared links and email to people outside the company.
Owner: the owner of the data involved, such as the head of finance for pricing or the head of HR for case notes, not IT by default.
A mitigation that works: the use case is tied to one approved account and one data class, personal accounts are blocked, and anything drafted for an external recipient is checked by a second person before it is sent. A policy sentence says “do not paste confidential data”.
How you would know: near-miss reports, an employee asking whether they were meant to send something, or an AI-drafted email going to a recipient outside the usual domains. If near misses are never reported, assume they are happening unreported.
2. Accuracy: output in a decision path nobody re-checks
Accuracy becomes a risk when AI output feeds a decision and nobody downstream goes back to the source. A Claude-drafted summary of a supplier contract is fine as a reading aid. It is a problem when the renewal decision is made from the summary alone, because one wrong clause then survives into a signed agreement.
Check: whether the person deciding reads the source or only the output, and what a wrong answer would cost by the time it is found.
Owner: the person accountable for the decision, such as the head of procurement, not the person who wrote the prompt.
A mitigation that works: a named person compares a sample of outputs to the source each month, and fields that drive money or commitments are always checked against the document. A policy sentence says “verify AI output”.
How you would know: an error found late and traced back to an AI summary, or a growing share of outputs that need correcting when sampled.
3. Bias: output that affects a person's access to something
Bias is a risk wherever an AI output affects whether a person gets a job, a promotion, a loan, a service or a benefit. A recruiter asking Claude or ChatGPT to shortlist CVs is the clearest case. If the output does not touch anyone's access to anything, record that and move on; the question takes a minute and saves a page.
Check: whether the output ranks, scores, filters or recommends about people, and whether a human decision follows or the output is the decision.
Owner: the head of the function making the decision, such as the head of talent for shortlisting.
A mitigation that works: a person makes and records the decision with a reason in their own words, and outcomes are compared across groups on a sample before and after the tool is introduced. A policy sentence says “we do not use AI to make people decisions”.
How you would know: shortlists that are narrower than the applicant pool, or a candidate or employee asking how a decision was reached and nobody being able to say.
4. Over-reliance: the reviewer stops reviewing
Over-reliance is the reviewer who still signs off but has stopped reading. After ten clean outputs the eleventh gets a skim, and the sign-off looks identical either way. Every control that depends on human review fails here first.
Check: whether review is a real step with time allocated to it, and whether the reviewer could say what they changed last week.
Owner: the team lead who sets the workload, because review time is a workload decision.
A mitigation that works: review time is built into the task, reviewers rotate, and a known error is seeded into a sample now and then to see whether it is caught. A policy sentence says “all output must be reviewed”.
How you would know: approval times shrinking, or weeks of outputs with no edits at all, which is more likely to mean nobody is looking than that the model is perfect.
5. Review cost: weak output that takes longer to check than to write
A use case can cost more time than it saves, because reviewing weak AI output can take longer than doing the work from scratch. It belongs on the register for the same reason as the other six: nobody is measuring it. In ivee's August 2026 survey of 500 UK AI decision makers, 96% said they cannot show the numbers on their organisation's AI spend, so a use case that loses time would not show up anywhere.
Check: how long five real tasks take with the AI route, including review, against how long they take without it. ivee's free calculator turns hours saved per person per week into an annual figure; enter the hours after review time, not before.
Owner: the team lead or the budget holder paying for the licences.
A mitigation that works: time the five tasks both ways before rollout, and drop or redesign any use case where the AI route loses. A policy sentence says “AI improves productivity”.
How you would know: people redoing the draft from scratch, or a team that says it is quicker to do it themselves and has stopped using the tool for that task.
6. Vendor continuity: terms that change or a tool that disappears
Vendor continuity is the risk that the tool a use case depends on changes its price, its data terms or its existence. An AI decision maker in ivee's August 2026 research put the worry plainly: “Once you automate loads and then the price goes up, can you swap vendor of the AI software?” The deeper the use case is wired in, the more that question costs to answer.
Check: how much of the use case lives inside the vendor: prompts, automations, stored files, outputs in a format only that tool reads, and whether you can export them.
Owner: whoever signs the contract, usually the COO or the head of procurement.
A mitigation that works: prompts and workflows are kept in your own documents, a fallback tool is named and tried once on this use case, and contract and terms dates are in a diary. A policy sentence says “vendors are reviewed annually”.
How you would know: a notice of changed terms landing in an inbox nobody is assigned to read, or a price line that moves between invoices.
7. Reputation: output that reads as machine-written reaches a client
Reputational risk is AI output that reads as machine-written reaching a client under a person's name, and the damage is to trust rather than to data. A proposal with a generic opening and one invented detail costs less to fix than the doubt it plants about the rest of the document.
Check: whether the output leaves the building under a person's name, and whether the client has rules or expectations about AI use in the work you do for them.
Owner: the client relationship owner, such as the account lead.
A mitigation that works: a named person rewrites client-facing text for voice and facts before it goes, and anything with a number in it is checked against the source. A policy sentence says “use AI responsibly”.
How you would know: a client quoting an odd phrase back to you, or asking whether AI wrote the document.
Which of the seven risks apply to which use case?
Match the risks to what the use case does. If it touches client or personal data, start with confidentiality and reputation. If its output feeds a decision, add accuracy and over-reliance. If it affects a person's access to anything, bias goes first. Every use case gets review cost and vendor continuity, because they apply to all of them.
Who decides which use cases go ahead at all is an AI governance question, and that sits one level above this page. The list of which tools are approved is a separate document again. This page only answers what could go wrong once a use case is allowed to run.
How do you run an AI risk assessment without it becoming theatre?
Keep it to one page per use case, start with the three use cases that touch the most sensitive data, and review the page when the tool, the data, the role or the vendor's terms change. Plan on an hour for the first pass, with the person who actually does the task in the room.
A risk register nobody reads is theatre, and it costs more than it saves, because it produces the feeling of control without any of the control. The test is simple: can the owner of each risk tell you its signal without opening the document? If not, the page is decoration. Ten pages people use beat a hundred nobody opens.
The honest limit of this approach is that it finds the risks you can name. It will not predict the odd one. What it does is move the ordinary ones, the wrong recipient, the unchecked summary, the reviewer on autopilot, from “someone should have thought of that” to a page with an owner on it.
ivee runs risk reviews of this kind alongside ops and risk leads, one use case at a time. Choose the use case you would least like to explain to a client or a regulator, and take it to a call with ivee.
