The wrong starting question
Most banks are asking where AI can be adopted. It is a reasonable question, and it produces real gains. Copilots speed up analysis and routine material. Automation removes repetitive work. Benefits appear without changing the wider organisation.
But it settles a more important question too early. The current bank becomes the fixed part of the equation, and AI becomes something to insert into it. The same departments, handoffs, decision rights and controls remain. AI is asked to perform inside yesterday's operating model.
A bank can automate a great deal of work without challenging why that work exists.
The stakes are larger than they first appear. Adopted programme by programme, AI may improve productivity in each area while the operating model stays as it was. Each programme also builds its own answers to context, authority and control, and those answers start to conflict once AI does consequential work. The opportunity is to treat AI as an operating-model question from the start: which work, decisions and controls would the bank design if this intelligence had always been available?
I see this from two sides: more than 25 years of delivering banking technology and transformation programmes, and now building Henova, an AI-native health company in a regulated domain. Henova is not a bank. But it shows what changes when an organisation is designed around AI rather than retrofitted with it, and several of those lessons transfer.
Start with the obligation, not the process
First-principles work does not require a blank sheet. It requires separating what the bank must preserve from what it has simply become accustomed to.
Capital, conduct, privacy, resilience, model risk and accountability are genuine constraints. A particular committee, queue or sequence of handoffs may not be. Many processes exist because information once had to be assembled manually and controls could only run at fixed checkpoints. If an AI-enabled lending process can assemble evidence, test it against policy and prepare a reasoned recommendation, the case need not move through the same sequence of teams.
This is not an argument for removing controls. It is an argument for distinguishing the accountability a control exists to protect from the mechanism that historically implemented it.
Separate AI programmes start colliding
AI is entering the bank in several places at once:
- as a co-worker, helping people analyse and decide;
- across the software lifecycle, from requirements to validation and release;
- in operations, where agents route, coordinate and execute work;
- in customer and colleague channels, as part of the interaction itself.
These usually start as separate programmes, and for a while each can progress alone. That separation does not survive serious operation. Once each is asked to do consequential work, they meet the same questions:
- Which context is authoritative, and which state is current?
- Who has authority to decide, and on what evidence?
- Where must a person decide?
- What may the machine do next?
- When a decision is superseded, how does everything that relied on it find out?
These are questions about the environment the models operate in, not about the models themselves. A bank that answers them separately in each programme ends up with several partial sets of controls and no shared account of what is true.
The deeper challenge is not deciding where to use AI. It is engineering the environment in which people and machines can reason, decide and act without losing authority, evidence or control.
Guardrails make ambition usable
Well-designed guardrails make more ambitious use of AI possible. They define what a system may do, the evidence it must produce and when a person must intervene. That gives Risk, Compliance and Internal Audit something concrete to assess.
But a guardrail written for one programme will not govern an agent in operations, an assistant in a channel and a validation step in the delivery pipeline. Those controls increasingly need to operate across the common layer, where they can determine whether work should proceed. That is what lets a bank extend trust in AI without renegotiating it one use case at a time.
What building Henova shows
Henova is small enough to observe, which is its value. I would not claim that what works there automatically works at banking scale.
The failures that mattered were rarely failures of intelligence:
- An agent reasoned well from context that had since been superseded.
- A sound conclusion reached in conversation never became something others could rely on.
- Work was ready to proceed before anyone with authority had agreed it should.
- When an authorised person did decide, the decision had to become something the system could reliably act on. It could not stay trapped in a conversation or meeting note.
None of these was a model problem. Each was an operating-model problem that surfaced as an AI problem, which is why better prompts did not fix them. Explicit mechanisms did: governed context, clear decision rights, retained provenance, named human decision points and an auditable record of how the organisation's state changes.
A bank will meet the same classes of problem with far more history, scale and control complexity. The authority question in particular deserves its own treatment, which I explore in Humans arbitrate. Agents execute.
What leadership decides, and what technology builds
This cannot be delegated to a technology or innovation function. Co-worker tools, coding agents, workflow automation and channel AI often have different owners. Each can succeed locally while authority, evidence and current state belong to no one.
Business leadership has to decide what the bank must preserve: its obligations, its accountabilities and the moments where human judgement counts. It has to decide which decisions can be delegated, and within what limits. Technology then has to build the shared foundations that let every programme operate on the same terms: authoritative context, explicit decision rights, retained evidence and controls that can stop work before it proceeds.
None of this removes the human role; it makes it more deliberate. As machines take on more execution, human authority cannot rest on an assumption about who is watching. It has to be designed into the work.
Design one journey differently
Take one important customer or operating journey and redesign it as if better intelligence were already available. Keep the obligations, the accountability and the moments where human judgement counts. Challenge the process around them.
Build it as a working prototype. A prototype shows where data is weak, policy ambiguous and judgement essential, and gives leaders and control teams something better to challenge than a statement of ambition. A good journey will usually expose several of the seams above at once. That makes it a useful test of whether the bank is building shared foundations or another isolated AI solution.
Done well, the result could be fewer handoffs, controls that run earlier or continuously, and people concentrated on judgement rather than assembly. Those are possibilities to test, not outcomes Henova has proven at banking scale. The prototype is how a bank finds out.
That is more demanding than an AI adoption plan. It may also stop the bank spending the next few years placing new tools into an operating model it would no longer choose to build.
Adoption asks where AI fits. Design asks what the bank should become.