AI Product Risk Registry Template: Track and Manage AI Product Risks
TL;DR
Most AI product teams manage risks reactively: a model provider outage hits without a backup plan, a regulatory change catches the team by surprise, or a quality degradation after a silent model update goes undetected for weeks. A risk registry forces this thinking ahead of time. This template covers the five categories of AI product risk, a 1-5 scoring matrix for likelihood and impact, a format for each risk entry, and a quarterly review process that keeps the registry from becoming shelf-ware.
The AI PM Minute
One tactic to make you a sharper AI PM, twice a week. 60 seconds to read. Free.
No fluff. Unsubscribe anytime.
Why AI Products Need a Dedicated Risk Registry
Standard software engineering has a risk management tradition: security reviews, dependency audits, architecture review boards. AI products inherit all of those risks and add a new layer that most traditional frameworks do not capture well.
The difference is that AI products have risk categories tied to the behavior of a system they do not fully control (the foundation model), data they do not fully own (user data processed by a third-party model), and regulatory frameworks that were written for algorithmic decision-making but are now being applied to generative AI in ways that are still being interpreted.
Scenario: A model provider deprecates a model version you depend on
Typical impact without a registry: Engineering scrambles to test a replacement model on all production prompts and workflows, usually in 30 to 90 days. Every feature that relies on a specific fine-tune or system prompt behavior must be re-evaluated.
Scenario: A silent model update changes output behavior
Typical impact without a registry: Quality regressions appear in production before monitoring detects them. Customer-facing quality degradation goes unnoticed for days or weeks. This has happened to teams on GPT-4 and on Claude Sonnet model updates.
Scenario: A regulatory body publishes guidance that requires changes to your AI disclosure or logging practices
Typical impact without a registry: Legal requests a 2-week turnaround on audit trail infrastructure that engineering estimated at 6 weeks. The feature launch behind it slips a quarter.
Scenario: A data processing agreement with your LLM provider is challenged under GDPR or the EU AI Act
Typical impact without a registry: Sales loses an enterprise deal in Germany because the DPA review is inconclusive. Product roadmap is blocked pending legal resolution.
A risk registry does not prevent these events. It ensures that when they happen, your team has a pre-thought owner, a mitigation plan, and a communication protocol, instead of spending the first three days just figuring out who is responsible.
The Five AI Product Risk Categories
Organize your registry around these five categories. Each maps to a different part of the organization that needs to be involved in mitigation:
1. Model Risk
Owner: Engineering + ProductRisks originating from the AI model itself or from changes to it: deprecation, quality drift, unexpected behavior on edge case inputs, fine-tuning regressions, hallucination rates in high-stakes outputs, and context window limitations.
Example registry entries:
Provider deprecates gpt-4-turbo by December 2026 with 90-day notice
Silent update to Claude Sonnet 5 changes summarization style and breaks customer-facing template
Hallucination rate on medical terminology inputs exceeds 5%, triggering a disclosure obligation
2. Data Risk
Owner: Legal + Privacy + EngineeringRisks related to how data flows through your AI system: user data sent to third-party model providers, training data provenance, inference data retention by providers, and data quality issues that degrade model performance over time.
Example registry entries:
LLM provider updates data processing terms to allow training on API calls sent without explicit opt-out
Customer uploads personally identifiable information in a free-text field that is included in a model prompt
Training dataset sourced from a contractor contains copyrighted material; copyright holder files DMCA notice
3. Regulatory Risk
Owner: Legal + Compliance + ProductRisks from AI-specific regulations: EU AI Act enforcement milestones, US state AI laws, sector-specific rules (HIPAA for healthcare AI, Fair Credit Reporting Act for credit scoring AI, EEOC guidance for hiring AI), and evolving disclosure requirements.
Example registry entries:
EU AI Act Annex III audit requirements take effect for HR tool category in Feb 2027
California AB-302 requires disclosure of AI decision-making in consumer financial products; launch timeline affected
FTC begins enforcement action against AI products that make unsubstantiated accuracy claims
4. Operational Risk
Owner: Engineering + Product + Customer SuccessRisks that affect reliability and continuity: provider outages, rate limit changes, latency degradation, pricing increases, and single-provider dependency. Distinct from model risk because they affect availability, not output quality.
Example registry entries:
OpenAI ChatCompletion API outage during US business hours; no fallback model configured
Provider raises API pricing 30% with 30-day notice; margin structure becomes negative on free tier
Rate limit reduction from 10,000 to 3,000 RPM blocks enterprise customer peak usage
5. Competitive and Business Risk
Owner: Product + StrategyRisks that threaten the business case for the product: a foundation model provider ships a feature that directly competes with your product, your AI moat is copied or commoditized, or user trust is damaged by a high-profile AI failure in your category.
Example registry entries:
OpenAI ships native document review feature that replicates 60% of your product's core workflow
Competitor uses the same model, same prompting approach, and undercuts on price by 40%
A high-profile AI hallucination incident in your category triggers user skepticism that depresses activation across the board
Risk Scoring Matrix: Likelihood x Impact
Each risk in the registry gets a score for likelihood (how likely is this to occur in the next 12 months?) and impact (how bad is it if it does occur?). Use a 1-5 scale for each. The product of the two scores is the risk priority number (RPN). Risks with RPN above 12 get a mitigation plan; risks with RPN above 16 get an owner and a review date.
| Score | Likelihood | Impact |
|---|---|---|
| 1 | Unlikely in 12 months; no industry precedent | Negligible; recoverable in under 1 day with no user impact |
| 2 | Possible but no signals; rare in industry | Minor; recoverable in 1-3 days, affects less than 5% of users |
| 3 | Plausible; has happened to similar products in the past year | Moderate; affects 5-25% of users or delays a roadmap item by 1-4 weeks |
| 4 | Likely; specific signals or precedents in the past 6 months | Significant; affects 25-50% of users, causes a launch delay, or creates a legal obligation |
| 5 | Near-certain; already announced or actively developing | Critical; affects majority of users, threatens revenue, or creates regulatory liability |
Scoring example
GPT-4-turbo deprecation: Likelihood 4 (announced, known timeline), Impact 4 (requires prompt testing across all workflows, 2-4 week migration). RPN = 16. This gets an owner (senior engineer), a mitigation plan (test GPT-5 parity on top 20 prompts by November), and a review date (4 weeks out).
Learn to Manage AI Products Systematically
The AI PM Masterclass covers risk management, vendor strategy, and the product judgment to anticipate what goes wrong before it does. Taught live by a Salesforce Sr. Director PM.
Risk Entry Format: What Each Row Should Contain
Each risk entry in the registry needs seven fields. Fewer fields and the registry becomes a parking lot for vague concerns. More fields and no one maintains it.
Risk ID
A unique identifier. Use a prefix by category: MODEL-001, DATA-001, REG-001, OPS-001, BIZ-001. This makes it easy to filter by category and track changes over time.
Example: OPS-003
Risk description
One sentence describing the specific risk. Specific is better than general. 'Provider deprecates the model version we call in production' is better than 'model risk.'
Example: Anthropic deprecates Claude Sonnet 5 with less than 60 days notice, requiring prompt regression testing across all 47 production workflows.
Category
One of the five categories: Model, Data, Regulatory, Operational, Business.
Example: Model
Likelihood / Impact / RPN
Score each 1-5 using the matrix above. List all three. The RPN is the product.
Example: L: 3, I: 4, RPN: 12
Owner
The single person responsible for monitoring this risk and executing the mitigation. Not a team. One name.
Example: Priya Agarwal (Staff Engineer, AI Platform)
Mitigation plan
What is the pre-planned response if this risk materializes? Include the first three concrete steps. If the mitigation does not exist yet, note when it will be ready.
Example: 1. Run regression eval suite against Claude 3.7 Sonnet on 47 workflows. 2. Identify prompts with greater than 5% quality regression. 3. Patch and re-evaluate within 2 weeks of deprecation notice.
Next review date
When will the owner check whether the risk has materialized, escalated, or been resolved? For RPN above 12, set this quarterly. For RPN above 16, set it monthly.
Example: December 15, 2026
The Quarterly AI Risk Review Process
A risk registry that is not reviewed becomes a comfort blanket: it exists, therefore people feel safer, but it provides no actual protection. Run a structured quarterly review with these four steps:
Step 1: Owner updates (week before the meeting)
Each risk owner submits a one-line status update: 'No change,' 'Risk materialized partially, see notes,' or 'Risk resolved, archiving.' This takes each owner 5 minutes and keeps the meeting from being a read-out.
Step 2: RPN re-score for active risks (in meeting)
For any risk that has changed status or received new information, re-score the likelihood and impact. A risk that was L3/I4 in Q1 might be L5/I4 after a provider announces a deprecation timeline. Re-scoring takes the meeting from status theater to actual risk management.
Step 3: New risk intake (in meeting)
Bring 2-3 candidate new risks sourced from industry news, provider announcements, or post-incident reviews from the quarter. Score them live. The goal is not to add every possible risk, it is to add the ones that are credible and would catch your team by surprise.
Step 4: Archive resolved risks (after meeting)
Move risks that have been mitigated or have expired to an archive tab. A growing active registry is harder to scan and signals that no one is actually resolving anything. Keep the active list under 25 risks for a mid-sized AI product team.
Risks AI Teams Consistently Miss
Based on patterns across AI product post-mortems in 2025 and 2026, these are the risks that appear in after-action reviews but were absent from the registries that preceded them:
Silent prompt injection at scale
Teams that build AI features on top of user-provided content often test for obvious injection attempts. They do not systematically test for adversarial content designed to manipulate model behavior in subtle ways. The risk materializes in customer-facing outputs before monitoring catches it.
Provider terms of service updates
OpenAI, Anthropic, and Google update their usage policies and API terms multiple times per year. Teams that read the initial terms at contract signing do not subscribe to change notifications. An update to data retention or acceptable use policies can create a compliance obligation with 30 days notice.
Downstream model behavior in multi-agent chains
Teams evaluate individual model calls. They do not systematically evaluate what happens when the output of one model becomes the input for another. Errors compound and can produce outputs that no individual step would have generated alone.
Long-tail user behavior at scale
Testing and red-teaming cover the expected use cases. The 99th percentile user input, which arrives in production after thousands of customers have used the product, consistently triggers behaviors that were never seen in pre-launch evaluation.
Reputational risk from industry incidents
A high-profile AI failure at a competitor or a news cycle about AI hallucinations in your category can depress user trust and activation across the board, even if your product had no incident. This is not in scope for engineering risk management but belongs in the business risk category of your registry.
Manage AI Products With Rigor and Confidence
The AI PM Masterclass covers responsible AI product management, vendor strategy, and the frameworks to anticipate and prevent AI product failures. Learn from a Salesforce Sr. Director PM.
Related Articles
Before you go: get the AI PM Minute
One tactic to make you a sharper AI PM, twice a week. 60 seconds to read. Free.
No fluff. Unsubscribe anytime.