AI Risk Assessment: The 5-Step Method Before You Approve

Before you approve any AI project, fill in a five-column table: what can go wrong, what impact it would have on the business, how likely it is, what you will do to prevent it, and who answers if it happens. That is an AI risk assessment. You do not need to be an engineer to do it, and it is the difference between saying “yes” with judgment and signing a blank check.

Most AI projects that go wrong in companies do not fail because of bad technology. They fail because nobody sat down for half an hour to think about what happens when the system gets it wrong. A risk assessment does not slow down innovation: it is what lets you approve the project knowing where the live wires are. And it is boring on purpose. Five columns you can fill in at your next committee meeting.

Why AI needs its own risk assessment

A generative AI system can give you different answers to the same question, and it can make one up with total confidence. That is the difference from traditional software.

When you buy a billing tool, you know what it does. You enter the same data and you always get the same result. It is predictable, which is why the risk is easy to understand. Generative AI (systems like ChatGPT that draft text, summarize documents or handle a customer) works differently. It generates each answer on the fly, and every so often it produces something that sounds perfectly reasonable but is false. In the industry this is called a hallucination: the system states a made-up fact with no sign that it is making it up.

For a decision-maker the practical consequence is simple. It is not enough to ask “does it work?”. You have to ask “what happens the times it does not work, and who takes the hit?”. That shift in the question is the reason AI deserves its own risk table and not that of any old piece of software. If you want the full framework for why AI forces you to decide differently, I develop it in the guide to AI risks for companies.

Steps 1 and 2: what can go wrong and who it hurts

The first step is to list, in plain language, everything that can go wrong. The second is to say which part of the business each thing hurts. No jargon.

These are the failures that show up almost every time AI touches a customer or a piece of data:

• A made-up answer to a customer. The assistant promises a refund that does not exist or states a legal condition the company does not offer.
• A personal-data leak. Someone pastes a customer’s ID number or medical history into the system and that data ends up where it should not.
• A biased decision. The system, trained on past data, rejects candidates or customers following an unfair pattern.
• Vendor dependence. Your whole process depends on an external service that can raise its price, change the rules or shut down.
• Runaway cost. The pilot was cheap, but at real volume the monthly bill multiplies.

Impact is measured in four currencies any decision-maker understands: money (a fine, a lost sale, an out-of-control bill), reputation (an outraged customer who tells the world), legal (a data-protection breach) and people (a decision that unfairly harms someone). Next to each failure, note which of those four it hits and how hard.

Step 3: how likely is it

You do not need an exact probability figure. A scale of low, medium or high, agreed in the meeting, is enough to decide. What matters is not precision, it is crossing two things.

A risk with huge impact but almost impossible (a meteorite) does not warrant stopping the project. A small but constant risk (the system gets one in every ten routine answers wrong) is not handled the same way as a big rare one either. Priority comes from multiplying impact by likelihood: what is serious and frequent goes first.

That combination reads better on a grid than in a list.

If you want the full visual tool to rank risks by priority, you have it in the AI risk and impact matrix. Here I will keep the underlying idea: you do not handle every risk, you handle the ones that land in the serious-and-probable corner.

Step 4: mitigation, or what you do so it does not happen

Mitigating means reducing the likelihood that the failure occurs or the damage it causes if it does. For each risk in the dangerous corner, note a concrete action, not an intention.

The mitigations that work in most AI projects are unglamorous:

• Human review before acting. The system proposes the answer, but a person approves it before it reaches the customer. Slow, yes, but it cuts hallucinations off at the root where it matters.
• Keep personal data out of the system. If the vendor does not guarantee in writing where it is stored and what is done with it, that data does not go in. Full stop.
• Start with a small pilot. One department, one type of query, one month. That way the real cost and the failures show up while they are still cheap to fix.
• Have a manual plan B. If the system fails or the vendor goes down, the process can carry on by hand. Never let AI be the only path for anything critical.

This is the judgment that truly separates a sensible AI project from a reckless one, and it is what we work on with real cases in the AI without hype course: not the technology, but how to decide which risk you accept and which you do not.

Step 5: the owner, the step everyone skips

Every risk needs the name of a person next to it. Not a department, a person. This is the step almost nobody fills in and the one that prevents the most problems.

“The AI” is responsible for nothing. A system cannot answer to a customer, to a judge or to your committee. There is always someone who answers, and if you do not decide it beforehand, chaos will decide it on the day of the incident. That is why the last column is a name: who watches that this risk stays under control and who you call when it goes off.

This is where the legal side comes in, and it deserves respect. In the European Union there are two rules that almost always appear. The GDPR (the data-protection regulation) governs how you handle the personal data of your customers and employees. And the European Artificial Intelligence Regulation (known as the AI Act, in force since 2024 and applying in phases) classifies AI systems by their level of risk and demands more controls the more sensitive the use. You do not need to know the articles. You need to know they exist and that the responsibility to comply is yours, not the vendor’s. This is not legal advice: for a specific case, talk to a specialist lawyer.

The full table, in one go

Here is the method applied to a case. Imagine a small business that wants to put an AI assistant in place to answer customer questions by chat. The figures and names are illustrative.

What can go wrong	Impact	Likelihood	Mitigation	Owner
The assistant promises a nonexistent refund	Legal and reputation, high	Medium	Refund answers always reviewed by a person	Customer Support Lead
A customer pastes personal data into the chat	Legal (GDPR), high	High	Visible notice and automatic deletion of those messages; clear contract with the vendor	Data Protection Lead
The monthly cost runs away at real volume	Money, medium	Medium	One-month pilot with a spending cap before opening to everyone	Finance
The vendor changes terms or goes down	Operational, medium	Low	Plan B: the human team can handle the chat by hand	Operations Lead

Four rows, half an hour of meeting, and suddenly the project stops being a leap of faith. You see what you accept, what you fix before starting and who you call when something goes off. If you also want the quick filter of “does this even need AI?” before building the table, start with the four questions before using AI.

A table like this does not guarantee nothing will go wrong. It guarantees that, if it does, you knew it could happen, you decided to accept it and you put someone in charge of watching it. That is managing a risk instead of suffering it.

One new concept every week

Subscribe

Checklist before approving the project

• You have the list of what can go wrong in business language, no jargon
• Each failure has its impact marked (money, reputation, legal or people)
• Each failure has an agreed likelihood (low, medium or high)
• The serious and probable risks have a concrete mitigation, not an intention
• Each risk has the name of a responsible person, not a department
• You have checked whether the project touches personal data (GDPR) or a sensitive use (AI Act)
• There is a manual plan B for anything critical

Frequently asked questions

What exactly is an AI risk assessment?

It is the exercise of listing, before approving an AI project, everything that can go wrong, rating its impact and its likelihood, deciding how you prevent it and assigning an owner to each risk. In practice it fits in a five-column table you fill in during a meeting. Its goal is not to block AI, but to approve it knowing what you are taking on.

What is the risk specific to generative AI compared to other software?

That it is not fully predictable. Normal software always gives the same answer to the same data, whereas generative AI generates each answer on the fly and sometimes produces false information with an air of certainty. That is why an AI risk assessment focuses so much on what happens when the system gets it wrong and who reviews it.

Do I need technical knowledge to do this assessment?

No. The assessment is done in business language: impact, likelihood, owner. The only technical thing worth having on hand is someone who can explain, in one sentence, what the system does and what data it works with. The rest are ordinary management questions applied to a new tool.

Who is responsible if the AI makes a mistake?

Always a person in your organization, never “the AI” nor, by default, the vendor. The system does not answer to a customer or to a judge, so the responsibility to watch each risk and to comply with the regulations (GDPR, AI Act) falls on whoever approves and operates the project. That is why the last column of the table carries a specific name. For the legal detail of your case, consult a lawyer.