Types of harm: what actually breaks
Ethics and responsible AI · Lesson 1 / 22
Start with consequences, not with principles
Conversations about responsible AI usually start with values and end with a slide deck. The conversation that changes a product starts elsewhere: what happens to a specific person if the system gets it wrong — or works as designed, but not in their favour. Harm from AI systems is not mysterious. It repeats across companies and falls into a few recognisable types.
Six kinds of harm you will meet in practice
- Denial of access. Scoring, fraud detection, résumé screening, account blocks. Someone does not get the loan, the job, or their own money.
- Wrong information with consequences. A support assistant promises terms that do not exist. An internal bot hands a lawyer a citation to a case never filed.
- Data leakage. Customer personal data ends up in a prompt, the prompt in a log, and the log is readable by a whole department and a contractor.
- Dignity harm. Offensive generation, degrading classification, recognition errors landing systematically on one group.
- Economic skew. Pricing or prioritisation under which some customers consistently get worse terms for no defensible reason.
- Quiet decision decay. The model suggests, staff stop thinking, quality drifts down and nobody measures it.
Scenario card (ten minutes to fill in) 1. What the system does, in one sentence 2. Who receives the output and what they do next 3. Who is hurt if the output is wrong 4. How many people pass through this per month 5. How we learn about an error, and after how long 6. Whether a person can contest the result
Insight. The most underrated line is number five. Companies know their system can be wrong and rarely know through which channel the error reaches them. If the answer is «the customer will write to support», you learn about harm only after it accumulates.
Half of these harms require neither malice nor exotic technology. An ordinary pilot on real customers is enough, because «it is only a suggestion». A suggestion becomes a decision the moment the operator stops checking it.
Common mistake. Counting only dramatic scenarios — discrimination and breaches — as harm. Real incident reviews are boring: the system produced a wrong amount, nobody noticed for three weeks, refunds went out by hand with no explanation.
Pro tip. Create an AI use-case register before you write a policy. Three columns are enough: the use case, its owner, what harm is possible. A policy without a register describes an imaginary company.
Cheat sheet
- Describe harm through a specific person and consequence, not a violated principle.
- Six recurring types: denial of access, wrong information, leakage, dignity harm, economic skew, decision decay.
- A suggestion becomes a decision the moment people stop checking it.
- Start with a register of use cases, not a declaration.
1. Where is it more useful to start a responsible AI conversation inside a company?
2. What does the line «how we learn about an error» in the scenario card require?
3. Why can a suggestion to an operator count as a decision?