A bank's first AI portfolio usually records who won the internal argument rather than where the money is. One function has an enthusiast, that function collects six use cases, and everything else gets a placeholder. The portfolio designed in this engagement refuses that shape deliberately. Twelve use cases sit on the map, three in each of four business areas, and the slide carrying them is titled with two words doing real work: balanced execution.
A consumer and SME banking group operating across several European markets ran an executive workshop deliverable through operating model design and came out with a named portfolio. The four areas are retail banking, SME banking, risk and compliance, and operations. Each is given an embedded AI lead plus squads, and each is given exactly three cases. Retail takes a personalisation engine, a service chatbot and churn prediction. SME takes credit underwriting, cash flow forecasting and document processing. Risk and compliance takes fraud and anti-money-laundering detection, regulatory reporting and model validation. Operations takes process automation, intelligent document processing and workforce optimisation.
The challenge
The portfolio sits downstream of an operating model choice the deck makes in the open. Four options were rated against four criteria, with a one-line reason written into every cell rather than a bare score. A fully central function rates highest on control and lowest on scalability and business alignment, and the reason written against that last cell is an ivory tower. Full federation inverts it: highest on business alignment, because the work sits inside the profit and loss line, and lowest on control, where the reason written is shadow AI. Hub and spoke and the hybrid variant both clear high on all four criteria, and the hybrid's only real edge is scalability, rated very high against high on the strength of platform-led scaling.
The recommendation was the hybrid: a lean central function owning platform, governance and standards, with embedded AI leads inside the business driving delivery. Target-state staffing is written as sixty per cent embedded, forty per cent central. That ratio is a design target rather than a headcount anyone had hired.
Both named failure modes are distribution failures, and that is the part worth carrying away. The ivory tower is a portfolio drawn entirely by the centre. Shadow AI is a portfolio drawn entirely by whoever had budget. Any operating model sitting between them needs a rule about how work spreads, and the twelve-case map is that rule made visible before anyone can argue about it use case by use case.
The approach
The map does three things at once, and only the first is obvious.
It caps ownership. No single function can point at the programme and call it theirs, because no single function holds more than a quarter of it. In a bank where the AI conversation is usually pulled toward credit risk by gravity alone, writing three cases into operations and three into retail is a decision that has to be defended once, at design time, instead of relitigated every quarter.
It spreads failure risk. Three cases in one area can all fail for the same reason, because they share data, a system of record and a sponsor. Twelve cases across four areas fail independently, or at least fail for four different reasons. A programme that concentrates its portfolio also concentrates its evidence, and a board that funded one area and got nothing back has no second reading to compare against.
And it forces the platform to be genuinely reusable. This is the least discussed and the most expensive of the three. A hub building for one spoke builds that spoke's stack. A hub building for underwriting, fraud detection, churn scoring and document processing simultaneously has to abstract, because those four workloads have almost nothing in common except the controls around them. The hub in this design holds exactly three shared assets: a common platform, model risk, and a talent academy. Three at the centre, twelve at the edge.
That reuse is where the money argument sits, and the deck argues it with somebody else's evidence. A peer benchmark inside the deliverable reports a thirty to fifty per cent reduction in lead time from idea to production at other banks that centralised their platform first, and the design leans on that reading to justify a funding rule of its own: ringfence forty per cent of the budget for the central team to build reusable assets, not governance alone. The funding rule is the design's. The range is not. It is a figure observed elsewhere and quoted as rationale, and this bank had no lead time of its own to set beside it, because nothing had been built.
Decision rights are written down rather than implied, and the split is symmetrical. The hub decides platform architecture, security standards, model governance policy and vendor selection. The spoke decides use case prioritisation, product features, user experience and business adoption. Four items each. Data scientists report to the business on a solid line and align to the hub for standards on a dotted one. Quarterly business reviews align the hub's platform roadmap against what the spokes need delivered.
The rollout designed behind all of this runs twenty-four weeks in three phases. The first four weeks appoint a head of AI for the hub and business AI leads for the spokes, charter the oversight committee, settle the risk-tiering policy the AI Act obligations will be tested against, and select the top three cases to start. Weeks five to twelve stand up a platform of model registry, feature store and a basic pipeline, run two or three pilots, and gate them with manual controls. Weeks thirteen to twenty-four turn those manual gates into policy checks inside the deployment pipeline, launch communities of practice, and move pilots into production.
The outcome
Read the plan and the map together and a tension shows up that the design is honest about. Twelve cases are on the map; three are selected to start. The even distribution is a property of the portfolio, not of the first budget cycle.
That is the right way round, and it is why the map is a governance artefact rather than a delivery plan. The map sets what the programme is allowed to become. The quarterly review decides what gets money next, and it is explicitly designed to reallocate funding on value realised rather than value promised, approving the next quarter's priorities as it goes. Even distribution is the starting position, not a permanent allocation. It exists so that when the review does concentrate spending, it concentrates on evidence from four areas rather than on the only area anyone was ever allowed to try.
What this engagement produced is a designed portfolio, an operating model recommendation with a staffing ratio, a written split of decision rights, a phased rollout and a funding rhythm. No pilot had run. The platform did not exist. The reuse figure belongs to other banks, the staffing ratio is what the plan targets, and the twelve cases are what the plan permits. Anyone reading a number here as an achieved result is reading a design document as a report.
The habit worth stealing is smaller than the deliverable. Before the first use case is argued, decide how many each business area gets. Four areas, three each, is not a magic ratio and the deck does not claim it is. What it is, is a constraint chosen ahead of the enthusiasm, which is the only time such a constraint can be chosen honestly. Our Consult engagements now open with that question rather than with a long list, because the list is easy and the distribution rule is the thing nobody wants to be the one to propose.