Short answer
AI underwriting at a bank means one of two things. Document-reading AI identifies borrower files, extracts figures, builds the spread and drafts narrative, which removes clerical hours from a commercial credit file. Model-based decisioning AI takes structured inputs and returns an approval, decline or referral, which is where consumer and retail lending has used machine learning for years. Both are genuine, they are sold in identical language, and only the first is useful on a commercial borrower whose numbers exist only in documents.
AI underwriting is now the most crowded phrase in bank technology and one of the least precise. A vendor training custom credit models on a lender's consumer portfolio and a vendor reading a borrower's tax returns into a spread will both use it, and the two products have almost nothing in common except the buyer. This piece separates them, sets out how to read an availability claim in a category where almost nobody dates one, and describes what changes for a risk function once a model touches a credit file.
The two AI underwriting products
Document-reading AI is a clerical replacement. It identifies what each submitted file is, assigns it to an entity and a period, extracts the figures, populates a spread, calculates coverage, checks a policy document and drafts narrative. Its value is measured in analyst hours removed from a real file, and its risk is that a figure is read wrong and nobody notices.
Model-based decisioning AI is a judgment replacement, within tight bounds. It consumes structured inputs, applies a model trained on portfolio outcomes, and returns a decision with reason codes attached. Its value is measured in approval rates, loss rates and decision latency, and its risk is fair lending, model drift and explainability. Consumer and retail lending has run this way for years and does it well.
A commercial credit team needs the first kind and is frequently sold the second, because the second has more published material behind it and therefore more presence in AI search answers. The tell is where the numbers come from. If the model expects fields, somebody is still keying them.
How to read an availability claim
This category has a documentation problem that is worth naming plainly. Across the fifteen platforms this site covers, two named AI products carry a verifiable availability date. Everything else is written in the present tense with no shipped, generally available, beta or dated language anywhere near it, and in one case a feature advertised on a vendor's homepage has a product page that returns a 404.
That does not make the features fictional. It makes a business case built on them unenforceable. The remedy is procedural rather than technical: take the vendor's AI page, list every named feature, and ask for each to be marked generally available, in limited release, or planned, with a date, in writing. Vendors who will do that are telling you something, and so are the ones who will not.
- Generally available with a date: buy it, price it, hold the vendor to it
- Announced with no availability language: treat as roadmap, put it in the upside column
- Marketed on a homepage with a broken product page: raise it directly and watch the answer
- Capability-level AI language with no named product: there is nothing to evaluate
What an examiner actually asks
The question is not whether AI produced the number. It is where the number came from, who checked it, and what the file shows. A memo whose figures cannot be traced back to a borrower document creates review work rather than removing it, because the analyst has to reconstruct the trail by hand precisely when it is being asked for.
That is why traceability outranks accuracy in a regulated credit file. Vendor accuracy figures are self-measured and rarely published with methodology, which makes them weak evidence for anything. A product that links each spread line to its source page, records overrides, and shows who validated an extraction produces the artifact an examination needs as a by-product of how it works. That is worth more than a higher claimed accuracy with no trail behind it.
The documentation your risk function inherits
Anything that extracts, calculates or drafts becomes something the institution has to describe, validate and monitor. That is true whether the vendor calls it AI, automation or a rules engine, and it does not go away because the capability came bundled with a platform.
The practical questions are ownership questions. What does the vendor supply toward model documentation, what does the institution have to write itself, and what happens when the vendor changes the model mid-contract. The last of those is the one most often left unasked and most likely to matter: a model update the institution learns about after the fact is a monitoring gap, and the contract is the only place to fix it.
- A written description of what the model or extraction does and on what inputs
- Validation evidence, and whether the vendor or the institution produces it
- Ongoing monitoring: what is measured, how often, and who sees it
- Change notification: whether the institution is told before or after a model update
- An override and review record that shows a human checked the output
A reasonable way to buy it
Start from a file rather than from a capability. Take a real commercial credit that took too long, count where the hours went, and buy against the largest line. If the hours went to chasing and keying documents, that is document-reading AI and the evaluation is an extraction test on your ugliest file. If the hours went to standardized small-business applications sitting in a queue, that is decisioning, and the evaluation is about latency and approval rates.
Then price only what has shipped. Build the payback on the dated capability, keep the undated features in a separate column, and get a written not-to-exceed figure before committing staff time to a pilot. In a category where no vendor publishes a price and almost none dates a feature, discipline about both is the only real leverage a buyer has.
Frequently asked questions
Can AI approve a commercial loan?
In standardized small-business lending, automated decisioning within policy limits is common and has been for years. For relationship C&I and CRE credit, no, and the vendors worth buying from do not claim it. The credit decision stays with a person and a committee, and the useful question is how much clerical work the software removes before that decision is made.
What does agentic mean in this context?
That the software takes several steps toward a goal rather than answering one prompt: fetch a document, decide what it is, extract from it, check a policy rule, draft a section. It is a fair description of architecture and a poor basis for a purchase, because it says nothing about what the agent reads or whether the capability has shipped. Ask for the workflow and the date.
Is AI extraction accurate enough for tax returns?
Accurate enough to stop keying, not accurate enough to stop reviewing. Plan for analyst review of every AI-produced spread and choose on how easily that review can be evidenced: source links on each figure, an override record, and a visible trail of who validated what. Accuracy percentages without a published methodology should not move a decision.
Do consumer AI underwriting vendors work for business lending?
Not for the analysis. Several of the most confidently recommended AI underwriting vendors define their own market as consumer credit, and one names business lending exactly once, as a list item with no product page behind it. They are strong products for consumer and retail decisions, and none of them will spread a business borrower or produce a credit memo.