The Short Answer
Adobe and Incisiv surveyed 528 financial services executives and found only 15 of every 100 proposed AI use cases reach production. The 85% stall on architecture, not models: no live system-of-record access, governance bolted on at the application layer, and vendor lock-in with no exit. ibl.ai closes all three — you own all the code and the data, self-hosted, model-agnostic, with spend limits enforced server-side.
The number that should concern a banking CTO is not that 85% of AI use cases fail. It is that 85% never get deployed at all. They die between a working proof-of-concept and a production system, which means the model was usually fine. What was missing sat underneath it.
What did the Adobe and Incisiv survey actually find?
Adobe and Incisiv surveyed 528 financial services executives about AI adoption. Three findings from that survey define the problem:
- 15 of every 100 proposed AI use cases reach production. Not 15% deliver ROI — 15% get deployed at all.
- 60% are stuck in what the report calls the "Frozen Middle" — piloting or deploying, but unable to scale past it.
- 14% measure ROI comprehensively. Most institutions cannot say with confidence which of the first two buckets they are in.
That third number reframes the first two.
An industry where roughly one in seven organizations measures AI ROI properly is an industry making deployment decisions on impression rather than evidence.
The "Frozen Middle" is not only a scaling failure; it is partly a measurement failure, because a pilot with no instrumentation produces no case for the investment needed to productionize it.
What the survey does not do is explain why the 85% stall. The diagnosis below is ours, argued from what production financial services workloads actually require — not from the survey, which reports the gap without attributing a cause.
Why do banking AI pilots stall between proof-of-concept and production?
Because a banking AI pilot and a banking AI production system are not the same class of system, and the pilot is usually built as though they were.
A pilot runs on exported or sample data, answers questions in isolation, and is judged on whether the output reads well.
A production system in a regulated institution has to reason over live client data, current compliance state, real transaction history and active regulatory requirements simultaneously — and it has to do it without extracting that data from the systems that own it.
The distance between those two things is not model quality.
It is three layers that a demo never needs and a production deployment cannot ship without: live access to the systems of record, governance that the model cannot route around, and ownership terms that survive a vendor's next pricing decision.
Each is examined below.
What does system-of-record integration require in a bank?
It requires reading from the systems in place, rather than copying out of them.
Most banking AI proofs-of-concept operate on a data export.
That is why they demo well and productionize badly: the export is a snapshot, and a bank's answer changes with the transaction that cleared this morning.
An AI agent that answers from last quarter's extract is not slightly less accurate than one reading the core banking system — it is answering a different question.
Production requires read-only, role-scoped access to CRM, core banking, compliance and trading systems in place.
No ETL pipeline creating a stale copy. No data lake that becomes its own compliance surface.
Increasingly this is built on the Model Context Protocol, an open standard for giving models structured access to live systems, which matters here for a specific reason: an open protocol keeps the integration layer portable across model vendors, so the connector work survives a decision to switch models.
The compliance argument for reading in place is stronger than the accuracy one.
Every copy of client data is a new location to secure, audit and eventually delete.
A retrieval architecture that copies nothing has a materially smaller surface to defend when an examiner asks where the data went.
Why does AI governance have to live in the infrastructure, not the prompt?
Because a control the model can ignore is not a control, and a financial regulator will not accept one.
The 85% that stall typically govern at the application layer — system prompts, instructions, and the hope that the model complies.
That approach fails a supervisory examination for an obvious reason: it cannot be demonstrated.
"We told the model to be careful" produces no evidence.
Production banking AI needs four things enforced beneath the model:
- Spend controls at multiple scopes, with hard limits the model cannot raise. On the ibl.ai platform these run at three scopes — workspace, agent, and per-person-per-agent, each with its own reset interval, an enforcement mode that blocks or alerts, and near-limit thresholds. Enforcement is server-side, so a blocked request fails for every client — which is the whole point. A limit enforced in the client is a limit that a different client does not have.
- Complete audit trails of every interaction, data access and decision, exportable in the formats examiners expect.
- Role-based access control tied to the institution's existing identity provider. A compliance officer and a retail banker should not inherit the same agent capabilities.
- Model-level routing that keeps sensitive queries away from external APIs — which is only possible if the platform is model-agnostic to begin with.
Governance also has to be observable, not just enforced.
The platform-scoped LLM usage analytics API shipped in August reports cost, tokens and latency percentiles from p50 to p99, grouped by model, agent and user, and drills down to per-session traces.
That is the same standard of instrumentation a bank already applies to a trading system — and it is what the 14%-measure-ROI figure says most institutions do not yet have.
Our 90-day AI governance framework for banks sets out the sequencing in more detail.
What does per-seat AI licensing cost a 5,000-person bank?
Enough that the pricing shape, not the price, becomes the deciding factor.
Per-seat AI licensing in financial services runs roughly $40–$60 per user per month at enterprise tiers. That bill scales with headcount whether or not the seats are used:
| Model | Per user / month | 5,000 people / year | What the bill tracks |
|---|---|---|---|
| Per-seat AI suite (lower tier) | $40 | $2,400,000 | Headcount |
| Per-seat AI suite (enterprise tier) | $60 | $3,600,000 | Headcount |
| ibl.ai (self-hosted, usage-based) | — | Tokens actually consumed | Usage |
The point is not that $3.6M is a large number for an institution of that size.
It is that the number is disconnected from use.
A bank where 800 people use AI daily and 4,200 opened it twice pays for 5,000 either way.
Usage-based pricing makes the bill a function of work performed, which is the only shape that lets a CFO reason about AI spend the way they reason about any other compute line.
We work through the arithmetic in full in the per-seat versus usage cost math for financial services.
Ownership changes the accounting as well as the total. Infrastructure an institution owns and runs is a capital asset it can capitalize; a subscription is an operating expense that recurs forever and buys no equity in the thing it pays for.
What do the 15% that reach production do differently?
They make three decisions before selecting a model, not after.
- They build the data and governance layers first. The model is the last and most replaceable component. An institution that has solved live, role-scoped access to its systems of record can adopt a better model in an afternoon; one that has only chosen a model has solved the easy part.
- They require infrastructure-level controls rather than application-level guardrails. The test is simple: can the model, or a differently-configured client, get around this control? If yes, it will not survive an examination.
- They demand ownership of code, data and deployment. Three questions decide it — who owns the code if the vendor reprices or is acquired; where does client data physically live; and can we change models without rewriting the integrations.
None of those three is a machine learning problem.
They are architecture and procurement problems, which is why the failure rate is stable across institutions of very different technical sophistication.
Our reference architecture for financial services AI lays out how the layers fit together.
How does ibl.ai close the production gap for financial services?
By making all three gaps structural properties of the platform rather than features to configure.
You own all the code and the data. ibl.ai is deployed on the institution's own infrastructure with full source code access — managed cloud, private cloud, on-premise, GovCloud, or fully air-gapped for the most sensitive workloads. There is no third-party cloud in the path of client data unless the institution puts one there, and no vendor decision that can strand the deployment.
It is model-agnostic. Any LLM, swapped without rewriting integrations. That is what makes model-level routing — sensitive queries to a self-hosted open-weight model, general queries wherever is cheapest — an available option rather than a roadmap item.
Governance is enforced server-side. Spend limits at three scopes, RBAC tied to the existing identity provider, complete audit trails, and usage analytics with p50–p99 latency and cost drill-down by model, agent and user.
Pricing is usage-based. No per-seat licensing, so the bill tracks work performed rather than headcount.
ibl.ai is family-owned and operated from New York, NY — a U.S.-headquartered, domestically-owned long-term partner rather than a vendor selling licenses.
For regulated institutions weighing who will still be standing behind a deployment in five years, that is not a small consideration.
The 85% can still get to production. It requires treating AI as core infrastructure to own rather than a product to subscribe to — and sequencing the data layer, the governance layer and the ownership terms ahead of the model.
Survey figures are from the Adobe and Incisiv survey of 528 financial services executives; the "Frozen Middle" framing and the figures cited here were reported in Rich Turrin's analysis of the survey. See how ibl.ai deploys for regulated institutions at ibl.ai/solutions/financial-services.