The best AI use case is rarely the one with the most impressive demonstration.

In private banking, a compelling demo can hide weak data, a difficult integration, uncertain ownership or a workflow that users have no reason to change. A quieter use case can create more value because it solves a frequent problem, fits the control environment and produces components the bank can reuse.

Use-case selection is therefore a portfolio discipline. It should balance impact, feasibility, risk, data readiness, adoption and reusability.

Begin with the work

I start with the user and the workflow, not a list of AI capabilities.

Take relationship-manager meeting preparation. The problem is not “we need generative AI.” The problem might be that relevant information is spread across a CRM, portfolio views, recent interactions, product material and research. Preparation takes time, varies by person and can still miss important context.

That definition creates useful questions:

  • How often does the task happen?
  • Which users perform it?
  • What information is required?
  • Which sources are authoritative?
  • Where is professional judgement essential?
  • What does a good preparation pack contain?
  • How would we know that the new workflow is better?

The same applies in operations. “Email classification” sounds simple until the team examines multilingual messages, attachments, ambiguous ownership, service deadlines and the consequences of a wrong route. Discovery converts an abstract capability into a product problem.

Score across ten dimensions

I find a ten-part view useful:

  1. Business impact: does this change an outcome the institution values?
  2. User value: does it remove a real source of effort or improve a decision?
  3. Strategic alignment: does it support the bank’s priorities?
  4. Data readiness: are the required sources accessible, reliable and permitted?
  5. Technical feasibility: can the product meet the needed quality and latency?
  6. Delivery effort: what integrations, process changes and dependencies are involved?
  7. Risk: what can go wrong, and how material would that be?
  8. Reusability: which capabilities will another use case use?
  9. Adoption potential: will the product fit the workflow and earn trust?
  10. Time to value: how quickly can the team test the core assumption?

Scores should be treated as structured hypotheses. A “high data readiness” score needs evidence. A “high adoption potential” score should reflect user discovery, not optimism from the project team.

BCG’s “How to Get ROI from AI in the Finance Function” (4 June 2025) reports a gap between widespread AI activity and realised returns, and emphasises impact-led use cases and implementation discipline. The lesson for a private bank is straightforward: proof-of-concept volume is a poor portfolio objective.

Separate value from readiness

I like to plot use cases on two axes: weighted value and weighted readiness.

High-value, high-readiness opportunities are candidates to prioritise. High-value, low-readiness opportunities are strategic bets: they may justify data or platform investment, but should not be sold as quick wins. Low-value, high-readiness ideas can still be useful foundations if they create reusable components. Low-value, low-readiness ideas should usually stop.

Consider three illustrative cases.

A policy assistant may score moderately on direct financial impact, but high on data readiness, feasibility and reuse. It can establish governed retrieval, source citation, content ownership and evaluation patterns.

Automated meeting preparation may score high on user value and strategic alignment. Its readiness depends on CRM quality, portfolio-data access and agreement about the appropriate output.

A payment-workflow agent may have high potential impact but also high risk, integration effort and oversight requirements. It may be a later-stage use case after the bank has proven identity, tool permissions, approval and audit capabilities elsewhere.

Give reusability real weight

Reusability is often mentioned and then ignored when final priorities are set.

That is a mistake. The first use cases should help create the bank’s AI platform. A document-review product might produce an ingestion service, a classification component, an evaluation set, a human-review queue and an evidence trail. Those assets can support KYC preparation, operations intake, control-evidence preparation and research processing.

Reusability does not mean forcing every problem through the same interface. Domain applications still need specialist design. The reusable layer sits underneath: identity, retrieval, model access, orchestration, review, evaluation and monitoring.

A less glamorous use case can be the right first choice when it creates these capabilities safely. The portfolio should recognise that contribution explicitly.

Assess risk at the level of the action

“Generative AI” is not a useful risk classification by itself.

Risk depends on the data, user, context, output and action. Summarising an approved public report for an internal audience is different from drafting personalised client communication. Preparing evidence for a compliance review is different from deciding the review outcome. Suggesting a payment exception path is different from executing a payment.

FINMA’s Guidance 08/2024 describes a materiality-based approach to AI governance and highlights model, data, cyber, third-party, legal and reputational risks. A useful portfolio process converts those risk areas into design choices:

  • which data classification is involved;
  • whether output reaches a client;
  • whether the system recommends or executes;
  • what human approval is required;
  • which tools are permitted;
  • what must be logged;
  • how performance will be evaluated and monitored.

This allows low-risk work to move proportionately while reserving deeper control for sensitive uses.

Test the biggest uncertainty first

A first experiment should not attempt to prove the whole business case. It should test the assumption most likely to invalidate the use case.

For a knowledge assistant, the uncertainty may be whether authoritative content can be retrieved with sufficient precision. For meeting preparation, it may be whether the available data creates a genuinely useful brief. For triage, it may be classification quality across the long tail of cases. For an agent, it may be whether tool permissions can be constrained tightly enough.

The experiment should use a defined user group, approved data, a comparison baseline and manual review. It should produce a decision, not just a demo.

The Swiss Bankers Association’s “Generative AI in Banking — A Comprehensive Overview” (April 2025) stresses the importance of secure infrastructure, trusted data and appropriate governance in the banking context. Those conditions belong in experiment design from the start.

Include adoption before approval

Adoption potential is not a communication plan added after build.

If a product adds another screen, produces work that must be checked line by line or arrives without clear ownership, users will avoid it. If it fits the existing trigger, uses familiar information, shows its sources and makes review easy, adoption becomes more plausible.

Portfolio proposals should therefore include the user group, workflow change, training need, support model and adoption measure. “Available to 2,000 employees” is not an adoption metric. Active use, repeated use, task completion and user-reported value are better signals.

Review the portfolio as evidence changes

Weights are strategic choices. A bank focused on near-term efficiency may weight time to value and adoption highly. A bank building a differentiated advisory proposition may accept more effort for client and relationship-manager capabilities. A bank early in its platform journey may give extra weight to reusability.

The important point is transparency. Executives and delivery teams should see why an opportunity has priority, what evidence supports the score and which assumption could change it.

Use-case selection is not a one-off funnel. It is a recurring allocation decision. New evidence should move use cases, change their shape or stop them.

Three concrete takeaways

  1. Score opportunities across value, readiness, risk, adoption and reuse—not demonstration appeal.
  2. Test the assumption most likely to invalidate a use case before expanding the scope.
  3. Revisit the portfolio as evidence changes, and stop work that no longer earns its place.
The views expressed here are personal and do not represent those of my current or previous employers.