AI Model Risk Is Now Board Risk: What CISOs Must Report in the Next Quarterly Review
Boards have started asking a question that most security functions cannot yet answer: do we know every AI model touching customer data, and who is accountable for each one?
The question is not idle curiosity. Directors have watched the EU AI Act define a category of practice that is simply prohibited, watched sectoral regulators place accountability for automated decisions on the regulated entity rather than its vendor, and concluded that AI is now a matter of directors' duties rather than a technology choice. This is a guide to answering the question well in the next quarterly review.
Translating Technical Risk into Enterprise Risk
The fastest way to lose a board is to describe an AI risk in the vocabulary of the people who build AI systems. Directors do not act on "hallucination rate" or "distribution shift." They act on consequences expressed in the same terms as every other risk on the register.
| Technical description | What the board needs to hear |
|---|---|
| The model hallucinates | The system states things that are untrue with the same confidence as things that are true. Where a customer relies on that output, we carry the liability for the advice. |
| Training data leakage | Information we put into the system to build it can come back out to someone who did not have access to it. That includes personal data and confidential material. |
| Model drift | The system's accuracy degrades silently as the world changes. It does not fail loudly; it becomes quietly wrong while reporting the same status. |
| Bias in outputs | The system produces materially different outcomes for different groups of people. Where it informs credit, hiring or claims, that is a discrimination exposure. |
| Prompt injection | Untrusted content the system reads can redirect what the system does. Text on a webpage or inside a document can act as an instruction. |
| Model extraction | Repeated querying lets a competitor reconstruct a system we spent money and data to build. |
| Vendor sub-processing | Our supplier's AI feature may send our data onward to a party we have never assessed and cannot name. |
The right column is what belongs in the board pack. The left column belongs in the appendix, for the director with a technical background who will ask.
The AI Model Register
Everything else in this article depends on this artefact existing. A board cannot govern a portfolio it cannot see, and "we are working on an inventory" is an answer that survives exactly one quarter.
A register entry should carry, at minimum:
- Identifier and name. Stable, referenced consistently across risk, audit and incident records.
- Business owner. A named executive accountable for the outcome, not a team.
- Technical owner. A named individual accountable for the system's operation.
- Purpose. The specific decision or task, stated narrowly. "Customer service" is not a purpose; "drafting first-response replies to billing queries" is.
- Data inputs. Classes of data consumed, with sensitivity and lawful basis.
- Data outputs and their consumers. Where the output goes and what it influences.
- Risk tier. Derived from consequence, using the tiering discussed below.
- Regulatory classification. EU AI Act tier where applicable, DPDPA purpose and lawful basis, sectoral flags.
- Human oversight. Whether a human reviews output before it takes effect, and evidence that the review is real rather than nominal.
- Validation status and date. When it was last tested, against what, with what result.
- Review cadence. Driven by tier.
- Retirement date. A date, not a condition. Conditions never arrive.
The retirement date deserves emphasis. Registers without one accumulate entries indefinitely, and an unused model with live credentials and production data access is a pure liability.
Tiering by Consequence
Risk tier should be a function of what happens when the system is wrong, not of how sophisticated it is.
| Tier | Test | Cadence | Board visibility |
|---|---|---|---|
| Tier 1 | Output affects a person's money, health, employment, or legal rights | Quarterly validation, continuous monitoring | Named individually in the board pack |
| Tier 2 | Processes personal or confidential data; output advises a human decision | Semi-annual validation | Reported in aggregate, escalated by exception |
| Tier 3 | Internal productivity on non-sensitive data | Annual attestation | Count only |
This tiering has a useful property: it aligns closely with the EU AI Act's Annex III categories and with the DPDPA's concern for processing that risks Data Principal rights, so one classification exercise serves three purposes.
The Five Numbers Boards Actually Want
Board reporting fails when it presents everything the security team measures. Five metrics carry the discussion.
1. Unapproved models in use. The count of AI systems discovered in the estate that never passed governance, and the trend across quarters. This is the single most diagnostic number, because it measures whether governance is keeping pace with adoption. A rising count means the policy is being routed around.
2. Percentage of Tier 1 models with a completed assessment. Coverage of the highest-consequence population. Report the percentage and the absolute count of gaps - percentages hide small numbers, and "94 percent" sounds fine until it means three critical systems are unassessed.
3. AI-related incidents. Count by category, with mean time to detect. Include near misses. A zero here is not automatically good news; it may mean detection does not exist.
4. Regulatory exposure in currency. The applicable penalty ceiling multiplied by an assessed likelihood, plus contract value carrying warranties that current usage may breach. Present the working, not just the total, because the board will test the assumptions.
5. Third-party AI dependencies. Count of vendors with AI features processing your data, and how many have been assessed. This number surprises boards more than any other, because it is usually an order of magnitude larger than expected.
Integrating with the Existing ERM Framework
The strongest argument you can make to a board is that AI risk is not a new framework but a new entry in the framework they already approved.
Under ISO 31000, AI risk flows through the same establish-context, identify, analyse, evaluate, treat cycle. The adaptation is in identification: AI risks are not discoverable through asset scanning alone, so identification must include the discovery techniques appropriate to shadow adoption.
Under COSO ERM, AI maps cleanly onto the five components. Governance and culture covers the accountability model and who may approve deployment. Strategy and objective-setting covers risk appetite for automated decisions. Performance covers the register and tiering. Review and revision covers validation cadence. Information, communication and reporting covers exactly the metrics above.
Two supporting standards make this concrete without inventing anything: NIST AI RMF 1.0, whose GOVERN function articulates board and executive accountability, and ISO/IEC 42001:2023, which specifies a certifiable AI management system designed to integrate with an existing ISO 27001 programme.
Framing it this way converts the board conversation from "we need a new AI risk framework" - which invites a budget debate - to "we are extending the risk framework you already approved to cover a new asset class," which invites approval.
A One-Page AI Risk Heatmap
The board pack needs one page. Here is what belongs on it.
The grid. Likelihood on one axis, impact on the other, standard five-by-five to match the enterprise risk register's existing scale. Do not invent a new scale for AI; comparability with other risks is the entire point.
The plot. One marker per Tier 1 model, plus aggregate markers for Tier 2 and Tier 3 populations. Colour by whether the assessment is current. Systems plotted in the high-impact quadrant with a stale assessment are the conversation.
The movement. Arrows showing position change since the last quarter. Boards respond to direction more strongly than to position, and a risk moving the right way earns you credibility for the ones that are not.
The margin. Three lines: the five numbers, the top three exposures with an owner and a date against each, and one decision you are asking the board to make. Every board page should ask for exactly one decision. Pages that ask for none get read as information and forgotten; pages that ask for several get deferred.
What to leave off. Model architectures, vendor names below Tier 1, technical metrics, and anything requiring a glossary.
Conclusion
The shift underway is that AI model risk has moved from a technical concern owned by engineering to a governance concern owned by the board, and the mechanism of that shift is regulatory. Once a regime places accountability for an automated decision on the entity rather than on its technology supplier, the question of who approved the deployment becomes a directors' question.
CISOs who arrive at the next quarterly review with a register, a tiering, five numbers and one decision will find the conversation straightforward. Those who arrive with a description of how large language models work will be asked to come back next quarter.
Actionable recommendations:
- Build the register before the meeting, even if it is incomplete. A register covering your Tier 1 systems with honest gaps marked is far stronger than a promise of a complete one later.
- Tier by consequence, and reuse the tiering. The same classification serves EU AI Act scoping, DPDPA risk assessment and internal review cadence. Do it once.
- Report the unapproved-model count every quarter. It is the metric that shows whether governance is winning or being routed around, and the trend matters more than the absolute number.
- Extend the ERM framework rather than proposing a new one. ISO 31000 and COSO already accommodate this. NIST AI RMF and ISO/IEC 42001 supply the AI-specific detail without a parallel structure.
- Ask for exactly one decision per board page. Zero decisions gets filed; several gets deferred.
Auto-generate board-ready AI risk reports. A live model register, consequence-based tiering, and a heatmap that drills down to individual model findings and their evidence - without a quarterly scramble through spreadsheets. See how Dedups.ai makes AI risk reportable.