AI Risk Register: Structure, Starter Risks, and Review Cadence

Every AI project has a list of things that could go wrong, usually in someone's head. A risk register moves that list into a document where each risk has a score, a control, an owner, and a review date, so it becomes work rather than worry. It is also the first document auditors, boards, and insurers ask for, and its absence is itself a finding. This guide covers the structure, a starter list of AI-specific risks, scoring, and cadence, drawing on FISTA Solutions' AI enablement practice. The wider risk framework is in ai model risk management and the standard in nist ai risk management framework explained.

What does a register entry contain?

Field	Content
Identifier and system	Which system or the program
Risk statement	What could happen and what would cause it
Category	Quality, safety, security, privacy, compliance, cost, vendor, adoption, delivery
Likelihood	Scored on a defined scale with reasoning
Impact	Scored on a defined scale with reasoning
Rating	Derived from likelihood and impact
Control	The specific measure that reduces likelihood or impact
Control evidence	How the control's operation is verified
Owner	Named person accountable
Status and review date	Open, mitigated, accepted, closed; next review

What AI-specific risks belong in a starter list?

• Quality: accuracy below threshold on a category; groundedness failures; regression after prompt or model change. Controls: golden datasets, CI gates, production sampling. See the ai evaluation checklist.
• Safety and fairness: harmful, biased, or non-compliant outputs. Controls: safety suites, fairness testing, output policy checks.
• Security: prompt injection, tool misuse, jailbreaks. Controls: structural separation, least-privilege tools, validation, red teaming. See ai agent security risks.
• Privacy: personal data in prompts, logs, or memory; unauthorized retrieval. Controls: redaction, permission-aware retrieval, retention. See ai data privacy compliance.
• Cost: usage growth beyond budget; provider price changes. Controls: attribution, budgets, routing, caching. See ai cost optimization checklist.
• Vendor: silent model changes, deprecation, outages, dependence. Controls: pinning, evaluation on updates, fallbacks, exit terms. See ai third party risk management.
• Adoption: users ignore or over-rely on the system. Controls: change management, trust patterns, usage measurement.
• Compliance: regulatory obligations unmet; disclosure failures. Controls: tiering, documentation, legal review.
• Delivery: scope drift, data unavailable, integration blocked. Controls: specification, checkpoints, dependencies managed.

How should risks be scored?

Define likelihood and impact scales, typically three to five levels each, with descriptions so scores are comparable across systems. Derive a rating that sets review cadence and escalation thresholds. Record the reasoning behind each score, because scores without reasoning cannot be challenged or updated sensibly. Rescore at project checkpoints, after incidents, and after model or vendor changes. Assessment method is in the ai privacy impact assessment checklist for the privacy dimension.

How do system and program registers relate?

Each AI system has its own register maintained by its owner. A program-level register aggregates cross-cutting risks such as platform dependence, governance capacity, skills gaps, and regulatory change, and rolls up the highest-rated system risks. The program register is what the governance board and executive risk committee review. Governance structure is in ai governance board.

How do controls and evidence close the loop?

A control is specific and verifiable: not "we test for bias" but "fairness tests by protected attribute run in CI with thresholds; results attached to each release." Control evidence, such as test reports, gate logs, and monitoring dashboards, is referenced from the register so reviewers and auditors can verify operation without interviews. Controls without evidence are assertions. Monitoring practice is in the ai observability checklist.

What review cadence works?

High-risk systems monthly; medium quarterly; low annually; program register quarterly; and immediate review after incidents, model or vendor changes, regulatory developments, or material scope changes. Reviews update scores, verify control evidence, close mitigated risks, add new ones, and escalate ratings above threshold. Audit expectations are in what is an ai audit.

What are common mistakes?

Risks stated so vaguely they cannot be controlled; controls that are intentions rather than mechanisms; no owners; scores without reasoning; registers created for an audit and abandoned; and no link between the register and the delivery process, so new risks from changes never enter it. Each is visible to an auditor in minutes. Documentation integration is in the ai documentation checklist.

How FISTA Solutions helps build AI risk registers

FISTA Solutions builds system-level registers as part of every specification, implements controls with verifiable evidence in delivery pipelines, and helps clients establish program registers with scoring scales and review cadences tied to governance. The AI enablement practice leads governance design, forward deployed engineers embed with client risk and engineering teams, and AI agents ship with controls and evidence. The record behind the approach is 150+ projects for 50+ companies.

To turn AI risk from concern into managed work, message FISTA on WhatsApp, or read ai model risk management for the framework the register operates within.