How to Present AI Risk to Your Board

The board deck had a section called "AI Risk." It listed twelve categories — model drift, data quality, algorithmic bias, third-party dependency, and eight others. No dollar amounts. No mitigations tied to specific risks. No ask. The board noted it and moved on. Six months later, the examiner arrived and asked to see the board's AI risk oversight documentation. That slide deck was the documentation.

I have sat in enough board prep sessions to know that this outcome is not unusual. The AI risk section of a board presentation is frequently the slide that nobody owns completely — too technical for the CFO to drive, too strategic for the CRO to write alone, too new for the board to have a strong opinion about. The result is a list of risks that satisfies nobody and authorizes nothing.

The fix is not a better-designed slide. It is a different theory of what the board presentation is supposed to do.

What board members are actually equipped to evaluate

Board members at financial institutions are not AI practitioners. They do not need to be. What most directors bring to a risk conversation is decades of experience evaluating whether management has identified the right risks, whether the mitigations are credible, and whether the ask in front of them is appropriate to the scale of the problem.

That is exactly the right frame for AI risk — and it is the frame that most AI risk presentations abandon the moment they start explaining transformer architectures or token-level validation.

A board member who spent thirty years in banking can evaluate: whether a $2.4M annual risk exposure from a model failure is proportionate to the $400K mitigation budget being requested. Whether a regulatory finding in the model risk space is likely to trigger a broader supervisory action. Whether the institution's customer base would tolerate a specific type of AI-related failure in a way that a regional competitor's would not. These are judgment calls that directors are well-equipped to make — if the presentation gives them the right inputs.

The problem is that most AI risk presentations give them the wrong inputs. Technical detail crowds out the information that would actually enable board-level judgment.

The three risk categories that translate to board language

A twelve-category AI risk taxonomy is not useful at the board level. Not because those categories are wrong, but because they do not map to the decision framework that boards use. Boards think in terms of regulatory risk, operational risk, and reputational risk. Every AI risk worth presenting fits into one of those three buckets — and framing it that way immediately connects it to the governance language the board already has.

Regulatory risk is the one that sharpens attention fastest. The question to answer is: what would an examiner finding in this area cost, and what prevents it? That is not a hypothetical question. The OCC, Federal Reserve, and FDIC have been increasingly specific about what they expect in AI governance — model inventory, validation documentation, human oversight evidence, explainability for adverse action — and the gap between what most institutions have and what examiners are looking for is quantifiable. I've written about what that examination looks like in practice at a field guide for bank executives. For a board presentation, the point is to be specific: "We currently have eleven AI models in production. Four have completed MRM validation. Three are in the validation queue. Four have not yet entered the process. An examiner finding on those four carries a materially higher remediation cost than bringing them into the queue now." That is something a board can act on.

Operational risk is where AI risk most directly connects to the bank's existing risk appetite framework — which means it is the easiest category to fold into existing board reporting if you structure it correctly. The question to answer is: what happens when the system fails, and how long does it take to recover? This requires identifying which AI systems are now operationally load-bearing and which are still advisory. A document summarization tool that summarizes credit memos is advisory — an analyst can work without it. A fraud detection model that clears transactions in real time is not advisory. If it fails or degrades, the bank needs a documented fallback. Model performance degradation is a specific operational risk that boards should understand in terms of detection lag: the time between when a model starts underperforming and when the institution knows about it. That lag is often weeks or months if monitoring is not structured correctly, and the dollar exposure compounds through that entire window.

Reputational risk is the one that is most frequently presented in vague terms — "customer trust," "brand impact" — and least frequently grounded in a specific failure scenario. The question to answer is: what does the customer-facing failure mode look like? A chatbot that gives wrong loan terms to a borrower. A credit decision model that produces a denial rate in one geography that triggers a fair lending inquiry. A document generation system that puts incorrect information into a customer disclosure. Each of these has a specific customer population, a specific harm, and a specific regulatory implication. Name it. The board should leave the presentation knowing exactly which AI-related customer failure scenario the institution is most exposed to and what the response plan is.

What does not belong in a board presentation on AI risk

Model architecture. Training data composition. Benchmark performance on academic datasets. Feature importance rankings. API call latency. These belong in the Model Risk Management validation package, not in a board deck. Putting them in a board presentation does not demonstrate rigor — it signals that the presenter is not sure what the board actually needs to decide, so they included everything.

Vendor names and product comparisons also do not belong at the board level unless the board is being asked to approve a specific vendor commitment. The decision to use GPT-4 versus a proprietary model is a management decision. If it carries risk implications material enough for the board — a single-vendor concentration risk that affects multiple critical systems, for example — present the concentration risk, not the vendor comparison.

Generic risk statements without attached mitigations belong nowhere in the document. "AI models may produce biased outputs" is not a board-level risk disclosure. "Our credit underwriting model showed a 6-point disparity in approval rates between [specific demographic groups] in Q4 testing; we have implemented [specific control] and will complete a full adverse impact analysis by [date]" is. The difference is specificity, and it is the difference between a governance document and a liability shield.

For the background that model risk management should be producing to support these presentations, the board deck should be drawing on documented validation work — not generating its own risk characterizations independently of MRM.

The one-page format that works for most boards

The format I've seen work most consistently is a single page — one slide or one printed page — structured around three columns: Risk, Current Exposure, and Mitigation/Ask. Each row is one material risk, translated into the board's language. No more than five rows. If the institution has twenty AI-related risks, management's job is to determine which five are material at the board level. The rest belong in the risk committee report.

Under Current Exposure, every risk gets a dollar figure or a regulatory consequence — not a heat-map color. "High" does not tell a director anything. "Potential remediation cost of $800K–$1.2M based on comparable examination outcomes" tells them something actionable. If you cannot estimate the exposure in those terms, the risk is not yet ready for board-level presentation — it needs more work at the management level first.

Under Mitigation/Ask, every row ends with one of three things: a statement of what is already in place, a request for budget or authorization, or an explicit decision that management needs the board to make. If a row has none of these, cut it from the presentation. The board should never leave the room having received information they could not act on.

A board presentation on AI risk that asks for nothing is not governance. It is a record that the topic was mentioned.

How to make an ask — and why most presentations don't

Presenting risk without an ask is the single most common failure mode I see in board AI risk presentations. It is also the most consequential, because it converts a governance moment into a documentation exercise.

The ask is avoided for two reasons. First, the team preparing the presentation is not sure what they need from the board — they are still figuring out the management response, so they present the risk as awareness rather than as a decision. Second, there is a belief that asking for budget or authority in a risk presentation looks like the risk team is using fear to push through a project. Both instincts are wrong.

A board that receives AI risk information without a corresponding ask cannot do its job. Directors are not operators. They cannot decide on their own how to remediate a model validation backlog. What they can do — and what they are positioned to do — is authorize a budget, direct management to report back by a specific date, approve a policy change, or accept residual risk on behalf of the institution. All of those require a specific ask.

The ask should be calibrated to what the board actually controls. "Authorize $450K to bring the MRM validation backlog into compliance ahead of the Q3 examination cycle" is an appropriate board ask. "Approve the following AI governance policy, which establishes the board's oversight responsibilities under SR 11-7" is an appropriate board ask. "Be aware that AI risk is increasing" is not an ask at all.

The institutions I have worked with that have the strongest board-level AI governance are not the ones with the most sophisticated AI programs. They are the ones where the CRO or CAI officer shows up to the board with a specific decision to make — and the board has enough information, in their language, to make it.