Banks already run processes that combine fixed rules with scoring models. Human approvals sit on top of both. Agentic AI adds another element: software that can choose the next step and then take it. Risk teams need to know who challenges that choice and who owns the outcome.
This article proposes an operating model for agentic AI risk management, with a focus on the handoff between model risk and operational risk. Adapt it to the structure of your own institution.
Workflow discretion runs along a continuum
Most banking processes mix several kinds of decision-making. The useful question is how much discretion each step carries.
A single process can use all four. A lending workflow might apply an eligibility rule and call a scoring model. An agent could then choose which documents to request, and an underwriter could make the final call.
Mark the boundaries of agent discretion
Map every step in the process to one of the four types before assigning any review. For each agent-selected step, document the following:
- The actions the agent may take
- The systems the agent can reach
- Limits on amount, scope or customer segment
- The conditions that force a handoff to a person
This map shows where discretion begins and where it ends. Both review functions work from it.
Where model risk and operational risk hand off
Model risk and operational risk each see only part of an agent.
Model risk has a clear interest in the model inside an agent. The agent also selects steps and acts inside production systems. Operational risk covers that activity.
Gaps appear at the seam. Validation may confirm that the underlying model performs as intended, yet nobody tests whether the permissions around it limit what the agent can do. The reverse happens too: an operational review signs off on access and nobody revisits the model after a material change.
Design the handoff explicitly. Model risk passes its findings on limitations to operational risk, which turns them into permissions and exception paths. When incidents reveal behavior that validation did not anticipate, those findings travel back to model risk.
A proposed responsibility split for agentic AI
Treat the split below as a starting point that you adjust to your lines of defense and committee structure. Existing policy may already assign some of these duties.
What model risk challenges
- The purpose the agent and its underlying models serve
- Known limitations of those models
- Validation approach and evidence
- Performance against expectations over time
- Which changes count as material
What operational risk challenges
- Who owns the process end to end
- The permissions the agent holds
- How exceptions are detected and routed
- How incidents are logged and escalated
- Recovery procedures when the agent stops or fails
- Resilience of the process and its dependencies
What the named business owner keeps
One named person in the business stays accountable for outcomes. That person approves the scope of agent discretion and answers for what the process produces. Model risk and operational risk challenge the owner's choices while accountability stays put.
Independent oversight, such as internal audit, can then test whether the split works in practice.
Lifecycle responsibility matrix
Use this matrix to assign duties by stage. Replace each function with a name before approval.
Pre-go-live questions for agentic AI
Put these to the right person in a joint session. Record each answer with a name beside it.
Business owner
- Which outcome am I accountable for, and who covers for me?
- Which decisions may the agent make without a human, and when must it hand a case to a person?
Model risk
- What is the intended purpose, and where does performance fall short?
- What evidence shows that performance holds on our own data?
- Which changes would we treat as material?
Operational risk
- What permissions does the agent hold, and who approved them?
- What happens when the agent meets an exception it was not built for?
- How do we stop the agent and recover the cases it touched?
- Which incidents trigger escalation, and to whom?
What the OCC bulletin covers and what it leaves open
A US example shows why an institution's own framework matters. In April 2026, the OCC issued Bulletin 2026-13. The bulletin explicitly excludes generative and agentic AI models from its scope. It is also not prescriptive or enforceable.
Read that as a statement about scope. Other controls may still apply to an agentic process, including internal policy and other supervisory expectations, so ask your legal and compliance colleagues how they apply. This article is not legal advice.
Security and compliance have their own pages
Threats to agents need dedicated treatment, so read agentic AI security in banking for that discussion. Regulatory workflows also deserve depth, and agentic AI compliance in banking covers that topic.
An operating-model perspective from EY
EY has published a perspective on what risk leaders need to do now about agentic AI. It makes a useful companion when you test this split against your own operating model.
Where does Backbase fit in agentic AI risk management?
AI can reason. Banking OS makes it safe to act. Model risk and operational risk keep their roles, and so do regulators and business owners. What Banking OS adds is a record the people holding the matrix can check an answer against.
- Platform context: Maintains operational memory across every interaction, decision, and case.
- Authority: Checks authority before action: identity, policy, limits, and evidence.
- Execution: Executes across people and systems, preserving state through every handoff.
- Evidence and human control: Records what happened and why, with human control for judgment and exceptions.
Agentic AI risk management works when each question has a named answer before the agent goes live.
