# AI Risk Management Policy

| Field | Detail |
|---|---|
| **Organisation** | [Organisation Name] |
| **Document type** | Policy — approved, mandatory |
| **Framework basis** | EU AI Act Art. 9 · ISO/IEC 23894 · ISO 31000 · NIST AI RMF (MAP/MEASURE/MANAGE) |
| **Owner** | [Policy owner — e.g. AI Governance Lead] |
| **Approved by** | [Accountable executive / Board] |
| **Version / status** | v1.0 — DRAFT for adoption |
| **Effective date** | [Date] |
| **Next review** | [Date — at least annually] |
| **Classification** | Internal |
| **Prepared with** | autogovern.io — AI governance & risk templates |


## 1. Purpose

This policy defines how **[Organisation Name]** identifies, analyses, evaluates, treats, monitors and reports the risks arising from its use of artificial intelligence (AI), across the whole lifecycle and as a **continuous** process — not a one-off exercise. It operationalises the risk commitments in the AI Governance Policy.

## 2. Objectives

- Prevent AI from causing harm to people, groups, the organisation or the public.
- Keep AI risk within the organisation’s stated risk appetite.
- Provide a consistent, repeatable method to assess and treat AI risk.
- Meet legal risk-management obligations (e.g. EU AI Act Art. 9) and align to ISO/IEC 23894 and NIST AI RMF.
- Give leadership clear, current visibility of the AI risk profile.

## 3. Scope

This policy applies to all AI systems in scope of the AI Governance Policy — in-house, procured, embedded, generative and agentic — and to everyone involved in their lifecycle. It covers risks to health, safety and fundamental rights, and risks to security, privacy, fairness, performance, operations, reputation and compliance.

## 4. Definitions

| Term | Meaning |
|---|---|
| Risk | The effect of uncertainty on objectives — here, the likelihood and severity of AI-related harm. |
| Inherent risk | Risk before controls are applied. |
| Residual risk | Risk remaining after controls are applied. |
| Likelihood | How probable the risk is to occur (scored 1–5). |
| Impact / severity | How serious the harm would be if it occurred (scored 1–5). |
| Risk appetite | The amount and type of risk the organisation is willing to accept. |
| Risk tolerance | The acceptable variation around the appetite for a specific risk. |
| KRI | Key Risk Indicator — a metric that signals rising risk. |
| Circuit-breaker | A control that pauses or falls back a system when a threshold is breached. |

## 5. Risk governance — three lines of defence

| Line | Owner | Role in AI risk |
|---|---|---|
| **1st line** | System / Model owners, Product, ML/Eng | Own and manage risk in their systems day-to-day; maintain the risk register entries; apply controls. |
| **2nd line** | Risk, Compliance, DPO, Security | Set the framework, challenge risk ratings, monitor appetite, and provide oversight. |
| **3rd line** | Internal Audit / independent review | Provide independent assurance that AI risk is managed effectively. |

## 6. Risk appetite & tolerance

[Organisation Name] will **not** deploy AI with **unacceptable** residual risk to health, safety or fundamental rights. Residual **high** risks require documented risk acceptance signed off by the accountable executive before go-live. The organisation states its appetite per risk category (see below) and reviews it at least annually.

| Risk category | Appetite (example — set your own) |
|---|---|
| Harm to people / fundamental rights | Very low — high/unacceptable residual risk blocks deployment |
| Unfair bias / discrimination | Low — must pass a fairness gate before release |
| Security & data breach | Low |
| Performance / accuracy degradation | Moderate, within monitored thresholds |
| Reputational | Low |

## 7. AI risk taxonomy

[Organisation Name] assesses AI risk across these categories:

| Category | Examples |
|---|---|
| Safety | Physical or financial harm from wrong or unsafe outputs/actions |
| Bias & fairness | Discriminatory outcomes across protected or vulnerable groups |
| Privacy & data protection | Unlawful use, leakage or inference of personal data |
| Security | Prompt injection, model/data poisoning, model theft, insecure output handling |
| Transparency & explainability | Opaque decisions, undisclosed AI use, unexplainable outcomes |
| Robustness & performance | Errors, hallucinations, drift, out-of-distribution failure |
| Autonomy / agentic | Unintended or irreversible actions by AI agents; scope creep |
| Societal & ethical | Manipulation, misinformation, environmental impact |
| Operational & third-party | Vendor dependency, availability, supply-chain and integration risk |
| Legal & compliance | Breach of AI, privacy, sector or consumer law |

## 8. Risk-management process (continuous)

Aligned to ISO 31000 / ISO/IEC 23894, NIST AI RMF (MAP → MEASURE → MANAGE) and EU AI Act Art. 9:

1. **Establish context** — intended purpose, users, deployment environment, affected people, and reasonably foreseeable misuse.
2. **Identify** — enumerate risks across the taxonomy above, including to fundamental rights.
3. **Analyse** — score each risk by **likelihood × impact** (1–5 each) to get an inherent score.
4. **Evaluate** — compare against appetite; decide treat / tolerate / transfer / terminate.
5. **Treat** — assign a mitigation/control and an owner; record residual risk.
6. **Monitor & review** — track KRIs; re-assess at every material model/data change and at least quarterly.
7. **Report** — surface the risk profile to the AI Governance Committee and leadership.

## 9. Risk assessment methodology (5×5)

Score **likelihood** and **impact** 1–5; the risk score is their product (1–25).

| Score | Likelihood | Impact / severity |
|---|---|---|
| 1 | Rare | Negligible |
| 2 | Unlikely | Minor |
| 3 | Possible | Moderate |
| 4 | Likely | Major |
| 5 | Almost certain | Severe / critical (harm to people, major legal breach) |

**Rating bands:** 1–4 Low · 5–9 Medium · 10–14 High · 15–25 Critical.

| Band | Response |
|---|---|
| Low (1–4) | Accept and monitor |
| Medium (5–9) | Treat where cost-effective; owner monitors |
| High (10–14) | Treat before/at deployment; owner + 2nd-line review |
| Critical (15–25) | Do not deploy until reduced; executive risk acceptance required if residual remains high |

## 10. Risk treatment — the four T’s

| Option | When to use | Example |
|---|---|---|
| **Treat** | Reduce likelihood or impact with controls | Add human review, guardrails, testing, monitoring |
| **Tolerate** | Accept within appetite with monitoring | Low residual risk, documented acceptance |
| **Transfer** | Share the risk | Insurance, contractual allocation to a vendor |
| **Terminate** | Avoid the risk | Do not build/deploy, or withdraw the system |

## 11. Key Risk Indicators (KRIs) & monitoring

Monitor leading indicators in production and act on thresholds:

| KRI | Example threshold | Response |
|---|---|---|
| Data drift (PSI per key feature) | > 0.2 | Investigate; assess retraining |
| Performance drop vs. baseline | > 5% | Trigger review / circuit-breaker |
| Fairness — disparate impact ratio | < 0.80 (four-fifths rule) | Investigate and remediate before continued use |
| Guardrail / policy breach rate | [set threshold] | Tighten controls; root-cause |
| Prompt-injection / jailbreak rate | [set threshold] | Harden inputs & output handling |
| Human-override rate spike | [set threshold] | Investigate root cause |

## 12. Agentic & autonomous AI

For AI systems that take actions (not just produce outputs), apply additional controls proportionate to the potential impact of those actions:

- **Least-privilege scopes** — grant agents the minimum tools, data and permissions needed.
- **Approval gates** — require human approval for irreversible, high-value or sensitive actions.
- **Action logging** — record every action, tool call and decision for audit.
- **Kill switch** — a tested mechanism to halt the agent immediately.
- **Bounded autonomy** — define what the agent may and may not do without escalation.

## 13. Incident & escalation management

Any risk scoring ≥ 15 inherent, or any newly discovered harm to people, is escalated to the AI Governance Committee within **5 working days**. Serious incidents are handled under the AI Incident Response Plan, including regulatory reporting where required:

| Situation (EU AI Act Art. 73) | Report to authority within |
|---|---|
| Default serious incident | 15 days of awareness |
| Death of a person | 10 days |
| Widespread infringement or serious disruption of critical infrastructure | 2 days |

## 14. Third-party & supply-chain risk

Assess the AI risk introduced by vendors and embedded models: security posture, data handling, model provenance, availability, and their own compliance. Record third-party systems in the risk register with a named internal owner and contractual risk allocation.

## 15. Reporting & assurance

The risk register is the single source of truth for AI risk. The AI Governance Lead reports the risk profile — open risks by severity, trend, and KRI breaches — to the AI Governance Committee at each meeting and, at summary level, to the Board. Independent review (3rd line) assures the process at least annually.

## Regulatory & framework mapping

This policy is designed to help the organisation align with the following instruments. Confirm which apply to your systems and jurisdictions.

| Framework / law | Jurisdiction | What this policy supports |
|---|---|---|
| EU AI Act (Reg. 2024/1689) | EU / EEA | Risk-management (Art. 9), data governance (Art. 10), documentation (Art. 11), logging (Art. 12), transparency (Art. 13), human oversight (Art. 14), accuracy/robustness (Art. 15), prohibited practices (Art. 5), transparency to users (Art. 50) |
| NIST AI RMF 1.0 | US / global | GOVERN, MAP, MEASURE and MANAGE functions |
| ISO/IEC 42001 | Global | AI management system (AIMS) — leadership, planning, operation, evaluation, improvement |
| ISO/IEC 23894 / ISO 31000 | Global | AI risk management guidance and principles |
| GDPR (incl. Art. 22) | EU / UK | Lawful basis, DPIAs, safeguards for solely-automated decisions |
| PIPEDA + OPC gen-AI principles | Canada (federal) | Valid consent for training data, transparency, accountability |
| Quebec Law 25 (s. 12.1) | Canada — Quebec | Notice, disclosure of factors, and human review of exclusively-automated decisions |
| OSFI Guideline E-23 (eff. 2027) | Canada (financial) | Model risk management across the lifecycle, incl. AI/ML |
| TBS Directive on ADM + AIA | Canada (federal gov) | Algorithmic Impact Assessment, notice, explanation, human intervention |

## 17. Review

This policy and the risk methodology are reviewed at least annually and after any serious incident or material regulatory change.

## Appendix A — AI risk register (maintain this table)

| ID | Risk / harm | Category | Cause | Likelihood (1-5) | Impact (1-5) | Inherent | Control / mitigation | Owner | Residual | Status |
|---|---|---|---|---|---|---|---|---|---|---|
| R-01 | [e.g. biased outcomes for a protected group] | Bias | [cause] | 3 | 4 | 12 | [control] | [owner] | 6 | Open |
| R-02 |   |   |   |   |   |   |   |   |   |   |

## Appendix B — Risk treatment plan (per material risk)

| Field | Detail |
|---|---|
| Risk ID | [R-xx] |
| Chosen option (4 T’s) | [treat/tolerate/transfer/terminate] |
| Actions & controls | [list] |
| Owner | [name] |
| Due date | [date] |
| Residual score after treatment | [score] |
| Accepted by (if residual high) | [executive] |

## Appendix C — Linked documents

This policy is supported by: the **AI Governance Policy**, Bias & Fairness Audit Procedure, Post-Market Monitoring & Drift Runbook, Accuracy/Robustness/Security Test Plan, Human Oversight Procedure, and AI Incident Response Plan.


---

## Document control & approval

| Version | Date | Author | Approved by | Summary of change |
|---|---|---|---|---|
| 1.0 | [Date] | [Author] | [Approver] | Initial adoption |
|   |   |   |   |   |

**Sign-off**

- Policy owner: __________________________  Signature: ______________  Date: __________
- Accountable executive: __________________________  Signature: ______________  Date: __________
- Next review due: __________

> _This template was generated by **autogovern.io** as a professional starting point. Review and adapt it to your organisation, systems, sector and legal advice before adoption. It is an educational aid, not legal advice._