# AI Risk Assessment: [AI system name]

> Complete risk assessment for an AI system, organised on the four
> functions of the NIST AI Risk Management Framework (AI RMF 1.0):
> GOVERN, MAP, MEASURE and MANAGE, and on its trustworthiness
> characteristics. It records the system context, who may be affected,
> the risk register with scores, how each risk is measured, the controls,
> the residual risk and the approval decision. Replace every `[bracketed]`
> value and every row marked *Example*.

<!--
Guidance: How to use this template
- Do the assessment before deployment and repeat it on every material
  change, at least once a year, and after any serious incident.
- Involve people outside the build team: product, legal, security, domain
  experts and, where possible, representatives of affected people.
- Score risks with the same scale every time (section 6.1) so that
  assessments can be compared across systems and over time.
- A risk without an owner, a measure and a decision is not managed. Every
  register row needs all three.
- This assessment supports, and does not replace, legal obligations such
  as a data protection impact assessment or EU AI Act conformity work.
-->

## Document control

<!-- Guidance: Identify the system version assessed and who approved the result. -->

| Field | Value |
|---|---|
| Document ID | [AIRA-SYSTEM-001] |
| AI system and version | [Name] [version] |
| Assessment type | [Initial / Periodic / Change-triggered / Post-incident] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@risk-owner] |
| Assessors | [@assessor-1], [@assessor-2] |
| Classification | [Internal / Confidential] |
| Last updated | YYYY-MM-DD |
| Next review due | YYYY-MM-DD |
| Related documents | [Model card], [ML system design], [DPIA], [AI policy] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| System owner | [@name] | [Accept / Accept with conditions / Reject] | YYYY-MM-DD |
| AI governance lead | [@name] | [Decision] | YYYY-MM-DD |
| Risk / compliance | [@name] | [Decision] | YYYY-MM-DD |
| Accountable executive (for high residual risk) | [@name] | [Decision] | YYYY-MM-DD |

## Revision history

<!-- Guidance: Each reassessment is a revision; note what triggered it. -->

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved with conditions C-01 and C-02 |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Reassessed after switching to a new foundation model |

## Contents

<!-- Guidance: Keep aligned with the headings below. -->

1. [Summary](#1-summary)
2. [GOVERN: governance context](#2-govern-governance-context)
3. [MAP: system context](#3-map-system-context)
4. [MAP: stakeholders and impacts](#4-map-stakeholders-and-impacts)
5. [Trustworthiness characteristics review](#5-trustworthiness-characteristics-review)
6. [Risk register](#6-risk-register)
7. [MEASURE: measurement plan](#7-measure-measurement-plan)
8. [MANAGE: controls and treatment](#8-manage-controls-and-treatment)
9. [Residual risk and decision](#9-residual-risk-and-decision)
10. [Monitoring and review](#10-monitoring-and-review)
11. [References and glossary](#11-references-and-glossary)

## 1. Summary

<!-- Guidance: A one-page summary for approvers: what the system does, the top risks, the overall residual rating and the recommended decision. Write it last. -->

| Item | Summary |
|---|---|
| System purpose | *Example:* Chat assistant that answers employee HR policy questions from the policy library |
| Risk tier | [Low / Medium / High / Unacceptable] with reason |
| Top risks | *Example:* R-01 incorrect policy answers; R-03 disclosure of personal data; R-05 over-reliance |
| Overall residual risk | [Low / Medium / High] |
| Recommendation | [Approve / Approve with conditions / Do not deploy] |
| Conditions | *Example:* C-01 groundedness at least 0.95 before launch; C-02 HR review of escalated answers |

## 2. GOVERN: governance context

<!-- Guidance: The GOVERN function sets the culture, policies, roles and accountability that the rest of the assessment depends on. Record what applies to this system. -->

### 2.1 Policies and obligations

| Item | Reference | How it applies |
|---|---|---|
| Organisational AI policy | [AI-POL-001] | *Example:* Requires risk assessment for any AI used on employee data |
| Legal and regulatory obligations | [List, for example data protection law, sector rules, AI Act category] | [How] |
| Risk appetite and tolerance | [Reference] | *Example:* No High residual risk without executive acceptance |
| Third-party and supplier terms | [Contract references] | *Example:* Model provider does not train on our prompts |

### 2.2 Roles and accountability

| Role | Name | Responsibility |
|---|---|---|
| System owner | [@name] | Accountable for the system and its risks |
| Risk owner(s) | [@name] | Own individual risks in section 6 |
| Independent reviewer | [@name] | Challenges the assessment; not on the build team |
| Incident contact | [@name] | Receives and triages AI incidents |

### 2.3 Diversity of perspectives

[Who took part in the assessment and which perspectives are missing.
Example: "Workshops with HR, legal, security, two employee
representatives and an accessibility specialist. No external experts."]

## 3. MAP: system context

<!-- Guidance: The MAP function establishes context so that risks can be identified. Describe purpose, setting, users, data, model, autonomy and limits. -->

### 3.1 Intended purpose and setting

| Aspect | Description |
|---|---|
| Intended purpose | [What the system does and the decision or task it supports] |
| Deployment setting | *Example:* Intranet, available to 8 000 employees in 4 countries |
| Users | *Example:* All employees; HR advisers for escalations |
| Level of autonomy | *Example:* Advisory; no actions taken on behalf of the user |
| Benefits expected | *Example:* Faster answers; 30% fewer routine HR tickets |
| Known limits and assumptions | *Example:* Policy library is current and complete |
| Out-of-scope uses | *Example:* Individual legal advice, disciplinary decisions |

### 3.2 System description

| Component | Description | Provider |
|---|---|---|
| Model | *Example:* Hosted large language model [name, version] | [Supplier] |
| Retrieval | *Example:* Search over 1 200 HR policy documents | In-house |
| Data inputs | *Example:* User question, user's country and grade | In-house |
| Outputs | *Example:* Answer text with links to cited policy sections | n/a |
| Human oversight | *Example:* "Ask HR" button; HR reviews flagged answers | n/a |

### 3.3 Alternatives considered

[Including not using AI. Example: "Improved search only; rejected because
users could not find answers in long policy documents."]

## 4. MAP: stakeholders and impacts

<!-- Guidance: Identify everyone who may be affected, including people who never use the system. Consider positive and negative impacts on individuals, groups, the organisation and society. -->

| Stakeholder | Relationship | Potential positive impact | Potential negative impact | Vulnerable or under-represented |
|---|---|---|---|---|
| *Example:* Employees asking questions | Direct users | Faster, consistent answers | Wrong answer leads to lost entitlement | Employees with limited language skills |
| *Example:* HR advisers | Operators | Less routine work | Deskilling; blame for model errors | No |
| *Example:* Employees discussed in questions | Indirectly affected | None | Personal data exposure | Employees on leave or in disputes |
| *Example:* Organisation | Owner | Cost saving | Legal claims, trust loss | n/a |
| [Stakeholder] | [Relationship] | [Positive] | [Negative] | [Yes / No, who] |

## 5. Trustworthiness characteristics review

<!-- Guidance: Review the system against each trustworthiness characteristic of the AI RMF. Note the concern, the evidence available and the linked risks. Characteristics often trade off; record the trade-offs. -->

| Characteristic | Key question for this system | Current evidence | Concern level | Linked risks |
|---|---|---|---|---|
| Valid and reliable | Are answers correct and consistent with policy? | *Example:* Pilot eval 92% correct on 300 questions | Medium | R-01 |
| Safe | Could an answer lead to harm to a person? | *Example:* Health and safety policies included | Medium | R-02 |
| Secure and resilient | Can it be manipulated or fail badly? | *Example:* Prompt injection tests not yet run | High | R-04 |
| Accountable and transparent | Do users know they talk to AI, and who is responsible? | *Example:* Banner and owner named | Low | R-06 |
| Explainable and interpretable | Can users check why an answer was given? | *Example:* Citations shown for every answer | Low | R-01 |
| Privacy-enhanced | Is personal data minimised and protected? | *Example:* Prompts logged 30 days | Medium | R-03 |
| Fair, with harmful bias managed | Do answers differ in quality across groups or languages? | *Example:* Not yet tested for 3 of 4 languages | High | R-07 |

Trade-offs noted: [Example: "Logging prompts helps measure validity but
increases privacy risk; resolved by 30-day retention and masking."]

## 6. Risk register

<!-- Guidance: One row per risk. Describe cause, event and consequence. Score inherent risk before controls; residual risk is scored in section 9. -->

### 6.1 Scoring method

Likelihood $L$ and impact $I$ are each rated on a 1 to 5 scale. The risk
score is their product:

$$
S = L \times I, \qquad 1 \le S \le 25
$$

| Score $S$ | Rating | Required response |
|---|---|---|
| 1 to 4 | Low | Accept; monitor |
| 5 to 9 | Medium | Treat or accept with owner sign-off |
| 10 to 16 | High | Treat before deployment; governance lead approval |
| 20 to 25 | Critical | Do not deploy until reduced |

| Level | Likelihood (in 12 months) | Impact |
|---|---|---|
| 1 | Rare: under 1% | Negligible: no lasting effect on anyone |
| 2 | Unlikely: 1% to 10% | Minor: inconvenience, easily corrected |
| 3 | Possible: 10% to 50% | Moderate: financial or emotional harm to individuals, correctable |
| 4 | Likely: 50% to 90% | Major: significant harm to individuals or many people affected |
| 5 | Almost certain: over 90% | Severe: irreversible harm, rights violated, regulatory action |

### 6.2 Register

| ID | Risk (cause, event, consequence) | Characteristic | L | I | $S$ | Rating | Owner |
|---|---|---|---|---|---|---|---|
| R-01 | *Example:* Outdated document retrieved, so the assistant states the wrong leave entitlement and the employee loses leave | Valid and reliable | 4 | 3 | 12 | High | [@hr-content] |
| R-02 | *Example:* Ambiguous safety question answered without escalation, so a hazard is not reported | Safe | 2 | 4 | 8 | Medium | [@hse] |
| R-03 | *Example:* Users paste colleagues' personal data, which is logged and visible to support staff | Privacy-enhanced | 4 | 3 | 12 | High | [@privacy] |
| R-04 | *Example:* Injected text in a policy document changes the assistant's instructions | Secure and resilient | 2 | 4 | 8 | Medium | [@security] |
| R-05 | *Example:* Employees treat answers as binding and skip HR advice on complex cases | Accountable and transparent | 3 | 3 | 9 | Medium | [@hr-lead] |
| R-06 | *Example:* Responsibility for wrong answers unclear between HR and IT | Accountable and transparent | 2 | 2 | 4 | Low | [@system-owner] |
| R-07 | *Example:* Answers in less-resourced languages are less accurate, so those employees get worse service | Fair, bias managed | 3 | 3 | 9 | Medium | [@ml-lead] |
| [R-nn] | [Cause, event, consequence] | [Characteristic] | [1-5] | [1-5] | [L x I] | [Rating] | [@name] |

## 7. MEASURE: measurement plan

<!-- Guidance: The MEASURE function uses quantitative and qualitative methods to analyse and track risks. For each significant risk, define the metric, method, data, threshold and frequency. -->

| Risk | Metric | Method | Data | Threshold | Frequency | Owner |
|---|---|---|---|---|---|---|
| R-01 | Answer correctness; groundedness | Expert-graded test set; automated citation check | 500 questions, refreshed quarterly | Correct at least 95%; grounded at least 0.95 | Before release and monthly | [@ml-lead] |
| R-03 | Personal data in logs | Pattern scan of logs | All logs | Under 0.5% of prompts after masking | Weekly | [@privacy] |
| R-04 | Injection success rate | Red-team test suite | 150 attack prompts | 0 successful instruction overrides | Before release and quarterly | [@security] |
| R-07 | Correctness gap across languages | Same test set translated | 4 languages | Gap at most 5 points | Before release and quarterly | [@ml-lead] |
| [R-nn] | [Metric] | [Method] | [Data] | [Threshold] | [Frequency] | [@name] |

Measurement limitations: [Example: "The test set covers the 200 most
common topics; rare policies are under-tested."]

## 8. MANAGE: controls and treatment

<!-- Guidance: The MANAGE function allocates resources to treat risks. For each risk, choose a response (mitigate, transfer, avoid, accept) and list concrete controls with owners and dates. -->

| Control ID | Risk(s) | Response | Control | Type | Owner | Due | Status |
|---|---|---|---|---|---|---|---|
| C-01 | R-01 | Mitigate | Retrieval limited to current policy versions; nightly sync check | Preventive | [@hr-content] | YYYY-MM-DD | [Open] |
| C-02 | R-01, R-05 | Mitigate | "Not legal advice" notice; escalation to HR for named topics | Preventive | [@hr-lead] | YYYY-MM-DD | [Open] |
| C-03 | R-03 | Mitigate | Mask personal data before logging; 30-day log retention | Preventive | [@privacy] | YYYY-MM-DD | [Done] |
| C-04 | R-04 | Mitigate | Treat retrieved text as data; output filter; quarterly red team | Preventive and detective | [@security] | YYYY-MM-DD | [Open] |
| C-05 | R-07 | Mitigate | Launch in English and German only until gap closes | Avoid (partial) | [@product] | YYYY-MM-DD | [Open] |
| [C-nn] | [Risks] | [Response] | [Control] | [Type] | [@name] | YYYY-MM-DD | [Status] |

Incident response: [How AI incidents are reported, triaged and fed back
to this assessment; link to the incident procedure.]

Decommissioning: [Conditions under which the system will be withdrawn,
and how users are informed.]

## 9. Residual risk and decision

<!-- Guidance: Re-score each risk assuming the controls work as designed. Compare against risk appetite and record who accepts any remaining High risk. -->

| ID | Inherent $S$ | Controls | Residual L | Residual I | Residual $S$ | Rating | Accepted by |
|---|---|---|---|---|---|---|---|
| R-01 | 12 | C-01, C-02 | 2 | 3 | 6 | Medium | [@system-owner] |
| R-03 | 12 | C-03 | 2 | 3 | 6 | Medium | [@privacy] |
| R-04 | 8 | C-04 | 1 | 4 | 4 | Low | [@security] |
| R-07 | 9 | C-05 | 2 | 2 | 4 | Low | [@product] |
| [R-nn] | [S] | [C-nn] | [1-5] | [1-5] | [S] | [Rating] | [@name] |

Overall decision: [Approve / Approve with conditions / Do not deploy],
with reasons and conditions. [Example: "Approved for English and German
pilot with 500 users, subject to C-01 and C-04 being complete."]

## 10. Monitoring and review

<!-- Guidance: Define how risks are tracked after deployment and what triggers reassessment. -->

| Item | Plan |
|---|---|
| Ongoing indicators | [Metrics from section 7 with dashboard link] |
| User feedback channel | *Example:* Thumbs down with reason; reviewed weekly by HR |
| Reassessment triggers | *Example:* New model version, new language, new user group, serious incident, threshold breach |
| Periodic review | *Example:* Every 12 months |
| Reporting | *Example:* Quarterly summary to AI governance board |

## 11. References and glossary

<!-- Guidance: Cite the framework and supporting documents. -->

### 11.1 References

| Reference | Use |
|---|---|
| NIST AI 100-1, *Artificial Intelligence Risk Management Framework (AI RMF 1.0)*, National Institute of Standards and Technology, January 2023 | Functions and trustworthiness characteristics |
| NIST AI RMF Playbook | Suggested actions per subcategory |
| [Organisational AI policy] | Risk appetite and roles |

### 11.2 Glossary

| Term | Meaning |
|---|---|
| Inherent risk | Risk level before the controls in this assessment |
| Residual risk | Risk level expected after controls work as designed |
| Groundedness | Degree to which an answer is supported by the retrieved sources |
| Red team | Structured adversarial testing to find failures |

## Standard and licence note

Based on the NIST Artificial Intelligence Risk Management Framework (AI
RMF 1.0, NIST AI 100-1), a work of the United States government in the
public domain. The template uses its GOVERN, MAP, MEASURE and MANAGE
functions and its trustworthiness characteristics; the wording,
scoring scheme and examples are original to this collection. Template
licence: MIT.