# AI Risk Register Template

**Organisation:** [ORGANISATION NAME]
**Owner:** [NAME / ROLE]
**Date:** [DATE]
**Version:** 1.0

---

## Purpose

A risk register is the working heart of an AI governance programme: one place where every AI risk is described, scored, owned, and tracked to resolution. This register is pre-loaded with 30 common AI risks across eight categories (data leakage, shadow AI, vendor and third party, model behaviour, agentic AI, compliance, intellectual property, and people and process) so your team starts from a credible baseline rather than a blank page.

This document is the register content. The same register is also available as a ready-to-use spreadsheet (ai-risk-register.xlsx) with dropdowns, automatic score calculation, and colour-coded ratings. If your team works in Excel, start there and keep this document as the reference copy.

---

## How to Use

1. Review the 30 pre-loaded risks below. Delete any that do not apply to your organisation and edit the rest so the wording matches your environment and named systems.
2. Add risks specific to your organisation: sector-specific regulation, unusual data types, bespoke models, or known incidents.
3. Score Likelihood and Impact for each risk from 1 to 5 using the Scoring Guide. Multiply them for the inherent score (the risk before controls).
4. Record the key controls in place or planned, and name a control owner who is accountable for them.
5. Re-score likelihood and impact assuming the controls operate as intended. This is the residual score. If it still lands in the red band, the risk needs more treatment or a documented acceptance by someone senior enough to own it.
6. Set a status for each risk (Open, Mitigating, Accepted, Closed) and a next review date, then review on the cadence set out at the end of this document.

---

## Register Structure

Each risk in the register carries the following fields. The spreadsheet version implements them as columns with dropdowns and formulas.

| Field | What to record |
|-------|----------------|
| Risk ID | Stable identifier, e.g. AI-DL-01. Never reuse an ID after closing a risk. |
| Category | One of: Data leakage, Shadow AI, Vendor & third party, Model behaviour, Agentic AI, Compliance, Intellectual property, People & process. |
| Risk description | What could happen, how, and why it matters. Specific enough that a new team member understands it without explanation. |
| Affected AI systems | The tools, models, or agents this risk applies to. Link to your AI system inventory where you have one. |
| Likelihood (1-5) | How likely the risk is to materialise before controls, per the Scoring Guide. |
| Impact (1-5) | How bad it would be if it did, per the Scoring Guide. |
| Inherent score | Likelihood x Impact. Green below 6, amber 6 to 14, red 15 and above. |
| Key controls | The controls that reduce this risk: technical, contractual, and procedural. |
| Control owner | The named role accountable for the controls operating. |
| Residual likelihood / impact (1-5) | The same two ratings, re-scored with controls in place. |
| Residual score | Residual likelihood x residual impact, banded the same way. |
| Status | Open (identified, not yet treated), Mitigating (treatment under way), Accepted (risk formally accepted), Closed (no longer applicable). |
| Next review date | When this risk is next due for review. |

---

## Scoring Guide

Score every risk twice: once before controls (inherent) and once after (residual). Use the definitions below consistently; the value of the register comes from scores meaning the same thing across teams.

### Likelihood (1-5)

| Rating | Label | Definition |
|--------|-------|------------|
| 1 | Rare | May occur only in exceptional circumstances. Not expected within the next three years. |
| 2 | Unlikely | Could occur at some time. Expected roughly once every two to three years. |
| 3 | Possible | Might occur at some time. Expected roughly once a year. |
| 4 | Likely | Will probably occur in most circumstances. Expected several times a year. |
| 5 | Almost certain | Expected to occur in most circumstances. Monthly or more often, or already observed. |

### Impact (1-5)

| Rating | Label | Definition |
|--------|-------|------------|
| 1 | Insignificant | Negligible effect. No data exposure, no regulatory interest, handled within the team. |
| 2 | Minor | Limited internal data exposure or disruption. Contained quickly, no external notification needed. |
| 3 | Moderate | Confidential data exposed or a business process disrupted. Management attention, possible customer questions. |
| 4 | Major | Personal or highly confidential data exposed, regulatory notification likely, material cost or reputational damage. |
| 5 | Severe | Large-scale exposure or harm to individuals. Regulator involvement, legal action, lasting damage to trust or revenue. |

### Risk rating bands

| Band | Score range | Colour | What it means |
|------|-------------|--------|---------------|
| Low | 1 to 5 | Green | Acceptable with routine monitoring. Review at the standard cadence. |
| Medium | 6 to 14 | Amber | Actively mitigate. Assign an owner, agree a treatment plan, review at least quarterly. |
| High | 15 to 25 | Red | Escalate to leadership. Treat before further rollout; consider pausing the activity until controls land. |

---

## Starter Risk Register

The 30 risks below are a starting point drawn from patterns seen across security, risk, and compliance teams governing AI. Scores shown are indicative inherent scores for a typical mid-size organisation with limited AI-specific controls; re-score every risk against your own environment.

### Data leakage

Sensitive data leaving the organisation through AI tools: pasted prompts, uploaded files, recorded meetings, and over-permissive internal assistants.

| ID | Risk | Example key controls | Suggested owner | L | I | Score |
|----|------|----------------------|-----------------|---|---|-------|
| AI-DL-01 | Employees paste customer records, personal information, or other confidential content into public generative AI chatbots to draft emails, summaries, or analysis. The data leaves the corporate boundary and may be retained by the provider or used to improve its models. Affected systems: Public chatbots (ChatGPT, Gemini, Copilot, Claude). | DLP rules that detect and block sensitive content pasted or uploaded to unapproved AI domains; approved enterprise AI workspace with no-training and retention commitments; data classification training with AI-specific examples | Head of Security Operations | 4 | 4 | 16 |
| AI-DL-02 | Developers submit proprietary source code, API keys, or credentials to AI coding assistants or public chatbots while building or debugging. Secrets and unreleased code are exposed to a third party outside the secure development environment. Affected systems: AI coding assistants (GitHub Copilot, Cursor, Claude Code). | Enterprise coding assistant tier with zero data retention; pre-commit and prompt-level secret scanning; secure development policy that names approved assistants and banned content | Head of Engineering | 4 | 4 | 16 |
| AI-DL-03 | AI meeting assistants and notetakers join calls, sometimes uninvited via calendar integrations, then record, transcribe, and store discussions that include commercially sensitive or legally privileged content. Affected systems: AI notetakers (Otter, Fireflies, Zoom AI Companion, Teams Copilot). | Allowlist of approved meeting assistants; conferencing settings that block unapproved bots from joining; standing disclosure and consent step for recorded meetings; retention limits on transcripts | IT Director | 3 | 3 | 9 |
| AI-DL-04 | An internal AI assistant built on retrieval-augmented generation surfaces documents to staff who were never authorised to see the source files, because the search index was built with broader permissions than the underlying repositories. Affected systems: Internal RAG assistants, enterprise search copilots. | Permission-aware connectors that honour source access controls at query time; scope review before each new data source is indexed; access certification and red-team testing before go-live | Head of IT / Platform Owner | 3 | 4 | 12 |

### Shadow AI

AI usage that governance cannot see: unapproved tools, personal accounts, AI browser extensions, and embedded AI features switched on by vendors.

| ID | Risk | Example key controls | Suggested owner | L | I | Score |
|----|------|----------------------|-----------------|---|---|-------|
| AI-SA-01 | Staff adopt AI tools that IT and security have never seen or assessed. Usage is invisible to governance, so no one knows what data flows into these tools, where it is stored, or what terms apply. Affected systems: Unknown by definition; any unsanctioned AI tool. | Continuous AI usage discovery across network, SSO, and browser telemetry; a fast, well-publicised approval pathway; a sanctioned tool catalogue that covers the most common use cases | CISO | 5 | 3 | 15 |
| AI-SA-02 | Employees use personal accounts on consumer AI services for work tasks. Company data sits outside enterprise controls, cannot be retrieved or deleted when staff leave, and is covered by consumer terms rather than a negotiated agreement. Affected systems: Consumer tiers of ChatGPT, Gemini, Claude and similar. | Enforce SSO and enterprise tenancy for approved tools; block personal-account logins to AI services on managed devices; acceptable use policy that names the practice explicitly | IT Director | 4 | 3 | 12 |
| AI-SA-03 | Browser extensions with embedded AI read the content of every page a user visits, including CRM records, internal dashboards, and webmail, and send it to third-party services for processing. Affected systems: AI browser extensions and sidebars. | Managed browser with an extension allowlist; periodic audit of installed extensions against the approved register; security review before any AI extension is approved | Head of Security Operations | 3 | 4 | 12 |
| AI-SA-04 | Business units subscribe to SaaS products whose vendors have switched on embedded AI features by default. AI processing starts on company data without procurement, security, or privacy review. Affected systems: Existing SaaS estate (CRM, HR, support, productivity suites). | Procurement gate with AI-specific questions; vendor register that flags AI features per product; contract clause requiring advance notice when a vendor adds AI features | Head of Procurement | 4 | 3 | 12 |

### Vendor & third party

Risk that sits with the AI providers themselves: training on your data, residency drift, silent model changes, and vendor breaches.

| ID | Risk | Example key controls | Suggested owner | L | I | Score |
|----|------|----------------------|-----------------|---|---|-------|
| AI-VN-01 | An AI vendor's default terms allow customer prompts and uploaded content to be used to train or improve its models. Company data becomes part of a model that serves other customers, including competitors. Affected systems: All third-party AI tools and AI features in SaaS. | Contractual restriction on training with customer data; enterprise tier with the training opt-out verified in writing; data processing agreement reviewed at onboarding and at renewal | General Counsel | 3 | 4 | 12 |
| AI-VN-02 | A vendor or one of its subprocessors moves storage or inference to a jurisdiction that conflicts with the organisation's data residency commitments to customers and regulators. Affected systems: AI vendors with offshore or multi-region infrastructure. | Subprocessor list review at onboarding and on notification of change; residency clauses with audit rights; transfer impact assessments for cross-border data flows | Data Protection Officer | 3 | 4 | 12 |
| AI-VN-03 | A vendor updates or replaces the underlying model without notice. Output behaviour of dependent workflows changes silently, breaking prompts, quality baselines, and downstream decisions. Affected systems: AI APIs and embedded model features. | Change-notification clauses in the contract; version pinning where the vendor offers it; regression test suite run on critical workflows after each known change | Product / Engineering Owner | 4 | 3 | 12 |
| AI-VN-04 | A security breach at an AI vendor exposes stored prompts, outputs, or fine-tuning data containing company or customer information. Affected systems: All third-party AI vendors. | Vendor security due diligence (SOC 2 Type II, ISO 27001); incident notification SLA in the contract; minimise sensitive data sent in prompts; retention and deletion commitments | CISO | 2 | 4 | 8 |

### Model behaviour

The model does something you did not want: hallucination, bias, drift, or manipulation through prompt injection.

| ID | Risk | Example key controls | Suggested owner | L | I | Score |
|----|------|----------------------|-----------------|---|---|-------|
| AI-MB-01 | Staff rely on fabricated (hallucinated) AI output, such as invented citations, figures, or legal positions, in customer communications, reports, or regulated decisions. Affected systems: All generative AI assistants and copilots. | Human review gate for any consequential or external-facing output; grounding and citation requirements for research use; training that builds verification habits | Business Unit Owners | 4 | 4 | 16 |
| AI-MB-02 | An AI system used in hiring, lending, insurance, or another consequential decision produces systematically biased outcomes against a protected group, creating legal exposure and harm to individuals. Affected systems: HR screening tools, credit and risk scoring models. | Bias and fairness testing before deployment and on a recurring schedule; documented human oversight of every consequential decision; legal review of use cases against anti-discrimination law | Model Owner / Head of People | 3 | 5 | 15 |
| AI-MB-03 | Model quality degrades over time as input data drifts or the vendor silently updates the model, and the degradation goes unnoticed because nobody monitors outputs against a baseline. Affected systems: Production ML models and vendor AI features. | Output quality monitoring with alert thresholds; periodic evaluation runs against a fixed benchmark; rollback criteria and procedure agreed in advance | Head of Data / ML Engineering | 3 | 3 | 9 |
| AI-MB-04 | Malicious instructions hidden in documents, webpages, or emails that an AI system processes cause it to ignore its instructions, exfiltrate data, or produce attacker-controlled output (prompt injection). Affected systems: AI assistants that read external content; RAG systems; browser agents. | Input sanitisation and isolation of untrusted content; output filtering; least-privilege data access for the assistant; red-team testing focused on injection | Head of Security Operations | 4 | 4 | 16 |

### Agentic AI

Autonomous agents that act on systems rather than just answering questions, where a mistake becomes an action.

| ID | Risk | Example key controls | Suggested owner | L | I | Score |
|----|------|----------------------|-----------------|---|---|-------|
| AI-AG-01 | An autonomous agent performs actions beyond its intended scope: sending communications, modifying records, executing transactions, or deploying code without approval. Affected systems: AI agents with write access to business systems. | Least-privilege permission scoping per agent; human approval gate for irreversible or external actions; comprehensive action logging; documented kill switch tested regularly | CISO / Platform Owner | 3 | 5 | 15 |
| AI-AG-02 | Credentials issued to an AI agent (API keys, tokens, service accounts) are compromised, and the attacker inherits everything the agent is permitted to do across connected systems. Affected systems: AI agents and their service accounts. | Short-lived, tightly scoped credentials; secrets vaulting with rotation; anomaly detection on agent activity patterns; separate identity per agent | Head of Security Operations | 2 | 5 | 10 |
| AI-AG-03 | In a chained or multi-agent workflow, one incorrect output propagates through subsequent automated steps, compounding the error before any human sees it. Affected systems: Multi-step agent workflows and orchestration platforms. | Validation checkpoints between workflow steps; circuit breakers that halt on anomalies; bounded retries; end-to-end monitoring with alerting | Head of Engineering | 3 | 4 | 12 |
| AI-AG-04 | An agent takes an action and nobody can reconstruct why: prompts, intermediate steps, tool calls, and data accessed were not logged, making incident response and audit impossible. Affected systems: All deployed AI agents. | Mandatory logging of agent inputs, tool calls, and actions; log retention aligned to audit and legal hold requirements; periodic review of agent decision logs | Head of IT | 4 | 3 | 12 |

### Compliance

Regulatory exposure from AI use: classification obligations, privacy law, automated decision-making rules, and the ability to evidence governance.

| ID | Risk | Example key controls | Suggested owner | L | I | Score |
|----|------|----------------------|-----------------|---|---|-------|
| AI-CP-01 | AI systems in scope of the EU AI Act or other AI-specific regulation are never identified or classified, so mandatory obligations such as transparency, risk management, and documentation are missed. Affected systems: Entire AI portfolio. | Maintained AI inventory with regulatory classification per system; regulatory watch covering every jurisdiction you operate in; counsel review of candidate high-risk systems | Head of Compliance | 3 | 4 | 12 |
| AI-CP-02 | Personal data is processed by AI tools without a lawful basis, an updated privacy notice, or a required privacy impact assessment, breaching GDPR or other applicable privacy law. Affected systems: Any AI tool processing personal data. | Privacy impact assessment for each new AI use case involving personal data; privacy notices updated to describe AI processing; records of processing kept current | Data Protection Officer | 3 | 4 | 12 |
| AI-CP-03 | AI makes or substantially shapes decisions about individuals (hiring, credit, service eligibility) without the human review, explanation, or disclosure that applicable law requires. Affected systems: Decision-support and screening tools. | Use-case register that flags automated decision-making; human-in-the-loop review for consequential decisions; disclosure statements provided to affected individuals | General Counsel | 3 | 4 | 12 |
| AI-CP-04 | When an auditor, enterprise customer, or regulator asks how AI is governed, the organisation cannot produce evidence: no register, no approval records, no control documentation. Affected systems: Governance programme itself. | Centralised AI register with controls and evidence attached; documented approval workflow with retained records; regular governance reporting to a named committee | Head of Compliance | 4 | 3 | 12 |

### Intellectual property

Ownership and protection of what goes into and comes out of AI: copyright, trade secrets, and code licences.

| ID | Risk | Example key controls | Suggested owner | L | I | Score |
|----|------|----------------------|-----------------|---|---|-------|
| AI-IP-01 | AI-generated content published by the organisation reproduces third-party copyrighted material, or key assets created with heavy AI assistance turn out to have weak or no copyright protection. Affected systems: Content generation tools (text, image, video, audio). | Editorial review of AI-generated content before publication; vendor indemnity for IP claims where available; guidance on documenting human creative contribution | General Counsel | 3 | 3 | 9 |
| AI-IP-02 | Trade secrets or other crown-jewel information submitted to an external AI tool loses confidentiality protection, weakening the organisation's legal position and competitive advantage. Affected systems: Public and third-party AI tools. | Explicit prohibition on trade secrets in AI prompts; DLP patterns tuned to crown-jewel content; targeted training for R&D and strategy teams | General Counsel | 3 | 4 | 12 |
| AI-IP-03 | An AI coding assistant reproduces code under a restrictive or copyleft licence into the proprietary codebase, creating licence contamination that is discovered late, often during due diligence. Affected systems: AI coding assistants. | Automated licence and provenance scanning in CI; assistant settings that block verbatim reproduction of public code; open-source usage policy that covers AI-generated code | Head of Engineering | 3 | 3 | 9 |

### People & process

The human layer: overreliance on AI output, unclear ownership of AI risk, and policies that exist only on paper.

| ID | Risk | Example key controls | Suggested owner | L | I | Score |
|----|------|----------------------|-----------------|---|---|-------|
| AI-PP-01 | Staff stop challenging AI output (automation bias). Errors that a trained person would once have caught pass straight through, and skills atrophy as tasks are delegated to AI. Affected systems: All AI assistants in daily workflows. | Verification steps written into standard operating procedures; training on known AI failure modes; sampling review of AI-assisted work by supervisors | Business Unit Owners | 4 | 3 | 12 |
| AI-PP-02 | No single function owns AI risk. Security assumes Legal has it, Legal assumes IT has it, and the gaps between teams leave risks unassessed and incidents unowned. Affected systems: Governance programme itself. | AI governance committee with a charter and decision rights; named risk owner for every system in the register; documented escalation path for AI incidents | CISO / Executive Sponsor | 3 | 3 | 9 |
| AI-PP-03 | An AI acceptable use policy exists on paper but staff have never been trained on it, so day-to-day behaviour is unchanged and the policy provides little protection in practice. Affected systems: Organisation-wide. | Mandatory AI training at onboarding and annually; signed acknowledgment records; targeted refreshers after incidents or policy changes | Head of People | 4 | 3 | 12 |

---

## Residual Risk Tracking

Once controls are recorded, re-score each risk and track it to resolution. The residual ratings below are indicative examples assuming the listed controls are implemented and operating; replace them with your own assessment.

| ID | Residual likelihood | Residual impact | Residual score | Status | Next review |
|----|---------------------|-----------------|----------------|--------|-------------|
| AI-DL-01 | 2 | 4 | 8 | Mitigating | [DATE] |
| AI-DL-02 | 2 | 4 | 8 | Mitigating | [DATE] |
| AI-DL-03 | 2 | 3 | 6 | Mitigating | [DATE] |
| AI-DL-04 | 2 | 4 | 8 | Open | [DATE] |
| AI-SA-01 | 3 | 3 | 9 | Mitigating | [DATE] |
| AI-SA-02 | 2 | 3 | 6 | Mitigating | [DATE] |
| AI-SA-03 | 2 | 4 | 8 | Open | [DATE] |
| AI-SA-04 | 3 | 3 | 9 | Open | [DATE] |
| AI-VN-01 | 1 | 4 | 4 | Mitigating | [DATE] |
| AI-VN-02 | 2 | 4 | 8 | Open | [DATE] |
| AI-VN-03 | 3 | 2 | 6 | Accepted | [DATE] |
| AI-VN-04 | 2 | 3 | 6 | Open | [DATE] |
| AI-MB-01 | 3 | 3 | 9 | Mitigating | [DATE] |
| AI-MB-02 | 2 | 5 | 10 | Mitigating | [DATE] |
| AI-MB-03 | 2 | 3 | 6 | Open | [DATE] |
| AI-MB-04 | 3 | 4 | 12 | Mitigating | [DATE] |
| AI-AG-01 | 2 | 5 | 10 | Mitigating | [DATE] |
| AI-AG-02 | 1 | 5 | 5 | Open | [DATE] |
| AI-AG-03 | 2 | 4 | 8 | Open | [DATE] |
| AI-AG-04 | 2 | 3 | 6 | Mitigating | [DATE] |
| AI-CP-01 | 2 | 4 | 8 | Mitigating | [DATE] |
| AI-CP-02 | 2 | 4 | 8 | Mitigating | [DATE] |
| AI-CP-03 | 2 | 4 | 8 | Open | [DATE] |
| AI-CP-04 | 2 | 3 | 6 | Mitigating | [DATE] |
| AI-IP-01 | 2 | 3 | 6 | Open | [DATE] |
| AI-IP-02 | 2 | 4 | 8 | Mitigating | [DATE] |
| AI-IP-03 | 2 | 3 | 6 | Open | [DATE] |
| AI-PP-01 | 3 | 3 | 9 | Open | [DATE] |
| AI-PP-02 | 2 | 3 | 6 | Mitigating | [DATE] |
| AI-PP-03 | 2 | 3 | 6 | Mitigating | [DATE] |

---

## Worked Example

How a completed entry should read once tailored:

| Field | Entry |
|-------|-------|
| Risk ID | AI-DL-01 |
| Category | Data leakage |
| Risk description | Customer service staff paste customer account details into public AI chatbots to draft responses. Data leaves our controlled environment and may be retained by the provider. |
| Affected AI systems | ChatGPT (consumer), Gemini (consumer) |
| Likelihood / Impact | 4 / 4 (inherent score 16, red) |
| Key controls | DLP policy blocking PII paste to unapproved AI domains (live); enterprise AI workspace with no-training terms rolled out to customer service (live); AI acceptable use module in onboarding (planned Q3) |
| Control owner | Head of Security Operations |
| Residual likelihood / impact | 2 / 4 (residual score 8, amber) |
| Status | Mitigating |
| Next review date | [DATE, quarterly while amber] |

---

## Review Cadence and Maintenance

| Rating band | Minimum review cadence |
|-------------|------------------------|
| Red (15-25) | Monthly until treated below 15, then quarterly |
| Amber (6-14) | Quarterly |
| Green (1-5) | Annually, or when circumstances change |

Re-score a risk whenever any of the following occurs, not just at the scheduled review:

- A new AI tool, vendor, or agent is adopted, or a shadow AI tool is discovered
- A vendor changes its model, terms, or subprocessors
- An AI-related incident or near miss occurs, inside or outside the organisation
- A relevant law or regulation changes in a jurisdiction you operate in
- The business starts using an existing AI system for a new purpose or new data

Report movement, not just the snapshot: the most useful output for leadership is which risks moved bands since last quarter, which treatments are overdue, and which new risks entered the register. Pair this register with an AI system inventory so every risk row can point at the concrete systems it covers.

---

*Provided free by [Aona AI](https://aona.ai). Aona discovers every AI tool in use across your organisation, monitors what data flows into them, and keeps your AI inventory audit-ready.*