The user wants to understand Risk in the context of AI Safety & Risk and apply it to practical AI governance or compliance work.
Use risk for potential adverse outcomes before or during assessment; use harm for the adverse effect that has occurred or may be concretely described.
Risk is the possibility of an adverse outcome; harm is the adverse effect itself. In AI governance, risk describes what may happen, how likely it is, how severe it could be, and what controls are needed. Harm describes actual or concretely described damage to people, rights, safety, property, organisations, or society. Risk assessment is prospective and preventive; harm analysis is used to understand impact, accountability, remediation, and lessons after or around an incident.
Risk is the warning sign; harm is the injury or loss the warning sign is about. A hiring model may carry a risk of discriminatory ranking before anyone is affected. If applicants are actually unfairly rejected, the organisation is dealing with harm. Good governance tries to reduce risk before it becomes harm and respond properly when harm occurs.
Analogy
Risk is the probability and severity of a bridge failing; harm is the collapse, injury, disruption, or cost if it fails.
The distinction matters because legal, technical, and governance work happen at different stages. Risk language supports design reviews, procurement checks, impact assessments, safety cases, control selection, and deployment approvals. Harm language supports complaints, incident response, user remedies, root-cause analysis, reporting, compensation, and enforcement. If teams blur the two, they may either overstate hypothetical concerns as proven damage or understate real damage as only theoretical risk. Clear vocabulary improves audit trails, board reporting, regulatory analysis, and vendor accountability.
Urgency
Teams should separate risk and harm language in AI inventories, risk registers, incident logs, and safety evidence.
A practical AI risk record should identify the hazard or failure mode, affected parties, potential harms, likelihood, severity, detectability, existing controls, residual risk, and accountable owner. A harm record should identify what occurred, who or what was affected, evidence, impact severity, root causes, mitigation, remediation, notifications, and lessons learned. Risk assessment should happen before deployment and when material changes occur. Harm analysis should happen when failures, complaints, incidents, near misses, or monitoring signals show that adverse effects may have occurred.
The most common mistake is writing vague risks such as 'AI bias' without identifying the specific harm, affected group, decision point, and control. Another mistake is treating harm as only physical injury. In AI systems, harm may include discrimination, denial of access, privacy intrusion, economic loss, reputational damage, psychological distress, security compromise, or loss of autonomy. Teams also fail when they keep risk registers and incident logs disconnected, making it hard to learn whether predicted risks became real harms.
Mistake 1: Recording 'hallucination risk' without explaining whether the possible harm is legal error, medical misinformation, financial loss, or user deception.
Mistake 2: Calling a documented privacy leak only a risk after affected users have already been exposed.
This page should link to risk, harm, ai-risk-assessment, safety-case, and ai-safety. The strongest comparison is risk-vs-harm because it supports cleaner AI governance documentation. It should also connect to safety-case-vs-ai-risk-assessment where teams need to understand the difference between identifying possible harms and building an evidence-backed safety argument. Related questions include what-is-ai-safety, what-is-a-safety-case-for-ai, and what-is-model-drift.