AI adoption in banking: which use case to actually start from

In short. In banking, the choice of a first AI use case is almost always made backwards, starting from the most visible process rather than the one with the best ratio of value to regulatory friction. The cases generating quick value are internal ones, where risk stays low and no authority asks about the model. The cases that move the P&L sit in credit, and that path is long because it runs through Annex III.

The question that comes up most often is where to start rather than whether to use AI, and in a bank that question carries an extra constraint: some processes are already covered by validated models, within a governance framework AI has to respect rather than bypass.

Two curves that don't line up

Assessing a banking use case takes two separate measures, and conflating them is the error that stretches projects out.

The first is expected economic value, which in most banks concentrates in credit, fraud prevention and back-office efficiency. The second is regulatory friction, meaning how much governance work is needed before the system can go into production.

The two curves don't line up. The highest-value use case, credit scoring, also carries the highest friction, because it falls under Annex III with obligations on data, technical documentation and human oversight. The lowest-friction case, internal search across documentation and regulation, has real value that is hard to put on the balance sheet.

Where those who reach production actually start

In the paths that work, the first use case is rarely the strategic one. It's an internal case, chosen because it lets the method get built while risk stays contained.

Use case	Value	Regulatory friction	Suitable as first
Search across regulation and internal procedures	Medium, in time saved	Low	Yes
Summarising files and loan documentation	High in efficiency	Medium, customer data	Yes, with attention to data
Support for the commercial network	Medium	Low, Article 50	Yes
Fraud and anti-money laundering	High	Medium, depends on effect on the individual	As a second step
Credit scoring	The highest	The highest, Annex III	No, not as a first
Customer-facing chatbot	Medium	Low, transparency obligations	Yes, if the scope is closed

The surprising column is the third. Many banks choose to start from the customer-facing chatbot because it looks most visible, then discover that the hard part is the boundary of what the assistant may say, not the model.

What separates a pilot from a project

A pilot is worth running if it produces a decision rather than a demo. That difference gets established before starting, by defining three elements that must exist in writing.

The first is the measured baseline of the current process: how long it takes, how many errors it produces, what it costs. Without that number the pilot is comparable to nothing and closes on an impression.

The second is the acceptance criteria, set before seeing any results. Written afterwards, they accommodate any outcome.

The third is the exit path, meaning what happens if the pilot works. A pilot without an industrialisation plan stays a pilot, and in a bank it can stay one for years, because moving to production requires integrations, controls and documentation nobody budgeted for.

Why credit comes later, and that isn't a retreat

Deferring credit scoring doesn't mean giving up the value, it means sequencing the work. Annex III obligations for high-risk systems apply from 2 December 2027 following the Digital Omnibus postponement, and that window exists to build what will then be required: data traceability, technical documentation, human oversight designed in rather than added on.

There's a practical reason too. Anyone touching credit scoring with fine-tuning on proprietary data may fall among providers under Article 25 of the AI Act, taking on the obligations in Article 16. That decision is better made knowingly than discovered mid-project.

In the meantime, internal cases build exactly the capabilities that will be needed: inventory, risk assessment, verified competence, a release process.

The most expensive mistake

The most frequent one isn't picking the wrong case, it's picking the right case with no owner. An AI system in production needs a named person accountable for the decisions it produces, and in a bank that person sits in the business function, not in IT.

When ownership stays with IT, the system gets maintained but not governed: nobody decides when it's outside its validity range, nobody notices drift, and the control exists on paper.

Where to start

The sequence that works begins with the AI system inventory, because in almost every bank something is already in use, often inside software bought years ago. From there you build the map of candidate cases across the two curves, value and friction, and pick the first from the bottom left rather than the top right.

The selection criteria in detail are in AI adoption: how to choose your first use case, and the cost model from pilot to production in AI project budgeting.

The sector's full regulatory picture is on the AI governance for banks and financial services page.

To work out which use cases make sense in your bank, you can book an assessment meeting.