What it means
- For each AI system (depth set by its tier), identify what could go wrong, how likely it is, how bad it would be, and what you will do about it.
- AI-specific risks to cover: wrong or made-up outputs, bias, drift over time, data leakage through prompts, prompt injection, over-reliance by staff, vendor lock-in, regulatory breach, reputational harm.
- Risks go into the AI (or enterprise) risk register with an owner, treatment plan and residual rating accepted by the right person.
- Repeat on a schedule and whenever the system changes.
Why it matters
- RBI FREE-AI puts AI risk under the board's risk committee and expects AI-specific checks before product approval.
- A documented risk assessment is the main way to show regulators the company thought before it deployed.
- It feeds testing, monitoring and audit priorities, so effort goes where risk is highest.
Checklist
- Extend the enterprise risk methodology with an AI risk catalogue (list of typical AI risks with examples).
- Assess every medium and high risk system before go-live; use a short-form assessment for low risk.
- Record risks in the risk register with owner, inherent rating, controls, residual rating and treatment actions with dates.
- Get residual risk accepted at the level the AI policy requires (for example CRO for high risk).
- Link each risk to the controls that treat it (testing, oversight, monitoring).
- Reassess at least annually and on material change (SC-AI-019 Change management and approval gates).
- Report top AI risks to the AI committee or RMC.
Evidence examples
- Completed AI risk assessment for the credit scoring model, signed by the model owner and CRO.
- Risk register extract filtered on AI risks, showing treatment status.
- AI risk catalogue or methodology document, approved and versioned.
- RMC minutes discussing the AI risk heatmap.
Common pitfalls
- Using the security risk template unchanged, so bias, explainability and drift never appear.
- Assessing the vendor but not how the company uses the vendor's model.
- Risk accepted by the same team that built the system.
- No reassessment after a major model update.
Satisfies
- VoluntaryISO/IEC 42001
- BindingEU AI Act
- SupervisoryPRA SS1/23
- VoluntaryNIST AI RMF and GenAI Profile
- SupervisoryNYDFS AI Cybersecurity Letter 2024
- BindingTexas TRAIGA
- BindingKorea AI Basic Act
- SupervisoryOSFI E-23
- VoluntaryRBI FREE-AI
Also relevant to
- NITI Aayog Responsible AI for Allno numbered obligations; mapped in its practical notes (accountability principle: risk and impact assessments)
Standards crosswalk
Clause references only. Check the standard itself for the exact wording.
ISO/IEC 42001
- 6.1.1 Actions to address risks and opportunities
- 6.1.2 AI risk assessment
- 6.1.3 AI risk treatment
- 8.2 AI risk assessment (performed at planned intervals)
- 8.3 AI risk treatment (implemented)
ISO/IEC 27001
- Clause 6.1.2 Information security risk assessment
- Clause 6.1.3 Information security risk treatment
- Clause 8.2 Information security risk assessment (performed)
SOC 2
- CC3.1
- CC3.2
- CC3.4
Key takeaways
- Reuse the risk method you already run; add an AI risk catalogue so AI-specific risks are not missed.
- Strong reuse of ISO 27001 risk process (clauses 6.1.2, 6.1.3, 8.2), though ISO 27001 Annex A has no AI risk content; the risk types are new.
- Tie each risk to the controls that treat it and reassess on change.