ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
An AI harm taxonomy is a structured list of the ways an AI system can cause harm, grouped into categories that assessors can apply consistently. Without one, AI risk assessments tend to fixate on whatever the team already worries about, usually security and accuracy, and to miss quieter harms such as unfair treatment, loss of autonomy or erosion of trust.
This guide explains what an AI harm taxonomy should contain, how to build one from recognized sources, how to use it in an assessment and how to avoid the common traps of long lists that nobody uses.
A taxonomy does three jobs. It prompts assessors to consider the full range of consequences, so that nothing important is missed because nobody thought of it. It gives everyone the same vocabulary, so that a risk described by a data scientist can be understood by a lawyer and by a business owner. And it makes results comparable across systems, so that leadership can see which categories of harm recur across the portfolio and decide where to invest in controls.
It is a tool for thinking, not a scoring method in itself. Scores come from your likelihood and severity scales. The taxonomy tells you what to score. Our guide to the difference between AI impact assessment and risk assessment explains how harms to people and risks to the organization relate.
Free AI risk assessment
Which of your AI systems could harm people, or you?
List your AI systems, models and data, pick from 38 AI risk scenarios, rate them for the people affected and for you, and plan treatment with ISO 42001 Annex A controls. You get a heat map, a process score and the findings an auditor would raise, free.
Run the free AI risk assessment → or View premium report sample
You do not need to invent categories. The NIST AI Risk Management Framework describes potential harms in three broad groups: harm to people, including individuals, groups and society; harm to an organization; and harm to an ecosystem. It also describes characteristics of trustworthy AI such as validity, safety, security, fairness, accountability, transparency, explainability and privacy. You can read the framework on the NIST AI Risk Management Framework page, and our article on trustworthy AI characteristics explains how those properties map to risks.
Other useful sources include the EU AI Act, which is concerned with risks to health, safety and fundamental rights, ISO/IEC 42001, which asks for consideration of impacts on individuals and society, and public incident databases that catalogue real failures. Adapt and combine these into a list that fits your sector. The goal is coverage, not a perfect academic classification.
| Category | Examples | Typical questions |
|---|---|---|
| Physical and safety harm | Unsafe recommendations, faulty control of equipment | Could a wrong output injure someone? |
| Psychological harm | Manipulation, distress, over-reliance | Could the system pressure or mislead users? |
| Economic harm | Wrongful denial of credit or work, price discrimination | Could an error cost someone money or opportunity? |
| Discrimination and unfair treatment | Different error rates across groups | Who is disadvantaged by this system? |
| Privacy and data harm | Inference of sensitive traits, leakage of training data | What could be learned about people that they did not share? |
| Loss of autonomy and rights | No route to appeal, hidden automated decisions | Can people understand and contest outcomes? |
| Societal and information harm | Misinformation at scale, erosion of trust | What happens if this is used widely? |
| Organizational harm | Legal liability, reputational damage, operational failure | What does it cost us if this goes wrong? |
| Environmental harm | Energy and resource use | Is the footprint proportionate to the benefit? |
Treat the categories as prompts in a workshop. For each AI system in scope, go through the list and ask whether the system could plausibly cause that kind of harm, to whom, and how. Record the answer even when it is no, along with the reason, because a documented no is evidence that the question was asked. The steps below show a workable sequence.
Harm does not arise only when a system works as designed. Ask what happens when users apply it to a purpose it was not built for, when it is given inputs outside its training range, or when someone deliberately tries to make it misbehave. For generative systems, add harms such as fabricated content presented as fact, disclosure of confidential inputs and generation of harmful material. Our guide to generative AI risk assessment covers those additions.
Take a model that ranks customer support tickets so that the most urgent are handled first. Walking the categories shows that a wrong ranking could delay help for someone with an urgent safety problem, which is a safety harm. It could systematically rank tickets from non-native speakers lower because the text looks unusual, which is a fairness harm. It could use customer messages to infer health conditions, which is a privacy harm, and it could leave customers unable to learn why their request waited, which touches autonomy. The organization faces complaints, regulatory attention and lost trust.
Without the list, the team might have rated only accuracy and uptime. With it, the assessment produces four additional findings, each with an owner: test error rates across language groups, add a human escalation route for safety keywords, restrict inference of sensitive traits and give customers an explanation of how priority is set. That is the practical value of a shared list: it turns a vague sense of responsibility into specific work.
Define severity so that a harm in one category can be compared with a harm in another. A common approach uses four levels: minor and easily reversed, moderate and reversible with effort, serious and hard to reverse, and severe or irreversible. Reversibility, the number of people affected and the vulnerability of those people should all raise the rating. Write the definitions down and apply them consistently so that a fairness issue affecting thousands of people is not scored lower than a minor operational problem merely because it is harder to measure.
Every harm you identify and rate should land in a risk register with a category tag from the taxonomy. That lets you filter by category and see, for example, all fairness risks across the portfolio, and whether they share a cause such as poor demographic data. See our guide to the AI risk register for a suitable structure, and the article on the AI risk treatment plan for turning findings into actions.
Some harms carry legal weight. Under the EU AI Act, deployers of certain high-risk systems must carry out a fundamental rights impact assessment before use, so your taxonomy should include rights such as non-discrimination, privacy, freedom of expression and access to remedy. Read our guide to the fundamental rights impact assessment for scope and content, and confirm current application dates against the official text because timelines have been subject to change.
The most common failure is length. A taxonomy of two hundred items looks thorough but no one uses it. Keep the top level to about eight to ten categories, add a short list of examples under each and allow assessors to add new items when they find gaps. Review the taxonomy after each significant incident, after each new regulation and at least once a year. Track which categories produce findings, and which produce none, since a category that never yields a finding may be too vague to work.
Make sure the categories reflect the people actually affected. Involve staff from customer-facing teams, compliance, legal and, where possible, representatives of affected groups. They often name harms the technical team never considered, such as a call center script produced by a model that is unusable for people with hearing difficulties.
If you would rather begin with a finished structure than a blank page, the AI Risk Assessment Report and Workbook includes a structured report, scoring and a working register into which you can bring your own AI harm taxonomy. Whatever tool you use, keep the taxonomy short, written down and applied every time so that results are comparable.
It is a structured list of the types of harm an AI system can cause, used to make sure assessments consider the full range of consequences in a consistent way.
No single one is mandatory. Sources such as the NIST AI Risk Management Framework, the EU AI Act and ISO/IEC 42001 provide helpful categories that you can adapt to your context.
Keep the top level small, roughly eight to ten categories, and give examples under each. Long lists are rarely used in practice and make assessments slower without improving them.
No. It tells you which harms to consider, while your likelihood and severity scales tell you how serious each one is. Use both together.
Include technical, legal, compliance, security and business staff, along with representatives of affected users where possible, so that the categories reflect real consequences.
September 30, 2026
