This article is provided for general information and does not constitute legal or regulatory advice. It reflects publicly available sources as at the date of publication. Regulatory expectations and timelines change; confirm your own position with your compliance function and the relevant authority.
Almost any bank, insurer or payments business can now produce an impressive AI demonstration in a fortnight. Far fewer can put one in front of customers within a quarter. The gap between those two facts is the actual subject of most AI programs in financial services, and it is not a gap in model quality.
AI in finance works when it improves a defined workflow inside a controlled operating model. It stalls when a team starts from the model, treats data and integration as preconditions rather than as the project, or leaves accountability to be assigned after the technology decision is made. Those three failures account for most stalled AI adoption in financial services, and none of them is a modeling problem.
What follows is that pattern in detail - the conditions under which these systems hold, and the ones under which they reliably stop - drawn from engineering work across the banking sector, insurance and payments.
A use case that survives contact with production has four things you can point at: a clear input, a named user, a defined action and a review point. The candidates that consistently meet that test are unglamorous:
Helping staff retrieve policy and product information, with citations;
Extracting structured fields from submitted documents;
Ranking cases or alerts for human review;
Summarizing a customer file with links to the source records;
Surfacing unusual patterns for investigation; and
Drafting customer communications for a person to approve before sending.
The first of those is the most common entry point, and it is the shape behind an enterprise AI assistant: retrieval over approved internal sources, answers that cite where they came from, and a person who remains responsible for what happens next.
What those have in common is that a human stays in the decision and the system's job is to collapse the time that person spends assembling context. That framing also sets the cost of being wrong at something the institution can absorb. As the outcome becomes more material - pricing, eligibility, anything the customer experiences directly - the control and evidence requirements rise steeply, and the sensible sequence is to earn that ground rather than start on it.
Performance in production depends far more on the data around the model than on the choice of model, and the blockers are strikingly consistent across institutions:
Identifiers that do not reconcile across systems;
Documents with no owner and no review date;
Access rules that exist in the source system but do not carry into retrieval;
Sensitive data copied into environments with weaker controls;
No process for correcting or withdrawing a source once it proves wrong; and
No measured baseline for the manual workflow the system is meant to improve.
The quiet killer, though, is the missing baseline. If nobody measured how long the manual process takes today, how often it produces an error, or how many cases it leaves unresolved, then the pilot cannot demonstrate improvement - only activity. Every business case built on top of that collapses at the first serious question from a finance director, and the team ends up arguing about model quality when the problem is that nothing was measured before the model arrived.
The practical move is to treat data readiness as a product requirement with its own budget, owner and acceptance criteria, rather than as an assumption the project is allowed to make. It is usually the longest item on the plan, and hiding it does not make it shorter - which is why our AI Consulting work starts with a readiness assessment rather than a model shortlist.
A benchmark question set is not an evaluation. The test set has to reproduce the conditions users actually face:
Incomplete applications;
Records that conflict between systems;
Customers with near-identical names;
Policies superseded but not withdrawn;
English and Chinese in the same case file - routine in Hong Kong;
Edge cases whose impact is out of proportion to their frequency; and
Requests the system should refuse or escalate rather than answer.