Put AI investment through the same diligence as every other capital decision

Every vendor deck and internal champion has reason to round up: pilots get reported as wins, and “AI-powered” gets attached to outcomes it didn't drive. The anchor that holds under scrutiny is the public record — what a peer bank, or the vendor it named, has stated openly, with a number where one exists. And silence is not absence: a benefit no one has disclosed is recorded as missing evidence, never as proof the value isn't real.

The read has two parts:

What counts is weighted by how well it's disclosed: a realized benefit over a planned one, a quantified figure over a directional phrase, a named primary source over a passing mention, a bank-wide outcome over a single anecdote.

The most broadly evidenced of the six sample use cases, scoring 85 against a register of 111 disclosed benefit claims across the cohort. Its evidence concentrates in labor saved and forecasts that reach further, across four major U.S. deployments — Bank of America's CashPro, JPMorgan's Cash Flow Intelligence, PNC's PINACLE, and Citi's Cashforce / TIS. The 85 says its value is the best documented — not that it is the most valuable bet a given bank could make.

A well-evidenced use case can still be costly to run safely. The next three sections read those costs — beginning with regulatory intensity.

The instinct is to count the laws on the books, or to assume the most advanced AI draws the most scrutiny. Both mislead. Regulatory weight is set by the specific characteristics of each use case: what the workflow does with its outputs, which obligations that workflow actually triggers, and how the exposure enforces. The sharpest single line is whether the system reaches decisions about people — their credit, their eligibility, their treatment — but it is one line among several.

For each use case, the framework builds a regulatory surface by asking three things of all 31 instruments — nine regulatory domains, four jurisdictions, anchored on the 14 U.S. instruments:

Relevance is scored separately from severity. Keeping the two apart stops a heavy-penalty law a use case barely touches from masquerading as a central obligation — the most common way regulatory heat maps mislead.

The lightest regulatory profile of the six sample use cases, at 49 — and lighter in kind, not only in degree. Because it produces analysis rather than decisions about people, consumer-protection, fair-lending, and the state AI statutes read as Not relevant. What remains concentrates in three supervisory regimes — third-party risk, model risk (SR 26-2), and tech governance — and runs through examination, not statute.

Knowing which rules bite is one cost; running and governing the system that satisfies them is another — and it is permanent.

This is the question most business cases under-price: what does it cost to run and govern this system, day after day — and where in the bank does that cost land? The build is the cheap part. Running is continuous and cross-functional — drawing steadily on model risk, data operations, and governance — and it is where evidenced value erodes when the intensity was never priced in. That burden is unevenly distributed, often shaped by what regulation and the technology demand rather than freely chosen; knowing where it concentrates is what lets a bank budget for it rather than discover it after the system is live.

The framework characterizes how a system is actually built, run, and governed across 14 operating-model categories in four layers:

Banks rarely publish their full operating model — so this is where the labeled-inference method does its heaviest work. Each category is read from the public record first; where the record stops, one labeled inference completes it, so a reader can see exactly where disclosure ends and inference begins.

The lightest operating profile of the six, at 56 — but “light overall” hides where the weight sits. Most of its run-and-govern choices sit at the cohort floor; the intensity concentrates in one category — data sourcing, the multi-source integration across client ERP systems, external bank accounts, and internal systems that the forecasts depend on — with model validation and data privacy shaped by regulation rather than choice. Even a light use case carries a specific, locatable burden, and the value of the read is knowing where it sits before the system is live.

Running the system is one cost; the difficulty of building it in the first place is another. The final section reads technical complexity.

The temptation is to read “AI complexity” as a single dial: the more advanced the model, the harder the build. It doesn't hold. For a great deal of banking AI the model is the cheapest part — the real cost sits in the data pipeline that feeds it, or in the systems of record it has to integrate with. The framework decomposes build difficulty into its sources, reading three components:

The read records not only what a system uses but what it notably does not — the absence of large language models, graph networks, or unstructured data is part of the profile, and recording it stops a conventional system from being scored as if it were frontier.

The lightest build of the six, at 40 — and the decomposition shows why. Its disclosed AI is conventional and mature — ensemble methods, time-series forecasting, scenario simulation — on a narrow, two-modality data layer. What complexity exists lives almost entirely in the integration: multi-bank ingestion, ERP, and treasury management systems — few system classes, each a system of record that tolerates no error. The weight sits in the plumbing, not the model — the same picture the operating read showed.

That completes the read: value, set against the three costs of realizing it. Placed on common terms, the well-evidenced, light-to-run cases earn capital first — and the ones whose value is outweighed by the cost of building, running, and governing them can wait, on evidence rather than instinct. Producing that placement is what the framework is for.