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 · 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.
Scores support prioritisation, but should not hide uncertainty. Record the evidence, rationale, assessor, approver and conditions attached to the decision.
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
06 · Supply chain
Third-Party AI and Supplier Risk
Third-party AI can shift implementation without transferring accountability for how the organisation uses the service. Due diligence should examine intended and prohibited uses, model and data dependencies, security, evaluation evidence, incident notification, change management, subcontractors, audit rights, retention and exit arrangements.
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.
07 · Treatment
Mapping Risks to Governance Controls
Each material risk should map to preventive, detective, corrective or compensating controls with a named owner. Controls may include access restrictions, data minimisation, independent testing, human confirmation, output review, usage limits, monitoring, incident playbooks or a decision not to deploy.
Traceability matters: risk scenario → control objective → implementation → evidence → residual-risk decision. Without that chain, a control library can appear complete while leaving the real exposure unmanaged.
08 · 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. Preserve evidence proportionately: what changed, how it affected risk, which control responded, who decided the outcome and whether remediation was verified.
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.
10 · Further reading