Hook

Your organization's AI chatbot starts hallucinating security escalation procedures during incident response. Your demand forecasting model begins predicting negative demand after a data format change upstream. Your anomaly detection system flags everything as suspicious because the production environment differs from training. None of these failures trigger your existing IT risk frameworks. They fall into gaps between operational, data, and model risk. By the time you've categorized the problem, the system has made decisions affecting your business. This gap between how you've managed IT risk for twenty years and how AI systems actually fail is the defining challenge of AI risk management leadership.

Purpose

Existing IT risk frameworks were built for systems with predictable failure modes and clear root causes. A database either works or it doesn't. A firewall either blocks or allows traffic. AI systems fail differently. They degrade slowly. They fail asymmetrically, performing well on common inputs and failing catastrophically on edge cases. They fail due to data your team doesn't control. They fail due to assumptions in training data that shift over time. You need risk assessment frameworks that capture these unique failure patterns while integrating with the governance structures and risk appetite your board already understands.

This lesson gives you decision frameworks for AI risk that sit on top of your existing IT risk infrastructure, mapping new risk categories to your governance language, and practical tools for building AI risk registers that survive real-world implementation.

Why This Matters

For Your Leadership: Board-level risk discussions require the same vocabulary whether you're talking about network infrastructure or AI systems. A risk framework that only speaks in AI jargon ("model drift," "training data contamination") gets abstract fast. A framework that maps to financial impact, compliance exposure, and operational continuity gets resources allocated.

For Your Team: Your incident responders, architects, and ops teams need clear thresholds for when an AI system is exhibiting concerning behavior, not after it's caused an incident, but during normal operation. Early detection saves cost and reputation. Late detection becomes a compliance violation.

For Your Vendors and Partners: You'll be asked to evaluate third-party AI services, buy SaaS platforms with embedded AI, or partner with data science teams. A shared risk taxonomy with your vendors reduces the chance you're accepting risks they haven't disclosed.

For Compliance and Audit: Regulators increasingly want to see how you've assessed AI risk, not just how you've bought the technology. A documented framework shows intentional governance, not reactive firefighting.

Core Concepts

Key Insight 1: AI Risk ≠ IT Risk (But It Sits On Top Of It)

Your current risk framework covers IT risk: availability, security, performance, capacity, disaster recovery. These still matter for AI systems. But AI introduces three additional risk domains that your infrastructure team didn't need to track:

Model Risk, the statistical or algorithmic failures of the AI model itself. The model makes inaccurate predictions, learns from biased training data, or becomes unreliable when the production environment diverges from training conditions.

Data Risk, failures in the data that feeds or comes from the model. Training data is poisoned, production data drifts, data dependencies break, or sensitive data handled by the system is exposed.

Decision Risk, the business impact when the AI system makes a decision based on inaccurate or biased outputs. Even if the model performs as designed, the decision it enables may violate compliance requirements, harm customers, or create liability.

These three layers sit on top of your operational IT risks. You can have a perfectly available, secure, high-performance AI system that still fails catastrophically due to model degradation or bias. Your risk register needs to track all layers.

Key Insight 2: AI-Specific Risk Categories

Your organization probably categorizes IT risk as: Availability, Security, Performance, Capacity, Compliance. These categories still apply to AI, but they need AI-specific instantiations:

Model Accuracy Risk: The model's predictive accuracy degrades below acceptable thresholds. This happens through data drift (the real-world distribution of inputs changes), concept drift (the relationship between inputs and outputs changes), or label noise (the training labels were wrong to begin with). Unlike traditional system degradation, you may not notice this until the business impact surfaces.

Bias and Fairness Risk: The model systematically disadvantages certain groups due to training data reflecting historical discrimination, insufficient representation of minorities in training data, or feature selection that proxies for protected characteristics. This is both an ethical and a compliance risk, discrimination lawsuits, regulatory fines, and reputational damage flow from biased AI decisions.

Data Poisoning and Integrity Risk: An attacker or compromised upstream system deliberately corrupts training data to degrade model performance or inject backdoors that cause specific misbehaviors under certain inputs. A tampered data pipeline can poison a model months before detection.

Model Dependency and Single Point of Failure Risk: Your critical system depends on a proprietary third-party model with no fallback. If the vendor changes the API, deprecates the model, or experiences an outage, your system fails. You have no visibility into when or how the model will change.

Adversarial Input Risk: An attacker crafts inputs designed to fool the model, slightly modified images that change classification, prompt injections that cause language models to ignore safety constraints, or queries designed to extract training data. Unlike traditional security breaches, adversarial attacks may not trigger your intrusion detection systems.

Regulatory and Audit Risk: Your AI system violates existing regulations (discrimination laws, GDPR, industry-specific rules), or new regulations you're unprepared for change what was previously compliant. The EU AI Act, state privacy laws, and sector-specific rules are still being written, your risk register needs to track emerging regulatory exposure.

Explainability and Auditability Risk: You cannot explain why the AI system made a specific decision. Regulators ask how the system approved a loan denial. You don't have a coherent answer. Your audit trail is insufficient because you didn't design the system to be auditable from the start.

Dependency Chain Risk: Your AI system depends on upstream AI systems, data feeds you don't control, or pre-trained models from third parties. A failure or change upstream cascades to your system with no warning.

Key Insight 3: Risk Scoring for AI Requires New Dimensions

Your traditional IT risk scoring follows this formula:

Risk = Likelihood × Impact

You assign a likelihood (how often does this happen?) and an impact (how bad is it?), multiply them, and prioritize. This works for many IT risks: a server failure is unlikely but high-impact; a misconfigured access control is more likely and medium-impact.

AI risk scoring needs additional dimensions:

Likelihood breaks down differently. A model accuracy degradation isn't a discrete event. It's a gradual process. You need to score not just "will this happen" but "how quickly will we detect it, and how long will it persist before action?"

Impact needs sub-dimensions:

• Business Impact: Revenue loss, operational disruption, missed SLAs
• Compliance Impact: Regulatory fines, audit failures, license revocation
• Reputational Impact: Customer trust, media coverage, brand damage
• Decision Impact: How many decisions does the system make per day, and what's the blast radius of a wrong decision?

Velocity becomes critical. A security breach in your traditional IT system is (hopefully) detected and contained. An AI model degradation that persists undetected for six months and affects millions of decisions has exponentially higher impact than one caught within hours.

Reversibility matters. If you turn off an AI system, can you fall back to a previous process? Or does the system make decisions that can't be unwound, approvals that become part of customer history, predictions that shape supply chain decisions?

Your risk scoring for AI systems should look like:

AI Risk Score = (Likelihood × Detection Lag × Impact × Decision Velocity × Reversibility Factor)

This captures that a slow-burning model degradation that you don't detect is riskier than an acute failure you catch immediately.

Key Insight 4: AI Risk Integration with Existing Frameworks

You don't need to replace your NIST Cybersecurity Framework, ISO 31000, or FAIR (Factor Analysis of Information Risk) methodology. You need to layer AI-specific risk onto them.

NIST approach: NIST categorizes risk into Identify, Protect, Detect, Respond, Recover. For AI:

• Identify: What data does the model use? What are the model's assumptions? Where are single points of failure?
• Protect: What controls prevent data poisoning? What controls prevent unauthorized model changes?
• Detect: How do you detect model degradation? How do you catch adversarial inputs?
• Respond: Do you have a playbook for taking down an AI system without taking down dependent processes?
• Recover: Can you revert to a previous model version? Can you restore from training data backups?

ISO 31000 approach: This framework emphasizes risk context, assessment, treatment, and monitoring. For AI:

• Context: What's the business process the AI supports? What's the failure mode that would create the most damage?
• Assessment: Score the AI-specific risks listed above
• Treatment: Accept the risk with monitoring, mitigate through controls, avoid by not using AI, transfer through insurance or vendor indemnification
• Monitoring: What metrics indicate the model is degrading? When do you trigger an alert?

FAIR approach: FAIR quantifies information risk as (Threat Agent Capability × Threat Agent Motivation × Control Gaps) × Probability × Loss Magnitude. For AI:

• Threat Agent: Who threatens the model? External attackers, malicious insiders, negligent data engineers?
• Capability: What's required to poison the model or extract training data?
• Control Gaps: What's your current control maturity for each AI-specific risk?
• Probability: How likely is the threat given your control gaps?
• Loss Magnitude: What's the financial impact of model failure?

Pick the framework your organization already uses. Don't introduce a new one. Extend it with AI-specific dimensions.

Key Insight 5: The AI Risk Register Template

Your IT risk register probably has columns: Risk ID, Category, Description, Owner, Likelihood, Impact, Score, Controls, Status. Add these columns for AI:

• Risk Type: Model Risk / Data Risk / Decision Risk / Dependency Risk
  - Specific Category: (Accuracy Degradation, Bias, Poisoning, Adversarial, Regulatory, Explainability, Dependency Chain)
  - Detection Method: How will you know this risk has materialized? (Automated monitoring metric, manual review, customer report, audit finding)
  - Detection Lag: How long from risk occurrence to detection? (Minutes, hours, days, weeks)
  - Reversibility: Can you immediately stop the harm? (Fully reversible, partially reversible, irreversible)
  - Velocity: How many decisions per day does this model make?
  - Control Owner: Who owns the control that mitigates this risk? (Data team, ML team, IT ops, security)
  - Monitoring SLA: How often is this risk assessed? (Continuous, daily, weekly, monthly)

Example row:

| Risk ID | Risk Type | Specific Category | Description | Detection Method | Detection Lag | Velocity | Score | Control Owner | Status |

|---------|-----------|------|-------------|------------------|---------------|----------|-------|---------------|--------|

| AR-001 | Model Risk | Accuracy Degradation | Demand forecasting model accuracy falls below 85% threshold due to data drift after supplier change | Monthly accuracy comparison against holdout test set | 30 days | 1000 predictions/day | High (90 days × 1000 pred/day) | Data Science + Demand Planning | Active Monitoring |

| DR-002 | Data Risk | Poisoning | Training data contaminated by compromised upstream ETL job | Daily data validation checks comparing statistical profiles against historical baselines | 24 hours | N/A | Medium | Data Engineering | Control in Place |

| DER-003 | Decision Risk | Regulatory | AI hiring recommendation system violates EEOC disparate impact guidelines | Quarterly bias audit on protected characteristics + legal review | 90 days | 50 hires/month | Critical | HR Legal + Data Science | Needs Remediation |

Key Insight 6: Reporting AI Risk to Your Risk Committee and Board

Your audit, risk, and compliance committee (often called the "ARCO") wants to see:

• 
  AI Risk Inventory: How many AI systems is your organization running in production? What's the risk profile of each?
• 
  Risk Concentration: Are you overly dependent on one vendor's AI? Do you have multiple models making similar decisions with correlated failures?
• 
  Control Maturity: For each risk category (accuracy, bias, poisoning, etc.), what's your current maturity in detecting and responding? Are you at "ad hoc," "repeatable," "defined," "managed," or "optimized"?
• 
  Escalations: What risks did you identify this quarter? Which ones breached acceptable thresholds and required mitigation?
• 
  Compliance Posture: Where do you stand against emerging regulations? What investments are needed to become compliant with the EU AI Act, state AI laws, or sector-specific rules?
• 
  Third-Party Exposure: What's your exposure through vendor AI systems? Do you have contractual protections?

Frame your report around business risk, not technical risk. "Our demand forecasting model is showing signs of degradation based on upstream data format changes" is too technical. "Our demand forecasting model has not been retrained in eight months despite a known data distribution shift upstream; current monitoring indicates prediction accuracy may have drifted 7-15% below acceptable thresholds, affecting supply chain planning. We estimate a 90-day lag between actual model degradation and detection. We've allocated resources to implement weekly retraining and daily accuracy monitoring, expected to reduce detection lag to 24 hours and restore control by Q3." That's a governance report.

Practical Use Cases

Use Case 1: Mapping AI Risk in a Hybrid Traditional + AI Operations Center

The Scenario: Your NOC (network operations center) traditionally monitors servers, network devices, and applications. You've added an AI-powered anomaly detection system that flags unusual patterns in system logs and network traffic. The team doesn't know how to risk-assess this new layer.

The Assessment Framework:

First, map what the AI system does:

• Inputs: System logs, network flow data, performance metrics from 2,000+ servers
• Processing: Unsupervised learning model (isolation forest) trained on 6 months of baseline data
• Output: Anomaly severity scores (1-100) that trigger alert routing and auto-remediation workflows

Now identify AI-specific risks:

• Model Accuracy Risk: The baseline data came from summer 2024. Your environment has since added 500 new servers, changed monitoring agents, and implemented a new backup strategy. The model's definition of "normal" may be outdated. Detection method: Monthly comparison of model-flagged anomalies against actual incidents (precision and recall). Detection lag: 30 days.
• Adversarial Input Risk: An attacker could craft network traffic patterns designed to be flagged as anomalies, causing the system to trigger auto-remediation that disrupts legitimate services. Detection method: Manual review of top 20 flagged anomalies weekly. Detection lag: 7 days.
• Single Point of Failure Risk: If the anomaly detection model fails or produces contradictory scores, the NOC has no clear escalation. Detection method: Model health checks (training data staleness, prediction distribution shifts). Detection lag: continuous.
• Explainability Risk: When the model flags a critical issue, the NOC operator needs to understand why to decide whether to act. "Feature X exceeded threshold Y" helps. "The model thinks this is weird" doesn't. Detection method: Audit trail of top contributing features for each alert. Detection lag: immediate.

Risk Score Calculation:

• Accuracy Risk: Likelihood 4/5 (no recent retraining), Impact 4/5 (false positives distract from real incidents), Detection Lag 4/5 (30 days), Score = 64/125 (High)
• Adversarial Risk: Likelihood 2/5 (requires sophisticated attacker), Impact 5/5 (auto-remediation disrupts service), Detection Lag 3/5 (7 days), Score = 30/125 (Medium)
• Single Point of Failure: Likelihood 3/5 (model is a critical dependency), Impact 5/5 (NOC is blind), Detection Lag 1/5 (continuous monitoring), Score = 45/125 (Medium-High)
• Explainability: Likelihood 5/5 (happens on every major alert), Impact 2/5 (NOC will investigate anyway), Detection Lag 0/5 (immediate), Score = 50/125 (Medium)

Mitigation Actions:

1. (For Accuracy Risk) Implement weekly model retraining on recent data and monthly accuracy validation against ground truth incidents
2. (For Adversarial Risk) Implement a secondary rule-based check: if auto-remediation is about to take action, require manual approval if the triggering anomaly score is within 10 points of the threshold
3. (For Single Point of Failure) Add a fallback: if model predictions are stale or contradictory, revert to a rule-based anomaly detection system
4. (For Explainability) Ensure every alert includes the top 3 feature contributions to the anomaly score; NOC team reviews these weekly

Use Case 2: Assessing Third-Party AI Risk in a Vendor Forecasting Platform

The Scenario: Your supply chain team is evaluating a SaaS platform that uses AI for demand forecasting. It's a black-box system. You can input historical sales data and get forecasts, but you can't see the model or audit its training data.

The Risk Assessment:

Questions to ask the vendor:

1. Data Risk: What data does the model see? Where is it stored? How long is it retained? Can it be used to train models for other customers? (Many vendors use customer data for continuous improvement and model performance benchmarking. This is a data exposure risk.)
2. Model Risk: How often is the model retrained? What's the training data window? How does it handle structural breaks in the data (supply chain disruptions, demand shocks)? When was the model last updated?
3. Dependency Risk: What happens if the vendor shuts down? Can you export your data and historical forecasts? Is there an escrow arrangement for model code or training data?
4. Regulatory Risk: Does the vendor warrant that the model complies with emerging AI regulations? Is the vendor liable if the model violates anti-discrimination laws?

Translate their answers into risk scores:

• Data Exposure Risk: If the vendor uses your data for model improvement and it could be reconstructed or reverse-engineered from the model, you have a data exposure risk. Likelihood 4/5 (common practice), Impact 3/5 (proprietary sales data leakage), Detection Lag 5/5 (you may never know), Score = 60/125 (High). Mitigation: require contractual prohibition on data use, anonymization of your data in model training.
• Model Degradation Risk: If the vendor stops investing in model improvements, your forecasts may become stale. Likelihood 2/5 (unlikely for active SaaS), Impact 4/5 (forecast errors compound), Detection Lag 3/5 (degradation is gradual), Score = 24/125 (Low-Medium). Mitigation: establish SLA for model accuracy; include escalation clause if accuracy drops below threshold.
• Vendor Lock-In Risk: You've been using this system for 18 months, your team is trained on it, your supply chain planning is built around its output format. The vendor doubles their pricing or discontinues the product. Likelihood 3/5 (happens to SaaS products), Impact 5/5 (you're locked in), Detection Lag 0/5 (you'll know immediately), Score = 45/125 (Medium). Mitigation: require data portability (your historical forecasts, training data), establish 12-month notice period for discontinuation, require export capability in API.

Use Case 3: Building a Risk Assessment Process for New AI Use Cases

The Scenario: Your IT leadership is approving three new AI pilots: an IT ticket auto-categorization system, a database query optimizer, and an AIOps platform for capacity planning. You need a repeatable process to assess and approve each one.

The Assessment Process:

• Pre-Approval Checklist (before pilot funding):
  - What data does the model use? Is it PII, confidential, or production data?
  - What decisions does the model make or support? What's the blast radius of a wrong decision?
  - Who owns the model? Is it a third-party vendor, internal data science team, or open-source project?
  - What's the fallback if the model fails? Can you continue operations without it?
  - What's the target accuracy? How will you measure it in production?
  -
  What compliance or regulatory requirements apply?
• 
  Risk Assessment Template (during pilot, before production):
• Complete the AI Risk Register for each risk category
  - Score each risk using the AI Risk Formula (Likelihood × Detection Lag × Impact × Velocity × Reversibility)
  - Identify control gaps: what monitoring, audit, or safeguards are missing?
  -
  Establish acceptance criteria: at what score does a risk become unacceptable?
• 
  Production Readiness Gate (before moving to production):
• All High-risk items must have a mitigation in place
  - All models must have automated monitoring of key metrics
  - All models must be traceable: you can explain major decisions or flag anomalies
  - All models must have a documented fallback or kill-switch
  - Compliance review: does this model violate any regulations? What audit trail is required?
  -
  Vendor review: if third-party, are contractual protections sufficient?
• 
  Ongoing Monitoring (monthly governance):
• Review risk register for changes in likelihood or impact
  - Audit control effectiveness: are our monitoring and safeguards working?
  - Track model performance against acceptance criteria
  - Report escalations to risk committee

Examples

Example 1: Demand Forecasting Model Risk Register

A manufacturing company's demand forecasting model is critical to supply chain planning. Here's how they assessed it:

Risk Category
Specific Risk
Description
Likelihood
Impact
Detection Lag
Velocity
Score
Control
Owner

Model Risk
Accuracy Degradation
Supplier data format change causes upstream data to be parsed incorrectly; model is unaware of structural break
4/5
4/5 (supply chain planning error)
30 days (monthly validation)
1000+ forecasts/day
76/125 High
Weekly data quality checks; monthly holdout test validation
Data Engineering

Data Risk
Data Poisoning
Upstream ETL job is compromised; bad data contaminates model training pipeline
2/5
5/5 (model completely unreliable)
14 days (bi-weekly data audits)
N/A
28/125 Low-Med
Daily data validation; statistical anomaly detection on input distributions; data lineage tracking
Data Engineering

Decision Risk
Bias
Historical demand data reflects unequal market access by region; model perpetuates regional bias in forecast allocation
3/5
3/5 (some regions get underallocated inventory)
90 days (quarterly bias audit)
1000+ forecasts/day
67/125 Med-High
Bias audit on geographic and demographic dimensions; manual override for flagged regions
Data Science + Supply Chain

Operational Risk
Single Point of Failure
Model is dependency for monthly S&OP (sales and operations planning) process; if model fails, no forecast for 30 days
3/5
5/5 (supply disruption)
Immediate (if model is down)
1 forecast/month
45/125 Med
Maintain previous quarter's forecast as fallback; weekly model health checks; automated failover to rules-based forecasting
ML Ops

Dependency Risk
Vendor Pricing Change
Using third-party demand sensing API; vendor doubles price or discontinues service
2/5
4/5 (forced to migrate or abandon feature)
0 days (immediate notification)
External dependency
32/125 Low
Require 12-month notice period in contract; maintain ability to export training data and retrain internally
Procurement + IT Strategy

Risk acceptance threshold: Medium-High (Score > 60) requires mitigation. All Medium-High and High risks have controls in place. The model is approved for production with these controls active and monitored monthly.

Example 2: Anomaly Detection in IT Incident Response, Risk Reporting to Board

Risk Committee Report: Q2 AI Risk Summary

AI System
Risk Category
Key Risk
Current Score
Control Status
Trend
Board Action

Anomaly Detection (NOC)
Model Accuracy
Baseline degradation from 8-month-old training data
High (68/125)
Mitigating: weekly retraining
Improving
No escalation needed

Anomaly Detection (NOC)
Explainability
NOC operators cannot explain model decisions for audit
Medium (50/125)
In place: feature contribution reporting
Stable
Continue monitoring

Demand Forecasting
Data Poisoning
Upstream data format changes undetected
High (76/125)
Mitigating: weekly data validation + monthly accuracy audit
Stable
Escalation: Data Eng team requested 1 FTE for data observability

Demand Forecasting
Bias
Regional forecast bias in demand sensing
Medium-High (67/125)
In place: monthly bias audit + manual override
Improving
Supply Chain to review flagged regions quarterly

AIOps Capacity Planner
Regulatory
Compliance with emerging EU AI Act
Medium (55/125)
In progress: documentation and audit trail implementation
At Risk
Legal and IT Strategy to establish compliance roadmap by Q3

Summary: 5 AI systems in production, 12 identified AI-specific risks, 6 High/Medium-High requiring active mitigation, 0 critical escalations. All systems have documented controls. Recommendation: approve continued operation with quarterly risk reviews.

Example 3: Vendor Risk Assessment, SaaS Forecasting Platform

Your vendor evaluation template asks:

Risk Dimension
Question
Vendor Response
Risk Score
Mitigation

Data Exposure
Where is customer data stored? How long retained? Used for model training?
"AWS US regions; retained 36 months for continuous model improvement; anonymized training data used for all customers"
Med-High (70/125): Shared training reduces your competitive advantage; difficult to validate anonymization
Contractual clause: exclusive model for your organization, no shared training data; right to audit data anonymization

Model Degradation
How often retrained? SLA for model accuracy?
"Retrained quarterly on customer's data only; no published SLA; typical accuracy 90%"
High (75/125): Quarterly may be insufficient; no accountability for accuracy
SLA: Model accuracy >= 88% measured monthly; automatic retraining if accuracy drops below; escalation if vendor cannot meet

Dependency
Discontinuation risk? Data export?
"30-day notice of discontinuation; API export available; no escrow for model code"
Medium (55/125): 30-day notice is tight; model code escrow missing
Negotiate: 12-month notice; model code escrow with third party; right to retrain model using your historical data

Regulatory
Compliance warranty? Liability for AI violations?
"No specific AI compliance warranty; vendor indemnifies for copyright/IP violations only"
High (80/125): If model discriminates, vendor has no liability; your organization bears risk
Negotiate: explicit warrant that model complies with anti-discrimination laws; vendor shares liability for violations

Risk Acceptance Decision: Approve pilot on condition that vendor agrees to Medium-term contracts (not annual) until data exposure and regulatory warranty issues are resolved. Pilot is limited to forecast recommendation (not automated decision-making) so impact of model failure is reduced.

Anti-Patterns

Anti-Pattern 1: "We'll Assess AI Risk When We Have a Failure"

Why This Fails: By the time an AI failure surfaces, the damage is done. A demand forecasting model that's been degrading silently for three months has affected supply chain decisions affecting millions of dollars. A bias in a hiring recommendation system that went undetected for a year is now a lawsuit.

What to Do Instead: Establish risk assessment as a gate for production deployment. Before any AI system goes live, complete an AI Risk Register. Before any vendor tool is approved, complete a vendor risk assessment. Risk assessment is not a compliance checkbox. It's engineering practice that prevents costly failures.

Anti-Pattern 2: "Our Existing Risk Framework Covers AI Risk"

Why This Fails: Your IT risk framework covers infrastructure risk: availability, security, performance. It doesn't measure model accuracy degradation or data drift or bias. These are orthogonal to whether your servers are up. An AI system can be available and secure and still fail catastrophically due to model degradation. You're missing an entire dimension of risk.

What to Do Instead: Layer AI-specific risk categories on top of your existing framework. Create a separate risk register or section for Model Risk, Data Risk, and Decision Risk. Map these to your governance structures (risk committee, audit reviews, SLAs) so they get the same oversight as operational risks.

Anti-Pattern 3: "AI Risk Assessment Is the Data Science Team's Job"

Why This Fails: Data scientists are incentivized to deploy models. They're not incentivized to highlight risks that might delay deployment. Worse, they may not see operational risks. They don't know that your incident response process depends on explainability, or that your NOC needs to trust the model's judgment. Risk assessment requires collaboration between data science, IT operations, compliance, and business stakeholders.

What to Do Instead: Make risk assessment a collaborative process. Include representatives from each team that owns a risk category. The data science team owns Model Risk. IT ops owns Operational Risk. Compliance owns Regulatory Risk. Each team contributes their perspective, and disputes are escalated to leadership for trade-off decisions.

Anti-Pattern 4: "We Have a Risk Register, So We're Compliant"

Why This Fails: A risk register that sits in a spreadsheet and is never reviewed is not governance. It's a checkbox. Real governance requires: active monitoring against accepted risk thresholds, regular (monthly or quarterly) reviews of emerging risks, escalation protocols when risks breach thresholds, and executive visibility of mitigation progress.

What to Do Instead: Establish a regular review cadence. Monthly: data science and IT ops teams review their risk registers and audit control effectiveness. Quarterly: present AI risk summary to your risk committee or ARCO. Executive decision: are current risks within acceptable tolerance? Do we need more investment in controls? Are there emerging risks we're blind to?

Anti-Pattern 5: "Risk Assessment Slows Us Down"

Why This Fails: A thorough risk assessment on a new AI system might take 2-3 weeks. That feels slow compared to the 1-week deployment cycle of some agile teams. But the cost of an undetected failure, regulatory fines, customer harm, reputational damage, dwarfs the delay. Risk assessment is not a friction cost; it's an investment that prevents catastrophic costs.

What to Do Instead: Build risk assessment into your deployment process from day one. Don't wait until production readiness to assess risk. Iteratively assess risk as the model is developed: what data are you using (data risk), how will you measure accuracy (model risk), what's the decision blast radius (decision risk). This distributes the effort and means production readiness assessment is a review, not a discovery process.

Human Judgment Checkpoints

Checkpoint 1: Risk Acceptance Decisions Are Leadership Decisions

Your framework gives you a risk score. That score is an input to a decision, not the decision itself. A High-risk model might be acceptable if the mitigation controls are in place and the business value justifies the remaining risk. A Low-risk model might be unacceptable if it duplicates an existing system or if the business value is marginal.

Who decides? Your CIO or Chief Risk Officer, in consultation with the business owner and technology team. The framework gives them information. Leadership applies judgment.

Checkpoint 2: Risk Appetite Is Not Risk Tolerance

Your organization has a risk appetite: how much risk are you willing to accept to achieve strategic objectives? You might accept High risk in a competitive advantage area (a proprietary demand forecasting model that other competitors don't have) but not in a compliance area (bias in hiring systems).

Your framework should map risks to your stated risk appetite. If you're risk-averse in hiring decisions, a Medium-High bias risk in a hiring system is unacceptable. If you're aggressive in supply chain optimization, a Medium-High accuracy degradation risk in forecasting might be acceptable if you have strong mitigation controls.

Checkpoint 3: Monitoring and Detection Lag Are Technical Choices

A model accuracy degradation risk is only acceptable if you can detect it fast enough to act. If it takes 90 days to notice that a model's accuracy has drifted, the risk is unacceptable no matter how strong your other controls are. Detection lag should be a design decision, not an afterthought.

When assessing AI risk, ask: can we detect this in hours, days, weeks? If the answer is "weeks or months," the risk is elevated and either needs stronger mitigation or the system needs a redesign to enable faster detection.

Checkpoint 4: Control Ownership Must Be Clear and Accountable

Every risk in your register has a control. Every control has an owner. That owner is accountable for the control working. Ambiguous ownership (is this the data science team's job or IT ops'?) means controls don't get maintained.

Make sure control ownership maps to actual organizational structure and incentives. If data quality controls are owned by a data engineering team that's measured on "data available" rather than "data quality," the controls won't be prioritized.

Key Takeaways

• 
  Establish AI-specific risk categories (Model Risk, Data Risk, Decision Risk) on top of your existing IT risk framework. Your traditional framework covers availability and security; AI risk covers accuracy, bias, and degradation.
• 
  Score AI risk using an extended formula: (Likelihood × Detection Lag × Impact × Decision Velocity × Reversibility). Detection lag and velocity are unique to AI and often dominate the score.
• 
  Build a collaborative risk assessment process that includes data science, IT ops, compliance, and business owners. Risk assessment is not siloed to one team.
• 
  Automate detection of key risks: model degradation, data drift, adversarial inputs. Manual review and quarterly audits are too slow. You need monitoring that alerts within hours of a problem.
• 
  Report AI risk to your board and risk committee in their language: financial impact, compliance exposure, business continuity risk. Not in ML jargon.
• 
  Establish clear risk acceptance thresholds before deploying systems. Decide as an organization: which risks are acceptable and why? Use your framework to measure whether deployed systems are within tolerance.
• 
  Make risk owners accountable: every risk has an owner, every control has an owner, and ownership maps to organizational incentives and structure.