01 · Scope
What Is AI Risk Management?
AI risk management is the continuing process of identifying, analysing, treating, monitoring and communicating risks created by AI systems. It addresses potential harm to people, organisations and society across design, acquisition, deployment, use and retirement.
This guide concerns the risk of AI systems themselves—not using AI to automate conventional financial or enterprise risk work. Effective practice combines technical evaluation with business context, accountable judgment and control evidence.
02 · Taxonomy
Key Risk Categories for Enterprise AI
People and decisions
Bias, exclusion, unsafe reliance, opacity, loss of recourse and inappropriate automation.
Security and privacy
Data exposure, hostile input, excessive access, model abuse and supply-chain weakness.
Performance and reliability
Inaccuracy, drift, brittle behaviour, unavailable services and unsuitable evaluation.
Operational and legal
Unclear ownership, third-party dependency, regulatory obligations and weak incident response.
Categories help coverage, but risk must be evaluated in context. The same technical limitation can have very different consequences in a drafting assistant and a system influencing employment, credit or access to essential services.
03 · Workflow
The AI Risk Management Workflow
- Define the intended use, boundaries and accountable owner.
- Identify affected people, systems, data, decisions and dependencies.
- Assess inherent risk using documented assumptions.
- Select and implement preventive, detective and response controls.
- Evaluate residual risk and unresolved uncertainty.
- Approve, reject or accept with explicit conditions and authority.
- Monitor operation and reassess after material change.
The workflow creates a decision trail rather than a static score. Each step should produce evidence that the next reviewer can understand.
04 · Method
AI Risk Identification and Assessment
Begin with intended purpose, affected people, decision significance, operating environment, data, users, autonomy and external dependencies. Identify plausible failures and misuse, estimate impact and likelihood using documented assumptions, and assess the strength of existing controls.
Assess potential impact and reversibility, scale, autonomy, data sensitivity, regulatory or contractual exposure, detectability, recovery and supplier dependency. Scores support prioritisation, but should not hide uncertainty. A 1–5 scale can be adapted to an existing enterprise method; it is not a universal formula. Record evidence, rationale, assessor, approver and conditions.
05 · Decision record
A Practical AI Risk Register
The register should connect a specific failure or misuse scenario to controls, ownership and the residual decision. Avoid entries such as “bias risk” without the affected decision, population and consequence.
| Use case / risk scenario | Inherent risk | Controls | Evidence | Owner | Residual decision | Reassessment trigger |
|---|---|---|---|---|---|---|
| Service agent updates a customer account using incorrect context | Material: financial and customer impact | Verified identity, bounded fields, approval above threshold, rollback | Test results, policy decision, action log and exception record | Service operations owner | Approve low-impact changes within limits | New data source, broader permissions, repeated failures or supplier model change |
06 · Authority
Risk Appetite, Exceptions and Acceptance
Define which role may accept residual risk at each tier and which outcomes cannot be accepted. An exception should record the unmet requirement, rationale, compensating controls, owner, expiry date and monitoring condition. High-impact exceptions should escalate to an authority independent of delivery pressure.
Acceptance is a time-bound decision, not a permanent label. Control failure, incident, material change or expiry should reopen the decision automatically.
04 · Framework
NIST AI Risk Management Framework
The NIST AI RMF is a voluntary, technology-neutral framework organised around Govern, Map, Measure and Manage. Govern establishes culture, policy and accountability; Map develops context; Measure analyses and monitors risk; Manage prioritises and acts on findings. The functions are connected rather than sequential certification steps.
Organisations can use the framework to structure responsibilities and evidence, then adapt practices to their sector, use cases and risk appetite. The companion Generative AI Profile offers additional considerations for generative AI.
Primary references
05 · Regulation
EU AI Act and Regulatory Considerations
The EU AI Act applies obligations according to roles and risk-related categories, with requirements entering into application on a phased timetable. Whether a particular system or organisation is in scope depends on facts such as the use case, market role and jurisdiction.
Governance teams should maintain system context, classifications, supplier information, technical and operational evidence, human-oversight arrangements and post-deployment monitoring where applicable. A software feature or template does not itself establish legal compliance; obtain qualified advice for specific obligations.
Official guidance
09 · Supply chain
Third-Party AI and Supplier Risk
Third-party AI can shift implementation without transferring accountability for how the organisation uses the service. Scope and tier the service, request proportionate evidence, set contractual change and incident duties, and retain an exit path.
Monitor material supplier changes after contract signature. A new model, embedded agent, data-processing location or tool integration can change the risk profile even when the product name remains the same. Use the AI third-party risk management guide for the complete supplier lifecycle and the EU AI Act supplier-readiness guide for regulatory evidence questions.
10 · Treatment
Mapping Risks to Governance Controls
Each material risk should map to preventive, detective, corrective or compensating controls with a named owner. Traceability matters: risk scenario → control objective → implementation → evidence → residual-risk decision.
| Risk scenario | Preventive control | Detective control | Response control | Evidence |
|---|---|---|---|---|
| Agent acts beyond approved value | Transaction and permission limit | Policy evaluation of every action | Block, escalate and revoke if repeated | Policy version, request, decision and outcome |
| Sensitive data reaches an external model | Data classification and routing restriction | Content and access monitoring | Contain, investigate and notify | Data source, rule, event and remediation |
| Supplier changes model or processing | Contractual notice and approved configuration | Change monitoring and periodic attestation | Reassess, restrict or exit | Notice, assessment and approval record |
11 · Continuous assurance
Continuous Risk Monitoring and Evidence
Risk changes as data, models, prompts, tools, users and environments change. Monitoring should combine technical signals with operational events such as complaints, overrides, exceptions, supplier changes and emerging failure patterns.
Set thresholds for review and response. Permission changes, incidents, control failures, drift, new populations, supplier changes and expired exceptions should trigger reassessment. Preserve evidence proportionately: what changed, how it affected risk, which control responded, who decided the outcome and whether remediation was verified. See evidence and metrics buyers can verify.
09 · Buying criteria
How to Evaluate AI Risk Management Capabilities
- Test whether assessments capture context and dependencies, not only a generic questionnaire.
- Trace a finding to control ownership, treatment, approval and verification.
- Check framework mappings without assuming a mapping equals compliance.
- Demonstrate supplier monitoring and reassessment after a material change.
- Export evidence with provenance, dates, roles and decision history intact.
Use the platform buyer's guide to compare broader tool categories and operating fit.
13 · Further reading
Related Insights
AI third-party risk management
Govern suppliers from intake through change, incident and exit.
Read insight →FrameworkNIST AI RMF: a practical operating model for buyers
Translate the four functions into observable capabilities.
Read insight →RegulationEU AI Act readiness: evidence questions for suppliers
Distinguish useful evidence from broad claims.
Read insight →