AI Risk Register
Template
A structured template for tracking AI system risks, likelihood, impact, controls, and remediation status across your AI portfolio.
Educational notice: This template provides a starting framework for AI risk management. Production deployments should undergo organization-specific risk assessment with qualified security and compliance professionals. Risks and controls should be tailored to your specific architecture, data types, and regulatory environment.
Synopsis
A risk register is the foundation of AI governance. This template covers data and privacy risks, prompt injection vectors, tool and action security, infrastructure and supply chain threats, model behavior and output risks, organizational factors, and compliance gaps — aligned with the NIST AI RMF functions of Govern, Map, Measure, and Manage. Each risk includes likelihood, impact, recommended controls, an owner, and status tracking. Use it alongside the AI Security Tools, the Vendor Due-Diligence Checklist, the Incident Evidence Checklist, and the Streamlit architecture guide.
Risk Prioritization Framework
Not all risks are equal. Use this framework to decide what to fix first.
Fix immediately (Critical impact)
Fix this quarter (High likelihood + High impact)
Plan and monitor (Medium likelihood + Medium impact)
Accept and document (Low likelihood + Low impact)
NIST AI RMF Mapping
This risk register aligns with the four functions of the NIST AI Risk Management Framework. Use this mapping to integrate the register into your broader AI governance program.
Govern — Policies, procedures, and accountability
Map — Context and risk identification
Measure — Assessment and testing
Manage — Mitigation and response
Scenario: From Risk Identification to Remediation
A financial services firm builds an internal AI assistant using Streamlit and RAG. The engineering lead runs through the risk register and identifies the following chain:
How to use: Copy this structure into a spreadsheet or governance tool. Assign owners, set target dates, and update status as controls are implemented. Review quarterly or after significant architecture changes.
Data & Privacy
| ID | Risk | Likelihood | Impact | Controls | Owner | Status |
|---|---|---|---|---|---|---|
| R-01 | Unauthorized data access through RAG retrieval without RLS | Medium | High | Tenant filters before retrieval, metadata-based access control | Data Engineering | Open |
| R-02 | Sensitive data leakage through global caching | Medium | High | Session-scoped cache keys, no global cache for sensitive data | Platform Team | Open |
| R-03 | PHI exposure in model prompts sent to external API | Low | Critical | DLP scanning, data minimization in prompts, on-premise model option | Security | Open |
Prompt Injection & Manipulation
| ID | Risk | Likelihood | Impact | Controls | Owner | Status |
|---|---|---|---|---|---|---|
| R-04 | Direct prompt injection overriding system instructions | High | High | Server-side authorization, structured output validation, pattern detection | Application Security | Open |
| R-05 | Indirect injection via poisoned RAG documents | Medium | Critical | Content sanitization, document provenance, human approval for actions | Data Engineering | Open |
| R-06 | Injection via MCP tool descriptions | Low | High | Tool description review, trusted MCP servers only, tool allow-list | Platform Team | Open |
Tool & Action Security
| ID | Risk | Likelihood | Impact | Controls | Owner | Status |
|---|---|---|---|---|---|---|
| R-07 | Excessive tool permissions (principle of least privilege violation) | High | High | Tool allow-list per use case, regular permission audit | Engineering | Open |
| R-08 | Automatic action execution without human approval | Medium | Critical | Human approval for action/admin tools, server-side approval workflow | Engineering | Open |
| R-09 | Model output trusted as authorization decision | Medium | Critical | Server-side authorization independent of model, identity provider verification | Security | Open |
Infrastructure & Supply Chain
| ID | Risk | Likelihood | Impact | Controls | Owner | Status |
|---|---|---|---|---|---|---|
| R-10 | Compromised MCP server exfiltrating data | Low | Critical | Trusted publishers, network egress restrictions, sandbox MCP servers | Security | Open |
| R-11 | Model vendor retaining sensitive prompts | Medium | High | DPA with vendor, DLP scanning, on-premise fallback for sensitive data | Legal & Security | Open |
| R-12 | Session State used as authoritative storage | Medium | Medium | Durable storage for all consequential state, external database for audit | Engineering | Open |
Shadow AI & Unauthorized Usage
| ID | Risk | Likelihood | Impact | Controls | Owner | Status |
|---|---|---|---|---|---|---|
| R-13 | Employees using personal ChatGPT/Claude/Gemini with company confidential data | High | High | Acceptable use policy, DLP on egress traffic, sanctioned AI tool provision, employee training, monitoring for unsanctioned AI usage | Security & HR | Open |
| R-14 | Teams adopting unsanctioned SaaS AI tools without security or legal review | High | Medium | Procurement policy requiring security review for AI tools, SaaS discovery scanning, quarterly AI tool inventory audit, credit card expense review for AI subscriptions | IT & Security | Open |
| R-15 | Employees pasting source code, financial data, or PII into public AI chatbots | High | Critical | Data classification policy, DLP scanning for AI chatbot domains, employee training with real examples, sanctioned enterprise AI with no-training-on-data clause | Security | Open |
| R-16 | Shadow AI usage creating undocumented data flows to unvetted third parties | Medium | High | Network egress monitoring for AI API endpoints, data flow mapping, vendor due diligence on discovered tools, remediation plan for unauthorized tools | Security | Open |
AI in Hiring & Employment Decisions
| ID | Risk | Likelihood | Impact | Controls | Owner | Status |
|---|---|---|---|---|---|---|
| R-17 | AI hiring tool used without independent bias audit (NYC LL 144 violation) | Medium | Critical | Annual independent bias audit by qualified third party, public posting of audit summary, candidate notice 10 business days before use, audit retention per NYC DCWP requirements | HR & Legal | Open |
| R-18 | Candidates not notified of AI use in hiring decisions (multi-state violation) | Medium | High | Candidate notification template covering NYC LL 144, Illinois AIVIA, California FEHA, Colorado SB 189, EU AI Act Article 50; notification in job posting and before assessment; consent for video interview AI analysis | HR & Legal | Open |
| R-19 | Algorithmic discrimination through biased training data or model behavior | Medium | Critical | Disparate impact testing (four-fifths rule), demographic data collection where legally permitted, human review for all adverse decisions, appeal process for rejected candidates, California FEHA 4-year record retention | HR & Compliance | Open |
| R-20 | Unauthorized biometric analysis (facial expression, voice emotion) in video interviews | Low | Critical | Prohibit emotion recognition AI in hiring (EU AI Act Article 5 ban), verify vendor does not use biometric categorization, Illinois BIPA compliance, Maryland HB 1202 consent requirements, documented vendor attestation | HR & Legal | Open |
| R-21 | AI employment decisions made without human oversight or appeal mechanism | Medium | High | Human-in-the-loop for all hiring decisions, documented override authority, candidate appeal process, EU AI Act Article 26-27 compliance (human oversight + fundamental rights impact assessment), GDPR Article 22 right to human review | HR & Legal | Open |
| R-22 | AI vendor changes model or training data without bias re-audit notification | Medium | High | Contract clause requiring vendor notification on model updates, right to re-audit on model change, version pinning where possible, annual re-evaluation regardless of vendor notifications | HR & Procurement | Open |
Model Behavior & Output Risks
| ID | Risk | Likelihood | Impact | Controls | Owner | Status |
|---|---|---|---|---|---|---|
| R-26 | AI hallucination causing real-world harm (fabricated citations, invented medical advice, false financial data) | Medium | High | Output validation against source data, grounding requirements, human review for consequential outputs, citation verification, disclaimer on AI-generated content, user training on hallucination risks | Engineering & Legal | Open |
| R-27 | Model drift or performance degradation over time without detection | Medium | Medium | Continuous model performance monitoring, drift detection alerts, scheduled re-evaluation, vendor notification on model updates, A/B testing against baseline outputs | Engineering | Open |
| R-28 | AI-generated content infringing third-party copyright or IP | Medium | High | Output similarity scanning, vendor indemnification for IP claims, training data provenance disclosure, opt-out from training on copyrighted data, content attribution where possible | Legal & Engineering | Open |
| R-29 | Third-party model provider outage or degradation with no fallback | Low | High | Multi-provider architecture, cached response capability, degraded mode operation, SLA with provider, incident response playbook for provider outage | Engineering | Open |
Organizational & Human Factors
| ID | Risk | Likelihood | Impact | Controls | Owner | Status |
|---|---|---|---|---|---|---|
| R-30 | Lack of AI literacy and training for end users (blind trust in AI outputs) | High | Medium | Mandatory AI literacy training, documented AI limitations, output review checkpoints, feedback mechanism for incorrect outputs, role-based training on when to trust vs. verify AI outputs | HR & Security | Open |
| R-31 | Cross-jurisdictional regulatory misalignment (compliant in one state/country but non-compliant in another) | Medium | High | Jurisdictional compliance matrix, multi-state regulatory tracking, per-jurisdiction notification templates, legal review for cross-border deployments, modular compliance controls by region | Legal & Compliance | Open |
Compliance & Governance
| ID | Risk | Likelihood | Impact | Controls | Owner | Status |
|---|---|---|---|---|---|---|
| R-32 | Missing AI system documentation for regulatory disclosure | Medium | High | AI system registry, disclosure review process, automated documentation | Compliance | Open |
| R-33 | No incident response plan for AI security events | Medium | High | AI incident response playbook, evidence preservation checklist, tabletop exercises | Security | Open |
| R-34 | Bias or discrimination in consequential AI decisions (non-hiring: lending, insurance, healthcare) | Low | High | Bias testing, human review for consequential decisions, appeal process, NIST AI RMF alignment, ECOA/Regulation B compliance for lending, CFPB guidance adherence | Compliance | Open |
Download the AI Risk Register Spreadsheet
FAQ
How is an AI risk register different from a traditional IT risk register?⌄
Traditional IT risk registers focus on infrastructure, access control, and data breaches. An AI risk register must additionally cover prompt injection (where the attack vector is natural language), RAG poisoning (where the data source itself is the attack vector), tool abuse (where the model is manipulated into taking actions), model-driven authorization bypass (where the application trusts model output for access decisions), and supply-chain risks from MCP servers and model vendors. These risks do not exist in traditional software.
Should every AI application have its own risk register?⌄
Small, low-risk applications (e.g., a single-user summarization tool with no sensitive data) can share a portfolio-level register. Any application with access to confidential data, more than 10 users, or action/admin tools should have its own register entry with application-specific risks, controls, and owners.
How do I know when to add a new risk to the register?⌄
Add a new risk whenever: (1) a new data source is connected, (2) a new tool or MCP server is integrated, (3) the user population expands significantly, (4) the deployment model changes, (5) a security incident occurs (even if caught before impact), or (6) a new regulatory requirement applies. Review the register quarterly and after any architecture change.
What is the difference between likelihood and impact?⌄
Likelihood is the probability that the risk will materialize given your current controls and architecture. Impact is the severity of consequences if it does materialize — considering data sensitivity, number of users affected, financial cost, regulatory exposure, and reputational damage. A risk with Low likelihood but Critical impact (e.g., PHI exposure) still demands immediate attention.