Most banks do not have an idea shortage. They have a conversion problem.
There are plenty of demonstrations that look promising in a controlled setting. A document is summarised. A meeting note becomes a list of actions. A chatbot answers a policy question. Then the difficult work begins: data access, security review, integration, evaluation, ownership, training, support and evidence that the product changed something that matters.
This is where many pilots slow down. The experiment was designed to prove that a model could perform a task. It was not designed to become a reliable part of the bank.
Private banks should approach this differently. The goal should be an AI operating system: not a single technical system, but a repeatable way to connect strategy, platform capabilities, governance, delivery and adoption.
Start with the mandate, not the model
An AI portfolio needs a small number of outcomes that the institution cares about. These might include more client-facing capacity, better service, lower operational effort, stronger controls or faster access to knowledge. The exact mix depends on the bank’s strategy.
That sounds obvious, but it changes the conversation. A proposal is no longer “we should test an agent.” It becomes “this workflow consumes scarce relationship-manager time, the current information path is fragmented, and we believe a controlled assistant can improve preparation quality and speed.”
The distinction matters. It gives the team a baseline, an accountable user, a reason to prioritise the work and a way to decide whether to stop.
BCG’s “For Banks, the AI Reckoning Is Here” (21 May 2025) makes a similar point: banks need to anchor AI strategy in business strategy and focus on where the technology can create real returns. This is less exciting than collecting experiments. It is also much more useful.
Build shared capabilities before every team builds its own
The second part of the operating system is a platform-product mindset.
Consider four early use cases: a policy assistant, client-meeting preparation, investment-research synthesis and operations case triage. They look different at the surface. Underneath, they reuse many of the same capabilities:
- enterprise identity and role-based access;
- retrieval from approved knowledge sources;
- model routing;
- prompt and workflow versioning;
- source citation;
- evaluation;
- human-review steps;
- usage monitoring and audit trails.
If each use case solves these independently, the bank creates cost, inconsistency and risk. If a platform team turns them into reusable services, every subsequent product starts from a stronger base.
This does not mean creating a large central platform before delivering anything. I prefer a thin-platform approach: build the first reusable components through a real use case, then harden them as more products prove the pattern.
The platform roadmap and the use-case roadmap should therefore be one conversation. Product teams create demand for capabilities. Platform teams make those capabilities repeatable. Each side improves the other.
Put governance inside the delivery path
In a regulated institution, governance cannot be a presentation prepared at the end of a pilot. By then, important design decisions have already been made.
The safer approach is to translate policy into the product itself. Identity determines who can access a capability. Data classifications determine which sources can be retrieved. Tool permissions limit what an agent can do. Human approvals sit before sensitive actions. Evaluation thresholds influence release decisions. Logs record what happened.
FINMA’s Guidance 08/2024, published 18 December 2024, highlights model, data, IT, cyber, third-party, legal and reputational risks and expects supervised institutions to align governance and controls with the materiality of their AI use. That is a practical design brief. It implies that controls should vary with the use case rather than treating every application as equally risky.
A public-information drafting assistant and an agent operating on confidential client data should not move through the same path. The second needs tighter access, more constrained tools, stronger evaluation, explicit approval and deeper monitoring. Differentiated access is how a bank can protect sensitive work without forcing low-risk work through the heaviest process.
Operate a portfolio, not a queue
An operating system also needs transparent selection.
I would score opportunities across business impact, user value, strategic alignment, data readiness, technical feasibility, delivery effort, risk, reusability, adoption potential and time to value. The score is not a machine that makes the decision. It is a way to expose assumptions.
The most useful question is often not “which idea has the highest standalone value?” It is “which sequence creates value while making the next use case easier?”
A policy assistant may have a smaller headline than a complex client-service agent. But it can create a governed retrieval service, citation patterns, evaluation datasets and an operating model for knowledge ownership. Those components may unlock several later products.
This is why portfolio reviews need both business and platform views. A use case can earn priority because of its direct outcome, its reusable contribution or both.
Treat adoption as product work
Deployment is not the end state. A technically sound product can still fail because it sits outside the workflow, creates extra checking or arrives without clear expectations.
The product team should understand the current job before designing the AI layer. What triggers the work? Which systems are open? Where does judgement happen? What does good output look like? What would make a user distrust the result?
From there, adoption becomes concrete:
- involve representative users during discovery and evaluation;
- train by role and workflow, not by generic feature;
- establish local champions with a clear feedback route;
- measure active usage and task completion, not just licences;
- redesign the workflow where AI changes hand-offs;
- provide support and visible ownership after launch.
FINMA’s April 2025 survey of around 400 Swiss financial institutions found that around half were using AI or had initial applications in development, while many were still building governance and strategy. The move from availability to dependable institutional use is the real work.
Measure the system, not only the demo
Every use case needs an outcome baseline. Depending on the workflow, that could include preparation time, completion rate, quality, rework, user satisfaction, risk events or cost to serve. Measures should be agreed before launch and reviewed after users have had enough time to change behaviour.
The platform needs measures too: evaluation performance, latency, reliability, unit cost, component reuse, incident patterns and the time required to launch a new use case.
BCG’s “How to Get ROI from AI in the Finance Function” (4 June 2025) argues for value focus, collaboration and sequential scaling. I agree with the sequence. A bank should not scale because a pilot looked impressive. It should scale when the outcome, control environment and operating model are strong enough.
The decision after a release should be explicit: stop, improve or scale.
What this changes
An AI operating system gives executives a portfolio connected to strategy. It gives control functions visibility into how risk is managed. It gives product teams reusable capabilities. It gives users products designed around actual work. And it gives the institution a way to learn from each deployment rather than starting again.
This is not a promise of frictionless delivery. Regulated environments contain legitimate constraints, fragmented data and difficult dependencies. The point is to make those constraints part of a repeatable system.
The objective is not to maximise the number of AI experiments. It is to repeatedly turn the right opportunities into safe, adopted and measurable outcomes.
Three concrete takeaways
- Define a small set of business outcomes before building an AI portfolio.
- Deliver early use cases through reusable platform capabilities and embedded controls.
- Measure adoption and operational performance, then make a clear stop, improve or scale decision.
The views expressed here are personal and do not represent those of my current or previous employers.