# AI Risk Assessment

**Purpose.** A structured assessment of what could go wrong with a specific AI system, how bad it would be, and what you are doing about it. For high-risk systems it is the core evidence that Art. 9 risk management is operating.

**When to use it.** Before development for high-risk systems, before deployment for all systems, and again on material change. Review live high-risk systems at least annually.

**How to use it.** Do it with the people who build and use the system, not about them. Assess risk to the people affected first and to the organisation second — that ordering is what the regulation expects, and it also surfaces the risks that later become reputational ones.

---

### System under assessment

| Field | Value |
|---|---|
| System ID / name | [AI-00X] |
| Accountable owner | [name] |
| Purpose | [what it does and what decisions it drives] |
| Risk tier | [prohibited / high / limited / minimal] |
| Affects individuals? | [yes / no — how] |
| Assessment date / assessor | [date] / [name] |

### 1. Prohibited practice screen

Answer first. Any "yes" stops the assessment.

- [ ] Deploys subliminal, manipulative, or exploitative techniques
- [ ] Exploits vulnerability by age, disability, or social/economic situation
- [ ] Performs social scoring leading to unjustified detrimental treatment
- [ ] Predicts criminal offending based solely on profiling or personality
- [ ] Builds facial recognition databases by untargeted scraping
- [ ] Infers emotion in the workplace or in education
- [ ] Performs biometric categorisation to infer protected characteristics
- [ ] Performs real-time remote biometric identification in public spaces

**Any box ticked → do not proceed. Escalate immediately.**

### 2. Harms assessment

Assess harm **to people** first.

| Harm type | Could it occur? | Who is affected? | Severity | Likelihood | Rating |
|---|---|---|---|---|---|
| Discrimination / unfair outcome | | | | | |
| Loss of opportunity (job, credit, service) | | | | | |
| Financial loss | | | | | |
| Physical or psychological harm | | | | | |
| Privacy intrusion | | | | | |
| Loss of autonomy or ability to contest | | | | | |
| Misinformation | | | | | |
| Exclusion of a group | | | | | |

Then to the organisation: regulatory, financial, reputational, operational.

> **Ask who is worst affected, not who is average**
> Aggregate accuracy hides concentrated harm. A system that is 95% accurate
> overall can be systematically wrong about one group — and that group is
> who will be harmed, and who will complain.

### 3. Technical risk

| Area | Question | Assessment | Mitigation |
|---|---|---|---|
| Data quality | Is training data relevant, representative, current? | | |
| Bias | Have you tested performance across subgroups? | | |
| Accuracy | Does it meet the declared threshold? Where does it fail? | | |
| Robustness | How does it behave on edge cases and adversarial input? | | |
| Drift | How would you detect degradation? | | |
| Explainability | Can you explain a decision to the person affected? | | |
| Security | Injection, poisoning, extraction, leakage through output? | | |
| Dependencies | What happens if the vendor or model changes? | | |

### 4. Human oversight

| Question | Answer |
|---|---|
| Who reviews the output? | [named role] |
| What information do they see? | |
| Can they realistically override? How? | |
| How long do they have per decision? | |
| How would we know if they were rubber-stamping? | |
| What training have they had? | |

> **The rubber-stamp test**
> If a reviewer handles hundreds of decisions an hour, or overrides almost
> never, oversight is nominal. Measure override rates — a rate near zero is
> a warning sign, not a success metric.

### 5. Transparency

- [ ] People are told they are interacting with, or subject to, AI
- [ ] AI-generated content is marked where required
- [ ] Affected people can obtain an explanation
- [ ] **There is a route to contest a decision**, and someone staffs it

### 6. Residual risk and decision

| Residual rating | Justification | Accepted by | Authority | Date |
|---|---|---|---|---|
| [low/med/high/critical] | | [name] | Per Decision Rights & Escalation | [date] |

**Decision:** Proceed · Proceed with conditions · Do not proceed

Conditions: **[list, with owners and dates]**

### 7. Review

| Trigger | Action |
|---|---|
| Material change of purpose or data | Full reassessment |
| Incident involving this system | Targeted reassessment |
| Annually (high-risk) | Full review — see {{default:high-risk-review-cycle}} |
| Vendor model change | Targeted reassessment |

---

## Adaptation notes

- **Small organisations:** Sections 1, 2, and 4 are the irreducible core: is it allowed, who could it hurt, and who is watching. That fits on two pages.
- **Regulated financial services:** Align with model risk management: add model validation findings, and treat this as a complement to, not a replacement for, independent validation.
- **Where a DPIA is also required:** Run them together and cross-reference. Section 2 harms feed the DPIA's risks-to-individuals directly — see Processing & DPIA Log.
- **Research and experimentation:** Apply a shortened version at experiment stage, and the full assessment before anything touches real users or real decisions.

---

*From the [Open Data & AI Governance Kit](https://lsdeva.github.io/governance-kit/). Licensed [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/) — free to use, adapt, and share with attribution.*

***Not legal advice.** Adapt to your jurisdiction, sector, and risk appetite, and have qualified counsel review anything material.*