The model is the easy part
Every AI initiative I've seen fail in financial services failed on trust, data, or adoption — never on model quality. What that means for how you sequence the work.
Do the autopsy on enough dead AI projects and you stop finding a body at the scene you expected. The pitch decks always blamed the model — not accurate enough, hallucinated, "the vendor oversold it." But when you actually trace the collapse back to its first load-bearing crack, the model is almost never where it started. The model was fine. It was the three things around the model that were never resourced like they mattered: trust, data, and adoption.
This isn't a claim that models don't matter. It's a claim about marginal effort. The center of gravity in this field has moved. Ten years ago, getting a model that worked at all was the hard, uncertain, differentiating part of the job, and everything else was plumbing. Foundation models and cheap adaptation flipped that. Today you can stand up something that classifies, drafts, or scores at a usable bar in an afternoon. What you cannot stand up in an afternoon is a data pipeline your risk function will sign off on, a documentation trail an examiner will accept, or a room full of underwriters who will actually change how they work because of your tool.
So the model is the easy part now — not because modeling is trivial, but because the difficulty has drained out of it and pooled everywhere else.
The three places difficulty pooled
Trust. In a regulated environment, "the model is 94% accurate" is the beginning of a conversation, not the end of one. Someone will ask: accurate on which population? Wrong in which direction? What happens to a customer when it's wrong, and can we explain that decision after the fact? A model that is slightly less accurate but produces a defensible reason for every output will clear governance while a better black box sits in a committee queue for two quarters. Trust is not a communications problem you solve at launch. It's an architectural property you either build in or spend the rest of the project pretending you have.
Data. The demo runs on a clean extract someone pulled by hand. Production runs on the actual warehouse — where the field means three different things depending on which system wrote it, the historical labels encode a decision process you're no longer allowed to use, and the record you most need is the one behind an access boundary you can't cross without a data-sharing agreement and ninety days. Nearly every "the model degraded in production" story is a data-lineage story wearing a model's clothes.
Adoption. If the producers don't use it, the model doesn't exist. Not "underperforms" — doesn't exist, as far as any P&L is concerned. An underwriter who quietly keeps doing it the old way, an adjuster who overrides every suggestion, a relationship manager who never opens the tab: each is a complete failure wearing the costume of a successful deployment. Adoption is where the most confident projects go to die, because it's the one constraint you can't engineer around from your desk.
If your project plan front-loads model selection and back-loads "change management" and "data readiness" as workstreams that start in month three, you have inverted the actual risk. You are spending your best, earliest, most-attention-rich weeks on the part most likely to already be fine.
What this does to sequencing
The practical consequence is that you should sequence the work against the risk, not against the org chart. The instinct — model first, because it feels like the real work and it's the part your engineers are excited about — puts your scarcest resource, early attention, on the lowest-variance problem. Invert it.
| Instinctive order | Risk-first order |
|---|---|
| Pick and tune the model. | Prove one real user will change one real decision because of the output. |
| Wire up production data. | Trace the exact data lineage and access reality for that decision — before modeling. |
| Build the governance/explainability story. | Fix the explainability and control surface as a design constraint, not a deliverable. |
| "Roll out" and manage change. | Ship the model into the workflow you already validated a human wants. |
Concretely: before anyone benchmarks a model, get one producer to commit that a specific output would change a specific decision they make — and watch them use a paper prototype of it. If they wouldn't act on a perfect answer, a real one won't save you, and you've learned it in week one instead of after a nine-month build. Then, before modeling, walk the data backwards from that decision to its source systems and find out who owns each hop and what it will actually take to use it. The model comes last not because it's least important, but because it's the step with the least uncertainty left in it once the other three are honest.
None of this is a counsel of despair about models. It's the opposite. The model being the easy part is good news: it means the hard, differentiated, defensible work of building AI in financial services is exactly the work a good product organization is built to do — understanding a user well enough to change their behavior, and understanding a system well enough to trust its outputs. That work was always going to decide whether you shipped. The model just stopped being the thing that hid it from you.
If you take one thing: the model is the part of an AI project with the least uncertainty left in it. Spend your first weeks where the variance actually is.