AI Risk Program Management
AI Risk Program Management
This domain tests whether you can run AI risk as a repeatable program: taxonomy, assessment method, metrics, reporting, assurance and third parties.
Core rules
- Adopt a common AI risk taxonomy so scores are comparable across use cases; assess inherent and residual risk separately.
- Use a defined methodology with calibrated scales and explicit impact dimensions: people, regulatory, financial, reputational, operational.
- Define KRIs before deployment: drift rate, incident and near-miss counts, human-override rate, inventory coverage, overdue remediation.
- Report an aggregate risk profile to the board on a fixed cadence with trends, top risks, incidents and remediation status - not a list of every model.
- Third-party AI requires due diligence, contract clauses on audit rights, incident notification, data use and change notification, plus ongoing monitoring.
- Independent assurance should test design and operating effectiveness of controls, not merely confirm the register exists.
Worked example. A quarterly AI risk report. The program manager aggregates: 42 models in inventory (up from 30), two high-risk deployments flagged, drift KRI amber on three models, one reportable incident closed, remediation 80% on time. Reasoning: the report is decision-oriented - it shows movement and asks for decisions on the two high-risk items; it uses the same scales as the enterprise register so the board can compare AI with other risks; it reports outcomes such as incidents and override rates rather than activity such as training sessions held.
Traps. A register with no owners; scores never recalibrated so everything lands as "medium"; measuring program activity instead of risk outcomes; one-off assessments instead of continuous monitoring; and letting the AI program duplicate ERM rather than feed it.