AI Risk Management: Identify, Assess and Control AI Risks

1. EU AI Act Article 9 requires providers and deployers of high-risk AI systems to establish, implement, document, and maintain a risk management system as a continuous iterative process throughout the system lifecycle. The system must identify, analyse, and evaluate known and reasonably foreseeable risks to health, safety, or fundamental rights. High-risk obligations apply from 2 August 2026.
2. Bank of England SS1/23 is the PRA supervisory statement on model risk management for banks. It sets expectations for model identification, governance, development, validation, and ongoing monitoring across the model lifecycle. Firms subject to SS1/23 must apply its principles to all models in scope, including AI models.
3. ISO 42001:2023 Clause 6.1 requires organisations to identify AI-specific risks and opportunities, assess those risks against defined criteria, and document a treatment plan for risks above their defined tolerance. It provides the most complete structured framework for integrating AI risk into enterprise risk management.
4. UK GDPR requires a Data Protection Impact Assessment where processing is likely to result in high risk to individuals' rights and freedoms. AI systems that involve automated decision-making, process sensitive data at scale, or use technology in ways individuals would not reasonably anticipate may trigger this obligation. The DPIA should be completed before deployment.
5. FCA Consumer Duty requires firms to demonstrate that AI-assisted decisions deliver good outcomes for retail customers. Where AI contributes to poor outcomes, firms face regulatory action regardless of whether the model was internally built or vendor-supplied.

A working taxonomy is the foundation of AI risk management. The categories below cover the failure modes risk managers most commonly encounter and that are most underrepresented in existing frameworks.

Model Risk

Model risk is the risk that an AI system produces outputs that are incorrect, biased, or otherwise flawed, and that those outputs influence decisions. It covers four primary failure modes.

1. Model error: the model is poorly designed, trained on unrepresentative data, or optimised for the wrong objective
2. Overfitting: the model performs well on training data but poorly on real-world inputs
3. Model drift: the model's performance degrades over time as the real-world data distribution diverges from training data
4. Fairness failure: the model produces systematically different outcomes for different demographic groups in ways that are discriminatory or unjust

Model risk applies equally to vendor-supplied models where the organisation has limited visibility into design or training methodology.

Model risk is sometimes treated as a subset of operational risk. The assessment and control approach differs enough to warrant treating it as a distinct category, particularly given the forward-looking validation requirements and the ongoing monitoring obligation.

Data Risk

AI systems are only as good as the data they are trained and operated on. Data risk covers the full pipeline from input to the model.

1. Training data quality: biased, incomplete, or outdated training data produces unreliable models
2. Data poisoning: adversarial manipulation of training or operational data to influence model outputs, relevant to security-sensitive applications
3. Data leakage: sensitive data used in model training that can be extracted or inferred from model outputs
4. Data pipeline failures: breakdowns in data flows that cause models to operate on stale, corrupted, or incomplete inputs at inference time

Data risk connects to your data governance framework. AI-specific risks (training data quality and data poisoning in particular) often sit outside standard data quality or information security controls and require dedicated assessment.

Third-Party AI Risk

In most organisations, the majority of AI risk comes from vendor-supplied AI capabilities embedded in the tools the business already uses: CRM systems with AI-powered lead scoring, finance platforms with AI-driven forecasting, HR tools with AI-assisted screening.

1. Opacity: limited visibility into how vendor models work, how they are trained, and how they perform across demographic groups
2. Supply chain risk: if a vendor's AI system is compromised or fails, the processes that depend on it fail with it
3. Contract risk: vendor contracts that do not adequately allocate responsibility for AI failures or provide audit access and transparency rights
4. Dependency risk: over-reliance on vendor AI capabilities that could be withdrawn, changed, or degraded without adequate notice

Deployment Risk

A model that performs well in testing may perform differently in production. Deployment risk covers the gap between controlled validation and real-world operation.

1. Distribution shift: real-world inputs that differ from test conditions in ways not anticipated during validation
2. Integration failures: problems at the boundary between the AI system and the processes or systems it is embedded in
3. Misuse: users applying the AI system in ways it was not designed for, or acting on AI outputs without appropriate human judgement
4. Scope creep: a system approved for one use case being extended to another without adequate re-evaluation

Reputational Risk from AI Failures

AI failures that reach the public (biased decisions, discriminatory outputs, privacy breaches) carry reputational consequences that are often disproportionate to the underlying harm. AI failures are legible as discrete events in a way that incremental process failures rarely are. A case of algorithmic discrimination has a name, a victim, and a public record.

Reputational risk from AI is particularly acute in consumer-facing and regulated industries. Organisations operating under Consumer Duty face both regulatory exposure and significant brand damage if AI-assisted decisions are seen to harm customers.

AI risk managed in a separate silo creates a parallel process that bypasses board-level risk oversight. Integration into ERM means risk appetite, escalation, and reporting for AI follow the same pathways as other enterprise risks.

Existing ERM taxonomies, risk register templates, and assessment methodologies require adaptation before they work for AI. Integration means adapting those frameworks rather than adding AI as a new row.

Adapting the Risk Register for AI

A standard risk register entry captures risk description, likelihood, impact, controls, risk owner, and residual risk. For AI risks, several additional fields make the entry actionable.

Risk Appetite for AI

Risk appetite for AI is an area where most organisations have said something without really committing to anything. A board-level statement that "we will use AI responsibly" sets a direction but leaves every implementation question unanswered.

Operationally useful risk appetite for AI answers three questions.

1. Which AI uses are prohibited outright, regardless of the business case?
2. Which AI uses are permitted subject to specific conditions and controls?
3. What level of model risk, fairness shortfall, or deployment risk is acceptable in the operation of approved AI systems?

The third question is the hardest and the most important. It forces a conversation about quantified thresholds: how much performance degradation triggers a review, what fairness metric shortfall triggers suspension, what level of data quality failure warrants action. Most organisations have not had that conversation yet.

A risk appetite statement that says "AI risk must be managed appropriately" gives every team complete discretion in interpretation. It sets no escalation threshold, no performance floor, and no cross-unit consistency. The statement creates an appearance of governance without the substance.

Risk assessment for AI systems needs to happen at three stages: before deployment as part of the approval process, at defined intervals post-deployment, and when triggering events occur.

Pre-deployment Assessment

Before an AI system is approved for use, a risk assessment should cover the following questions.

1. What decisions does this system make or influence, and what are the consequences of a wrong decision?
2. Who is affected (employees, customers, third parties) and in what ways?
3. What data does it use, and what are the data quality and data protection risks?
4. What are the known limitations of the model, and what failure modes are most likely?
5. What controls are in place, and are they adequate given the risk tier?
6. Is there a human oversight mechanism for high-stakes decisions?

For high-risk systems, a Data Protection Impact Assessment is likely required under GDPR, and should be conducted in parallel with the AI risk assessment rather than as a separate exercise.

Ongoing Monitoring as a Risk Control

The key difference between AI risk assessment and traditional risk assessment is that AI risk is dynamic. The risk profile of a system changes over time, and point-in-time assessments capture only a moment in that evolution. Ongoing monitoring is both a governance requirement and a risk control.

Monitoring that functions as a real risk control has four characteristics.

1. Defined in terms of specific metrics with documented thresholds: for example, if fairness metric X falls below Y, the system is reviewed within Z days
2. Conducted at a frequency appropriate to how quickly the system and its data environment change
3. Routes findings to someone with the authority and context to act, with a log of the action taken
4. Has a documented escalation pathway for threshold breaches

Common monitoring failures include periodic reports that are generated but never reviewed, dashboards that flag issues with no defined response process, and review cycles set annually regardless of how dynamic the system is.

The distinction between controls that reduce actual AI risk and controls that demonstrate compliance matters for both risk outcomes and the credibility of your governance posture. A regulator able to identify the difference will scrutinise the latter accordingly.

The pattern is consistent: effective controls are specific, measurable, and tied to defined responses. Compliance theatre controls are stated in policy without operational specificity.