What a risk assessment is for
An AI risk assessment is a structured way of asking, before launch, what could go wrong, how likely that is, how bad it would be and what can be done about it. It does not predict the future. It makes assumptions visible so that a team can decide, with open eyes, whether to proceed, change the plan or stop.
Assessments are usually one part of a wider AI governance program, and the depth should match the stakes. A tool that sorts internal documents deserves a lighter look than one that influences who gets a loan, a job interview or medical attention.
Start with purpose and necessity
The first questions are about the problem, not the model.
- What exactly is this system meant to do, and for whom?
- Is AI needed, or would a simpler rule-based approach or a process change work as well?
- What does success look like, and how will it be measured?
- What is the current process, and how well does it perform? A system should be compared with a realistic baseline, which may be imperfect human work, not an imagined ideal.
Teams that skip this step sometimes discover late that they built a clever tool for a poorly defined problem.
Ask about the data
Because systems reflect what they learn from, data questions come early.
- Where does the training data come from, and are we allowed to use it for this purpose?
- Does it include personal data, and if so, is that necessary? The issues are covered in the article on AI privacy and in the discussion of data minimization.
- Is it accurate, current and representative of the people and situations the system will meet? Concerns about data quality apply with extra force when a model will learn from the records.
- Are some groups missing or underrepresented? This is one route to the unfairness described under algorithmic bias.
- Who can access the data, and how long is it kept?
Ask about harms and who bears them
A useful exercise is to list the people affected, not only the people who use the tool. Customers, applicants, employees, patients and members of the public may all be touched by a decision they never see.
For each group, consider:
- What is the worst plausible error, such as a wrongly denied service or a false accusation?
- How easy is it to notice and reverse?
- Could errors fall more often on some groups than others?
- Could the system be misused, deliberately or by accident, for something other than its intended purpose?
- Are there security risks, such as manipulated inputs or leaked data?
Generative tools add specific concerns. Text generators can state falsehoods fluently, a failure covered under AI hallucinations, and they may raise questions about AI copyright for the material they produce or were trained on.
Weigh likelihood and severity
Many teams use a simple grid. Each risk is rated for how likely it is and how severe the consequences would be, using plain categories such as low, medium and high. Combining the two helps decide priority: a rare but catastrophic risk may deserve more attention than a frequent but trivial one.
A hypothetical example: suppose a team rates three risks on a scale of 1 to 3 for each factor and multiplies them. A frequent small error might score 3 x 1 = 3, an occasional moderate one 2 x 2 = 4, and a rare severe one 1 x 3 = 3. The multiplication is only a prompting device. It hides judgment calls, and a rare severe harm may be unacceptable no matter what its score is. Treat scores as a way to structure discussion, not as objective measurements.
Check oversight, transparency and recourse
- Who is accountable for the system after launch?
- Where will people review or override outputs, and do they have the information, time and authority to do it? See human oversight of automated decisions.
- Can the decision be explained to the person affected at a level they can use? The field of explainable AI addresses this, though its tools have limits.
- Will people be told that AI is involved?
- Is there a clear way to question or appeal an outcome?
Plan for operation, not just launch
Risk does not end at deployment. Performance can degrade as real-world conditions drift away from the data a model learned from. Reasonable plans cover:
- metrics to monitor and thresholds that trigger a review
- periodic retesting, including checks across different groups
- a process for reporting and handling incidents, modeled on incident response practice
- the ability to pause or roll back the system quickly
- ownership of vendor relationships when the model comes from a supplier, including what the contract says about data, changes and audits
Decide, document and revisit
An assessment ends with a decision: proceed, proceed with conditions, redesign or do not deploy. Writing down the reasoning, the assumptions and the people consulted makes the decision reviewable later. It should be revisited whenever the system, its data or its use changes materially.
Risk assessment is not a guarantee of safety, and different organizations and legal systems expect different things. Some jurisdictions require formal assessments for certain high-impact uses. This article is general information, not legal or compliance advice, so consult qualified professionals about the requirements that apply to you.