Most AI governance reports tell the board how much governance work was done, not whether the organisation's AI risk is inside the appetite the board approved. Directors need a short set of indicators that move when exposure changes: high-risk systems running outside tolerance, sensitive data flowing to unapproved AI services, agents acting without approval gates, and incidents that could trigger a regulator's clock. This guide sets out ten board-level key risk indicators (KRIs) and four supporting key performance indicators (KPIs) for AI, with formulas, tolerance bands, the appetite statement each one tests and the escalation each one should trigger. It is written for AI governance leads, CISOs, chief risk officers and company secretaries preparing the board or risk committee pack. The operational health check that keeps the AI management system running is a separate page, the AI Governance Programme Health Check; this guide reports outcomes upward and shares at most two measures with it.
Key takeaways
- Start from the appetite statement, not the data you have. Each KRI should test one sentence of the board's AI risk appetite; a measure that tests nothing the board decided belongs in the operational pack.
- Report exposure, not effort. "Training sessions delivered" is a KPI for management; "high-risk AI systems operating with residual risk above tolerance" is a KRI for the board.
- Agents change the picture. AI that can act, through tokens and tool access, needs its own KRI on privileged actions without an approval gate, because the loss path is an action, not an answer.
- Regulatory clocks belong on the board page. Reportable AI incidents and systems in scope of the EU AI Act with open gaps are risk indicators directors can be asked about.
- Ten KRIs on one page, with trend. Show current value, tolerance band, direction over four quarters and the decision you are asking for; the detail stays in the appendix.
KPIs versus KRIs for AI
A KPI shows whether a governance activity performs as designed; a KRI shows whether exposure to a specific risk is approaching or past the tolerance the board agreed. The distinction follows the approach in the Key Risk Indicators for Cyber Risk Guide. For AI the difference matters more than usual, because AI programmes generate large amounts of activity data (assessments completed, models registered, people trained) that can all be green while exposure grows.
| Question | KPI | KRI |
|---|---|---|
| Audience | AI governance committee, management | Board or risk committee |
| Measures | Throughput and control performance | Exposure against tolerance |
| Example | Median days to approve a new AI use case | Share of customer-facing AI decisions made by systems without tested human oversight |
| Threshold source | Service levels set by management | Tolerance derived from the board's appetite statement |
| Action when red | Management fixes the process | Board decides: accept, fund, restrict or stop |
NIST AI RMF 1.0 supports this split: GOVERN 1.5 asks for ongoing monitoring and periodic review of the risk management process and its outcomes, and MEASURE 1.1 asks that approaches and metrics for the AI risks identified in the MAP function are selected. ISO/IEC 42001:2023 requires the organisation to determine what needs to be monitored and measured (clause 9.1) and to feed results into management review (clause 9.3).
Write the appetite statements first
Each KRI tests a statement. Before choosing indicators, agree five to eight AI appetite statements with the board, in plain language. Examples an organisation might adopt:
- High-risk use: "We accept AI in decisions that significantly affect customers or staff only where a person with authority can review and override the outcome."
- Data: "We do not accept confidential or personal data being sent to AI services that we have not assessed and contracted."
- Autonomy: "AI agents may take irreversible or external actions only through an approval step or a pre-approved policy."
- Regulation: "We will meet every AI incident reporting deadline that applies to us."
- Dependency: "No critical business service depends on a single external AI model provider without a tested fallback."
- Quality: "Production AI that informs decisions stays within its agreed accuracy and error thresholds."
NIST CSF 2.0 GV.RM-02 calls for risk appetite and tolerance statements to be established, communicated and maintained; the Risk Appetite and Tolerance for Cyber Guide and the Cyber Risk Appetite Statement Template show how to write them.
The ten board KRIs
Thresholds are NHI Mgmt Group starting points; set your own from your appetite statements and record the reason for any change. "High-risk" means the top tiers of your own risk tiering scheme (see the AI Use Case Risk Tiering Guide). K1 and K6 are the only two measures that overlap with the operational health check, and here they are reported as exposure rather than process health.
| ID | KRI | Formula | Green | Amber | Red |
|---|---|---|---|---|---|
| K1 | Unregistered AI in use | AI systems and services found by discovery that are not in the AI register, by tier of data they touch | 0 handling confidential data | 1 to 3 handling confidential data | More than 3, or any handling special category data |
| K2 | High-risk AI outside tolerance | High-risk AI systems in production with residual risk rated above tolerance and no approved treatment plan | 0 | 1, with a plan due within 90 days | Any without a plan, or any plan overdue |
| K3 | Decisions without tested oversight | Customer- or staff-affecting AI decisions in the period made by systems whose human oversight was not tested in the last 12 months / all such decisions | 0% | Up to 5% | Above 5% |
| K4 | Sensitive data to unapproved AI | Blocked plus allowed attempts to send confidential or personal data to unassessed AI services, per 1,000 users per month | Falling quarter on quarter | Flat | Rising for two quarters |
| K5 | Agent actions without a gate | Irreversible or external actions by AI agents (payments, deletions, external email, permission changes) executed without approval or a pre-approved policy / all such actions | 0% | Below 1%, all reviewed | 1% or more, or any unreviewed |
| K6 | Reportable AI incidents | AI incidents in the period that met an external reporting threshold, and the number reported late | None late | Any reportable incident, all on time | Any reported late |
| K7 | Regulatory gaps on in-scope systems | AI systems in scope of a specific AI law (for example EU AI Act high-risk or transparency duties) with an open compliance gap past its due date | 0 | 1 to 2, dates agreed | Any gap that will be open on the legal application date |
| K8 | Model provider concentration | Critical business services that depend on one external model provider without a tested fallback | 0 | 1, fallback test scheduled | 2 or more, or any with no plan |
| K9 | Production AI outside performance thresholds | Decision-informing AI systems that breached their agreed accuracy, error or drift threshold for more than 30 days in the period | 0 | 1, with remediation running | 2 or more, or any affecting a high-risk system |
| K10 | Over-privileged AI identities | AI agents and AI service identities holding tenant-wide or admin-level access to business data / all AI agents and AI service identities | Below 5% | 5% to 15% | Above 15% |
What each KRI tells the board
- K1 and K4, shadow exposure: together they show whether AI use is outrunning governance. The Samsung ChatGPT source code leak in 2023, where staff pasted confidential code into a public AI service, is the pattern K4 is designed to surface early. See the Shadow AI Discovery Guide.
- K2 and K3, harm to people: where AI decides about customers or staff, the board needs to know both whether residual risk is accepted and whether oversight actually works.
- K5 and K10, agent autonomy: agents act through credentials. K10 counts the standing access; K5 counts what was done with it without a check. See the Agent to SaaS API Access Patterns Guide for reducing tenant-wide grants.
- K6 and K7, regulatory: the EU AI Act Article 73 sets serious incident reporting deadlines for providers of high-risk AI systems (no later than 15 days after awareness in general, 2 days for widespread infringement, 10 days in the event of death), and Article 26 requires deployers to monitor high-risk systems and keep logs for at least six months. Application dates for high-risk obligations were moved by the Digital Omnibus; track them in the EU AI Act Implementation Timeline Tracker and the AI Incident Reporting Clocks Map.
- K8, resilience: concentration on one provider is a business continuity risk as well as a third-party risk; NIST AI RMF GOVERN 6.2 asks for contingency processes for failures or incidents in high-risk third-party data or AI systems.
- K9, quality: drift and error breaches are often the first sign of a data or model problem; NIST AI RMF MANAGE 4.1 asks for post-deployment monitoring plans to be implemented.
Supporting KPIs
Four KPIs give the board context on whether the programme can keep up. Report them below the KRIs, never instead of them.
| ID | KPI | Formula | Why the board sees it |
|---|---|---|---|
| P1 | Use case approval lead time | Median working days from complete intake to decision | Slow approval drives shadow AI (K1, K4) |
| P2 | Risk treatment delivery | AI risk treatment actions closed by due date / actions due | Shows whether K2 will improve |
| P3 | Oversight test coverage | High-risk systems with a human oversight test in the last 12 months / high-risk systems | Leading indicator for K3 |
| P4 | Agent access review completion | AI agent identities re-certified in the last 90 days / AI agent identities | Leading indicator for K10 |
Building the board page
- One page, ten rows. Each row: KRI, current value, tolerance band, four-quarter trend arrow, owner, and one line of commentary.
- Lead with breaches of tolerance. Open with any red KRI and the decision requested: accept with a time limit, fund remediation, restrict the use case or stop it.
- Show movement, not only status. An amber KRI that has worsened for three quarters deserves more board time than a stable red one already under a funded plan.
- Name the appetite statement. Next to each KRI, cite the statement it tests, so directors can see when the appetite itself needs revisiting.
- Keep the evidence in an appendix. Formulas, data sources, exclusions and the last internal audit result for each measure.
- Agree the cadence. Quarterly to the risk committee, at least half-yearly to the full board, and immediately for any red K5 or K6.
For the format of the wider cyber pack see the Board Cyber Risk Reporting Guide and the Board Cyber Report Template.
Choosing KRIs by size and maturity
| Organisation | Start with | Add when ready |
|---|---|---|
| Small, using AI mainly through SaaS products | K1, K4, K6, K10 | K8 once any critical process relies on AI |
| Mid-sized, building some AI and agents | K1, K2, K4, K5, K6, K10 | K3, K9 as decision-making use cases go live |
| Large or regulated, provider of high-risk AI | All ten | Business-line splits and a quantified loss view per KRI |
Early in a programme, data will be partial. Report what you can measure, mark the confidence of each figure (high, medium or low) and show the date full measurement will start. A KRI that is honestly "low confidence" is more useful than a confident green built on an incomplete register. The AI Security Maturity Model helps set expectations for what each stage can measure.
Data sources and measurement quality
- Register and discovery (K1, K2, K7): the AI register, reconciled against procurement records, SaaS and OAuth grant inventories, AI gateway or secure web gateway logs and code repositories. See the AI Register and AI Inventory Template.
- Data loss prevention and gateway logs (K4): count both blocked and allowed events; a falling block count can mean users found another route.
- Agent platform and identity logs (K5, K10): tool call logs with an approval flag, identity provider and SaaS grant exports for agent identities.
- Incident register (K6): AI incidents with the reporting rule that applied and the timestamp of awareness and of report. See AI Incident Management and Escalation.
- Model monitoring (K9): agreed thresholds per system, recorded at approval, not set after the fact.
- Assurance: ask internal audit to re-perform two KRIs each year, rotating so all ten are tested over a cycle.
Common failure patterns
- Activity dressed as risk. The board pack lists models registered and assessments completed; nothing shows whether exposure is inside appetite.
- Thresholds set after the data arrives. Bands chosen so that the first report is green. Set tolerances from the appetite statement before the first measurement.
- Only the AI you built. Indicators cover in-house models while most AI arrives inside SaaS products and browser tools, so K1 and K4 read low because nobody looks.
- Agents counted as software, not identities. No measure of what agents can access or do, so the first sign of over-privilege is an incident.
- No decision attached. Red KRIs are noted and carried forward quarter after quarter without accept, fund, restrict or stop being recorded in the minutes.
- Legal dates treated as fixed. Regulatory KRIs keyed to dates that have since moved. Re-check application dates each quarter.
Framework mapping
| Framework | Reference | Relevant KRIs |
|---|---|---|
| NIST AI RMF 1.0 | GOVERN 1.5 monitoring and periodic review; GOVERN 1.6 AI inventory; GOVERN 2.3 executive responsibility for AI risk decisions; GOVERN 6.2 third-party contingency; MEASURE 1.1 metrics; MANAGE 4.1 post-deployment monitoring; MANAGE 4.3 incident communication | K1, K2, K6, K8, K9 |
| ISO/IEC 42001:2023 | Clause 6.2 AI objectives; clause 9.1 monitoring, measurement, analysis and evaluation; clause 9.3 management review | All |
| NIST CSF 2.0 | GV.RM-02 appetite and tolerance; GV.OV-03 risk management performance reviewed; GV.RR-01 leadership accountability; GV.SC-07 supplier risk monitored | All; K8 |
| NIST SP 800-53 Rev. 5 | PM-6 Measures of Performance; PM-9 Risk Management Strategy; CA-7 Continuous Monitoring; AC-6 Least Privilege | All; K10 |
| EU AI Act | Article 26 deployer obligations; Article 73 serious incident reporting | K3, K6, K7 |
Practitioner checklist
- Agree five to eight AI risk appetite statements with the board before choosing indicators.
- Map each KRI to one appetite statement and record the tolerance bands and their rationale.
- Include at least one KRI on agent actions and one on AI identity access.
- Count AI inside purchased products and browser tools, not only models you build.
- Track reportable AI incidents with the rule, the awareness time and the report time.
- Show four-quarter trends and a confidence rating for each figure.
- Attach a decision request to every red KRI and record the outcome in the minutes.
- Keep no more than two measures in common with the operational health check.
- Have internal audit re-perform two KRIs a year on rotation.
Standards and references
- NIST: AI Risk Management Framework (AI RMF 1.0), NIST AI 100-1
- ISO: ISO/IEC 42001 Artificial intelligence management system
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- EU AI Act: Article 73 Reporting of Serious Incidents
- EU AI Act: Article 26 Obligations of Deployers of High-Risk AI Systems
- OWASP: LLM06:2025 Excessive Agency
Related NHI Mgmt Group resources: AI Governance Guide · Board Briefing: AI Security · NIST AI RMF Guide · AI Governance Policy Template