What it means
- Every AI system has a named business owner who answers for it, and the company has a group (committee or existing risk committee) that oversees AI risk as a whole.
- Roles are written down: who approves new AI uses, who validates models, who monitors them, who handles incidents, who signs off on vendor AI.
- Staff have a clear route to raise concerns about an AI system (for example unfair outcomes or misuse) without fear of blame.
- Where AI is supplied by or to a partner, the contract and RACI say which side is responsible for what.
Why it matters
- RBI FREE-AI puts AI risk under the Risk Management Committee and suggests a cross-functional AI committee.
- When something goes wrong, "the model did it" is not an answer. Regulators and customers want a person who was accountable.
- Clear roles stop the gap where IT thinks business owns the model and business thinks IT does.
Checklist
- Decide where AI oversight sits: existing RMC, a new AI committee, or both. Write terms of reference (members, quorum, frequency, decisions it can take).
- Include risk, compliance, legal, IT/security, data, and business heads on the committee.
- Build a RACI for the AI lifecycle: intake, risk assessment, build or buy, testing, approval, deployment, monitoring, incidents, retirement.
- Assign a business owner and technical owner for every system in the SC-AI-003 AI system inventory.
- Keep developers and validators separate for medium and high risk systems.
- Set up a channel to report AI concerns (email alias, ethics hotline category, or ticket type) and tell staff about it.
- For partner or vendor AI, record the split of responsibilities in contracts.
Evidence examples
- AI committee terms of reference approved by the board, and the last four sets of meeting minutes.
- RACI matrix for the AI lifecycle, version-controlled.
- Inventory extract showing named owners for each AI system.
- Job descriptions or appointment letters naming the AI risk owner.
- Concern-reporting channel communication and a log of concerns raised and closed.
Common pitfalls
- Committee exists on paper but never meets, or meets without minutes.
- Owners named as teams ("Data Science") rather than people.
- Same person builds, tests and approves a high-risk model.
- No path for frontline staff to flag a misbehaving AI tool.
Satisfies
- VoluntaryISO/IEC 42001
- BindingEU AI Act
- SupervisoryPRA SS1/23
- VoluntaryNIST AI RMF and GenAI Profile
- SupervisoryNYDFS AI Cybersecurity Letter 2024
- BindingKorea AI Basic Act
- SupervisoryOSFI E-23
- VoluntaryRBI FREE-AI
Also relevant to
- ICMR AI in Healthcare Guidelinesno numbered obligations; mapped in its practical notes (accountability and liability split agreed before deployment)
- NITI Aayog Responsible AI for Allno numbered obligations; mapped in its practical notes (ethics committee idea)
Standards crosswalk
Clause references only. Check the standard itself for the exact wording.
ISO/IEC 42001
- 5.1 Leadership and commitment
- 5.3 Roles, responsibilities and authorities
- A.3.2 AI roles and responsibilities
- A.3.3 Reporting of concerns
- A.10.2 Allocating responsibilities
ISO/IEC 27001
- A.5.2 Information security roles and responsibilities
- A.5.3 Segregation of duties
- A.5.4 Management responsibilities
SOC 2
- CC1.2
- CC1.3
- CC1.5
Key takeaways
- Name a person for every AI system and a forum for AI risk overall.
- Partial reuse from ISO 27001: the roles, segregation of duties and management responsibility patterns carry over; the AI committee and concern-reporting channel are new.
- Write down responsibility splits with vendors and partners before go-live.