AI Risk Management in Banking: 21 Risk Domains, How to Measure Residual Exposure, and What Regulators Actually Examine

Credit risk, market risk, operational risk, liquidity risk — the traditional taxonomy was built for failure modes that are predictable and traceable back to a human decision or a system outage. AI doesn't fail that way. A credit model that perpetuates historical bias isn't an operational risk event with a root-cause ticket attached — it's a fairness failure that can run silently for months before anyone notices the pattern. A customer-service LLM that gradually becomes more willing to offer investment advice it was never authorized to give isn't a cybersecurity incident; nothing was breached, nothing was hacked, the model just drifted. Banks that force these failure modes into a traditional risk taxonomy end up with incident reports that misdiagnose the cause and therefore misdirect the fix.

21 risk domains, and why the list keeps growing

A reasonable working taxonomy spans model accuracy and reliability (hallucination, distributional shift, training data contamination), security and robustness (prompt injection, adversarial examples, model extraction, data poisoning), fairness and bias (disparate impact, proxy discrimination, feedback-loop amplification), governance and accountability (audit trail gaps, board visibility gaps), privacy and data, explainability, agentic AI (authorization-scope violation, tool misuse, multi-agent collusion), vendor and third-party AI, model lifecycle, and regulatory compliance. Banks running agentic AI face domains with no precedent in a pre-2023 risk register — multi-agent collusion wasn't a category anyone needed five years ago, and recursive prompt injection, where one compromised agent's output becomes another agent's poisoned input, is a genuinely new attack surface. Treat this list as a living taxonomy, not a static checklist — it was eleven domains two years ago and it isn't finished growing now.

Why AI risk needs a different measurement model than VaR or expected loss

Traditional risk measurement leans on statistical distributions of outcomes — VaR, expected loss, scenario analysis — because the underlying failure modes are reasonably stationary and well-understood. AI risk measurement has to start from inherent risk times control effectiveness equals residual risk, and critically, that requires testing a control's actual behavior, not just assessing its design. A control that looks sound on an architecture diagram and a control with 90 days of adversarial test evidence behind it are not the same control, even though both would get checked "yes" on a naive compliance questionnaire. The shift from design assessment to control testing is the single biggest methodology change banks need to make, and it's the one most legacy risk functions resist because it's slower and requires actual adversarial testing infrastructure, not a questionnaire.

The failure-detection gap is where most banks get caught

Traditional risk failures tend to show up in standard performance reporting — a loss ratio moves, a default rate ticks up, someone notices. AI failures, particularly behavioral drift in LLMs, can hide behind strong aggregate quality metrics for a long time; accuracy and user satisfaction scores stay healthy right up until the moment the model says something it shouldn't have, to a customer who happened to ask the right adversarial question. Catching this requires dedicated behavioral monitoring — a fixed probe set run against production on a schedule, compared against a baseline — which most banks' existing monitoring infrastructure simply doesn't do, because it was built to watch for metric drift, not behavioral drift.

Root-cause tracing needs forensic replay, not system logs

When a traditional risk event happens, the transaction records and system logs usually let you reconstruct what happened and why. An LLM's failure can't be reconstructed from a standard log, because the log typically captures the output, not the prompt, retrieved context, conversation history, and model version that produced it. Forensic replay — rebuilding the exact context state behind any single past inference — is the only way to answer a regulator's or an internal investigator's question of "why did the model say that," and building it after an incident, rather than before one, means the answer to that question is simply unavailable for every inference that happened before the logging was fixed.

Action checklist for extending risk management to AI

1. Stop forcing AI failure modes into traditional operational-risk or cyber-incident categories — build or adopt a dedicated AI risk taxonomy and route incidents to the team that actually understands the failure mode.
2. Move every Critical and High tier control from design-assessment scoring to tested, dated evidence before the next risk committee cycle.
3. Stand up behavioral consistency monitoring for every production LLM — a fixed adversarial probe set, run on a schedule, compared to a validation-time baseline.
4. Build forensic replay and inference-level logging now, not after the first incident that needs it and can't get it.
5. Calculate residual risk (inherent × (1 − control effectiveness)) for every domain in your taxonomy before ranking remediation priority — inherent risk alone will misallocate your budget.