AI Operating Models in Banking: The Case for Useful Friction
Rewiring the banking operating model for agentic AI means preserving the controls that matter, even at the cost of speed-to-value
Executive Summary
- Governance, control and auditability are too often treated as a secondary step, mistaken for unnecessary friction that delays time-to-value in agentic programmes.
- Even when controls are addressed, teams still rarely consider the wider operating-model implications for the end-to-end process being agentified.
- Many control objectives are load-bearing, doing more than simply compensating for human frailty. They preserve safety, accountability and trust and should not be lost.
- An Agentic Development Framework (ADF) provides a repeatable way to agentify processes, ensuring what is deployed is trusted, safe and auditable at scale.
- Designing and operating an AOM is not just a question of deploying agents. It is the only way to be confident your agent-enabled processes will stand up to auditor, regulator and customer scrutiny.
Imagine a bank that using artificial intelligence to accelerate customer onboarding, cutting processing times sharply and improving completion rates. Months later, a review finds that edge-case identity checks, previously caught through human verification, had been mishandled at scale. The model had performed as designed, but the operating model around it did not.
This is one of the defining risks of the agentic era. The technology accelerates decision-making, but where the surrounding control architecture does not keep pace, errors no longer sit quietly inside a slow-moving process. Instead, they compound at machine speed until they surface somewhere visible.
The challenge is to understand which areas of friction carry control, accountability and judgement and ensure those elements are rebuilt correctly within the agentified institution.
Friction is not the enemy
The appeal of agentic AI is clear, offering the promise of fewer hand-offs, faster decisions and more responsive service. Some friction in banking processes is plainly wasteful and should disappear.
Yet some friction is load-bearing. A manual review, a sequential approval or a mandatory escalation often exist because they introduce visibility, create accountability or slow a decision at precisely the point where the institution benefits.
The operating model challenge is therefore not to remove friction wholesale. Rather, it is to separate drag from discipline and to ensure that when control points become automated, their governance function is deliberately rebuilt elsewhere in the workflow.
|
|
|
|---|---|
|
Illustrative failure mode |
A bank introduces an agentic decisioning workflow to replace a manual process that previously included a compliance review. The review had routinely identified recurring data-quality issues in a third-party rules feed. The new workflow now processes decisions at volume without an equivalent control in place. Over time, the issue persists until a subsequent review uncovers it. In such a case, the failure is not automation itself, but the removal of a control the workflow did not replicate, even though the process still depended on it. |
Governance moves into workflow
Traditional banking operating models assumed that decisions moved in stages. Business teams originated activity, while technology ran systems and risk, compliance and oversight reviewed outputs. That system worked well when decisions were slow and discrete enough to be checked between steps.
Yet autonomous workflows break that assumption. Agents can ingest data, apply policy logic, generate communications and trigger downstream actions in seconds. Hence, when governance and control sits outside the workflow, they become retrospective by design. For banks, that creates a need for policy rules, escalation thresholds and human override points to be designed into the Agentic Operating Model (AOM) and enabled by the orchestration layer.
UK regulation points in the same direction1. Institutions are required, for example, to avoid foreseeable customer harms, not merely remediate them after the fact. Meanwhile, important business services must remain within defined impact tolerances under stress and accountability must be located with named individuals rather than systems. Taken together, it is clear that these and other such requirements make post-fact governance a weak solution for safe, real-time autonomous decisioning.
|
|
|
|---|---|
|
Design principle |
For every autonomous decision loop, define the Agentic Operating Model (AOM) in advance. This includes determining what the agent can decide without human input, what conditions trigger escalation, who owns the escalation path and what constitutes an outcome that requires an immediate circuit-break as part of governance architecture. |
From pilots to production: building repeatable deployment
These days, few banks lack for AI pilots. However, what many do still need is the Agentic Development Framework (ADF) to deliver holistic agentification. While a pilot can tolerate informal controls and close human oversight, a production environment cannot.
At scale, the ADF is a disciplined development and deployment system resembling a factory: clear gates exist for scoping and design, data ingestion, model development, validation, deployment, monitoring and retirement. There are also defined controls embedded at each stage, including automated documentation and feedback loops to surface issues early.
The goal here is not simply to make AI deployment faster. It is rather to achieve repeatable, auditable deployments of AOMs that can be trusted at scale. The seven-stage lifecycle below illustrates what this ‘factory model’ requires at each step, showing the failure signals that appear when stages are bypassed under delivery pressure.
Table 1: The seven-stage lifecycle underpinning the ‘factory model’ of the Agentic Development Framework (ADF)
Source: Deloitte
In practice, the biggest issue is overly narrow scoping and design. This would typically include failing to treat the control operating framework as part of the use-case requirements, and effectively outsourcing business-process responsibility to the technology. Within the technical build, the weakest points are validation and monitoring, where validation can be compressed under delivery pressure while monitoring is narrowed to model performance rather than decision quality, downstream effects2 or outcome fairness. Such gaps may be manageable in a pilot, but in production they become structural vulnerabilities.
Accountability does not distribute, it relocates
One of the subtler operating model issues of the agentic era is what happens to accountability when an automated workflow spans multiple functions and is made up of multiple agentic components. Here, the challenge is not assigning responsibility for a single monolithic system, but making clear who owns which decision domains, workflow stages and underlying agents across design, training, data, testing, deployment and post-deployment monitoring. Much of that ownership is likely to follow existing functional lines, provided the mapping has been done explicitly and the underlying agents are visible. But that alone is not enough. As agentic workflows scale, firms need clear accountability for the end-to-end control environment and for the collective risks that arise across multiple agents, particularly from a resilience and accountability perspective. Indeed, while the latter may overlap in practice, it must still resolve to named ownership at both component and system level before deployment, rather than after something has gone wrong.
When a regulator asks who was accountable for a decision, “the workflow” is not an acceptable answer.
In practical terms, banks need explicit decision rights for autonomous workflows so they can identify who owns each decision domain, each underlying agent or control point, the escalation path, the monitoring of outcomes and the authority to pause, intervene or override where necessary. Those accountabilities also need to be clear across the lifecycle, from design, training data and testing through to deployment, monitoring and change. And since multiple agents can create aggregate risks that sit beyond any single workflow step, institutions also need clear ownership for the end-to-end control environment. These responsibilities must be documented, tested and made visible, not inferred from legacy organisational charts that predate deployment.
|
|
|
|---|---|
|
Illustrative failure mode |
A bank deploys an agentic workflow spanning credit, fraud and customer communications. A customer complaint exposes a series of conflicting automated decisions. Different senior managers believe that accountability sits elsewhere. The regulatory problem is no longer just the underlying error, but the fact that ownership of the decision chain was never clearly mapped. |
New operating model, new capabilities
Operating model transformation in the agentic era is not just structural. It is a capability challenge that leaves many institutions trying to scale autonomous workflows with talent models built for slower, more modular systems. In this context, new roles are emerging while others are changing.
New roles:
Transformed functions:
Seen this way, the talent gap is not just a people issue as much as an operating model risk. Institutions that deploy agentic capabilities faster than they build governance talent are not simply understaffed. They are creating structural vulnerability. While this gap may be manageable in the short term, at scale, this is the type of risk that will surface in regulatory review.
Diagnostic questions
Map your current autonomous workflows against five questions:
- Which process controls from the pre-agentic era still matter, and what new process controls are needed?
- Have all these controls been built and subjected to audit?
- Was training provided to support any operating model changes?
- Has ownership of the impacted decision domain been defined?
- Has that accountability been tested in practice?
If the answer to any of these questions is unclear, the operating model is unlikely to be a suitable AOM and will be much harder to govern.
Measure what matters
Traditional performance metrics do not disappear in the agentic era. Throughput and cost still matter. But in an orchestrated model, banks will also need to know that their controls can function at speed. That means measuring things that were perhaps easier to ignore in the pre-agentic era, such as:
|
|
|
|---|---|
|
Outcome quality and fairness |
are autonomous decisions producing materially different outcomes across customer groups, and is that being monitored in something close to real time? |
|
Escalation effectiveness |
are human interventions being triggered at the right thresholds, or has the HITL mechanism become nominal, rather than real? |
|
Governance latency |
how quickly can the institution identify, contain and remediate an error propagated through an autonomous workflow? |
|
Auditability |
can the institution reconstruct, within a defined timeframe, how a recent autonomous decision was made in human explainable terms and who owns it? |
Finance has a specific role here too. Business cases for agentic capability should capture not only labour savings, but resilience gains, avoided remediation costs and the long-term value of earned supervisory trust and faster, more confident deployment. In this way, governable autonomy becomes a key source of commercial advantage.
The questions leaders should be asking
Technology changes what is possible. The operating model determines whether what is possible can be trusted.
References
1. Our UK AI Hub provides space for Deloitte’s topic experts to publish their perspectives on the major transformation questions raised by AI adoption in banking and financial services: how institutions modernise their technology estates, redesign operating models, reshape workforces, strengthen governance and scale AI safely and effectively. Regulation is central to that agenda and is a substantial and rapidly evolving topic in its own right. The regulatory implications of AI depend heavily on use case, institution, type of customer or client affected, the jurisdictions involved and the ways in which technology is designed, deployed and controlled. For that reason, this series of article focuses on the transformation themes at hand. For detailed information on regulatory considerations related to AI, we direct readers to our European Centre for Regulatory Strategy (ECRS) for the latest regulatory developments in AI. https://www.deloitte.com/uk/en/blogs/ecrs.html
2. Including interaction between agents, discussed in more detail in our previous article - https://preview3.deloitte.com/content/websites/uk/en/Industries/financial-services/blogs/ai-architecture-in-banking.html (Should replace with the live URL soon)
