Designing an AI operating model for a nationwide commercial bank
Two versions of a programme design for a large commercial bank: skills, process architecture and joint development. What the second version removed matters most. Proposal stage: we claim no contract and no deployment.
Context
This case describes a programme design we prepared, as a proposal, for a large commercial bank with a nationwide branch network. Its staff work in a cloud office suite, so the design relies on that suite's AI assistant and scripting layer instead of new tooling. It sets out who learns what, where process work starts, what gets built jointly, and under which controls.
The challenge
We started from three hypotheses. An adoption gap: the tools keep improving, but use by non-technical staff stalls. Operational friction: hours lost to manual reports, email triage and repetitive tasks. Generic AI: off-the-shelf assistants do not resolve problems that sit in the bank's own workflows.
None of these was validated inside the bank; we had seen no process documentation, usage data or security policy. So the real challenge was ours: a programme credible to a regulated institution, for staff at very different levels of responsibility, that promises nothing only a discovery can establish.
Our approach
The design went through two versions, about five weeks apart. The difference between them is the useful part of this case.
- 1Draft a first versionThree phases (discovery, a controlled pilot with business-banking executives, national rollout), three use cases, a platform hub and a return calculator.
- 2Test it against what we did not knowIt promised core-system and CRM integration and very low latency before any discovery. Indefensible to a bank's IT team without system access, so it came out.
- 3Rebuild around three dimensionsCapabilities, operating architecture and joint development, with an academy by level and a security section, closing on one principle: listen first. No price, scope list or rollout phases.
- 4Prototype the demonstrationA scripted simulation: three plain-language prompts to the suite's AI assistant assemble a workflow across mail, spreadsheets, documents and slides. All data is fictional.
What was designed
Three dimensions of the operating model
- Capabilities. Everyone trained to use AI in the tools the bank already runs, starting from their own tasks.
- Operating architecture. Process analysis to find systemic friction and bottlenecks, and to apply AI where the operation actually runs.
- Joint development. Internal and customer-facing solutions built by both teams, drawing on the bank's data and both sides' experience.
Discovery with conversational agents
The design pairs personal interviews with BizMRI, our interview product, in invite-only beta. An agent interviews many employees in parallel: a person's role, the repetitive task that takes most of their time, then that task reframed as a candidate use case. A three-week plan, drafted in the design files but displayed in neither version, ends in a friction map, a use-case shortlist and a tailored playbook. The design text said the agent could interview a whole workforce in under an hour. We have not evidenced that capacity at a bank's scale, and it says nothing about how people respond to an invitation.
A portfolio of candidate automations
The first version named three candidates: extraction from PDF financial statements to draft credit-risk reports; an assistant suggesting replies to account officers from client history and the product catalogue; and analysis of bylaws and powers of attorney to speed up corporate account opening. The second showed one instead: a customer-feedback pipeline across app, branch, contact centre and corporate banking, as a mock dashboard. These are candidates, not a backlog. Selection belongs to discovery.
The demonstration takes another route: automation assembled by non-technical staff. In the scripted scenario, credit-approval requests emailed by branches become tracker rows, approval documents, PDF replies and a self-updating summary deck.
An academy in four tracks
Training is stratified by responsibility: governance and strategic narrative for the C-level; operating-flow design and change leadership for vice-presidents; orchestration of mixed human and AI teams for managers; advanced prompting and personal automation for operational staff. Eight touchpoints surround the tracks, among them three biweekly workshops, an asset library transferred to the bank's servers, a semi-annual adoption survey and a final impact report to inform any decision to scale.
Results
Default inputs of the design's capacity calculator in its two versions. No baseline was measured at the bank; a discovery would replace it.
Planned duration in the draft discovery plan, which neither version displayed. A plan, not a record of work carried out.
Three in the first version, one in the second. None was selected, built or tested.
This case has no outcome figures. What exists is a set of design artefacts: two versions of the programme structure, a scripted demonstration, a draft discovery plan, an academy specification and a security section. Nothing was built against the bank's data, and we claim no change to any process there. Mock screens carried illustrative values, one left over from an earlier design; none of that is evidence.
The more useful result is what the second version removed. The first priced recovered hours at an hourly cost and drew an adoption curve approaching full use within six months. Neither had a baseline, and both went. The second keeps a calculator in hours and full-time equivalents, with adjustable assumptions. We do not reproduce its output: a default slider position is not a forecast for this bank, and four to six hours a week is a planning input, not a finding.
Governance and risk
The security section commits to fitting the bank's information-security policies, to using no client data to train public models, to end-to-end encryption, and to on-premise or private-cloud deployment where the bank requires it. These are commitments on a page; none was tested against the bank's controls. The draft wording also overreached: it promised strict compliance with local regulation and referred loosely to certifications. Alignment with a regulator's directives is control-by-control work with the bank's own teams, and we cite no certification whose certificate and scope we cannot hand over.
Our position on a first implementation in any bank: internal, assistive and narrow. Decisions that affect customers, money, eligibility or regulated controls stay with accountable people. The first version described the credit candidate as risk reports in seconds, which skips the control that matters. Framed properly, the agent extracts and drafts, an analyst reviews, and the credit decision is untouched.
Staff-built automation raises a question the design leaves open: who reviews a script that reads a shared mailbox and sends documents on the bank's behalf? Without an answer, self-service automation becomes shadow IT with better tooling. An inventory, a review step and limits on what scripts may touch belong in the first session with IT security, before anyone is trained to build.
What we learned
- Remove every promise that only a discovery can establish. Integration, latency and rollout phases promised before system access cost credibility with a bank's IT team.
- Show capacity as adjustable inputs in hours, never as money without a baseline. A calculator default is not a forecast, so we do not publish its output.
- Train staff to automate only after IT security has agreed who reviews their scripts, where they are inventoried and what data they may touch.
Client identity, locations and identifying details are withheld under confidentiality. Figures are rounded. Measured figures come from engagement records; client-reported figures are attributed, not audited; modelled figures are projections from the engagement's business case and are labelled as such.