The model is the easy part
Trace failed enterprise AI projects back to their first crack and it's almost never the model. The difficulty moved — spend your early weeks where it went.
Do the autopsy on enough dead AI projects and you stop finding the body where the pitch deck said it would be. The deck always blamed the model — not accurate enough, hallucinated, the vendor oversold it. But trace the collapse back to the first load-bearing crack and the model is rarely where it started. The model was fine. The three things around the model 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 where the remaining difficulty lives. Ten years ago, getting a model that worked at all was the hard, uncertain, differentiating part, and everything else was plumbing. Foundation models flipped that. Today you can stand up a system 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, an evaluation trail that holds up under scrutiny, or a room full of experienced operators who will change how they work because of your tool.
The model is the easy part now — not because modeling is trivial, but because the difficulty drained out of it and pooled everywhere else.
The three places the difficulty pooled
Trust. In a serious enterprise, "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 afterward? A slightly less accurate model that produces a defensible reason for every output will clear review while a better black box sits in a committee queue for two quarters. Trust is not a launch communication. It's an architectural property — explainability, evaluation, controls — that you either build in or spend the rest of the project pretending to have.
Data. The demo runs on a clean extract someone pulled by hand. Production runs on the actual warehouse — where the same 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 sits behind an access boundary that takes ninety days to cross. Nearly every "the model degraded in production" story turns out, on inspection, to be a data story that got blamed on the model.
Adoption. If the people it was built for don't use it, the model doesn't exist — not "underperforms," doesn't exist, as far as any business outcome is concerned. This one is large enough that I wrote about it separately ("If they don't use it, it doesn't exist"); here it earns its place on the list because it's the constraint you can least engineer from your desk, and the one most confidently scheduled for "month three, change management."
If the project plan front-loads model selection and back-loads data readiness and adoption as workstreams that start later, the plan has inverted the actual risk. It is spending the team's best, earliest, most attention-rich weeks on the part most likely to already be fine.
What this does to sequencing
Sequence the work against the risk, not against what's exciting. The instinct — model first, because it feels like the real work — 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. | Walk the data backwards from that decision to its sources — before modeling. |
| Write the evaluation story at the end. | Write the eval first; it's the spec. |
| Roll out, then manage change. | Ship into a workflow you already validated someone wants. |
Concretely: before anyone benchmarks a model, get one user to commit that a specific output would change a specific decision — and watch them work through a paper version. Then trace the data that decision needs, hop by hop, and find out who owns each hop. The model comes last not because it matters least, but because it's the step with the least uncertainty left in it once the other three are honest.
None of this is bad news. The model being the easy part means the hard, differentiated work of enterprise AI is exactly what a good product organization is built to do: understand a user well enough to change their behavior, and understand a system well enough to trust its outputs. That work was always going to decide whether you shipped. The model just stopped hiding it.
If you take one thing: the model is the part of the project with the least uncertainty left in it. Spend your first weeks where the variance actually is.