Why AI Pilots Stall in Life Sciences: It Is Never the Model

I was asked on Executive Insights for Life Sciences Innovators why so many AI projects stall after the pilot. Was the harder problem the model, redesigning the workflow, or the ownership and handoffs around it?

I told the host what it isn't. It is never the model.

That answer is less interesting than it sounds, because it is not a defence of any particular model. It is an observation about where the failure actually sits. Every model available to a commercial team today is good enough for the work those teams are trying to do. If the project died, something else killed it.

Three things, in my experience.

The workflow you picked

This one gets skipped, because choosing a workflow feels like the easy part before the real work starts. It is the decision that determines everything after it.

If you are solving a task, that is non-value added. A task is one step somebody performs. A workflow is how the work moves between people, including the waiting and the approvals in between. Automate a task and you make a step faster inside a process whose delay was somewhere else entirely. The demo works. The cycle time does not move. Nobody misses it when it is switched off.

The question worth asking before anything is built: when this workflow goes wrong today, what does it cost us? If that has no answer, the pilot has no way to prove anything, and a pilot that cannot prove anything is a pilot that stalls.

Whether whoever is solving it understands that workflow

There is a version of this that sounds like snobbery and is not what I mean. I do not think you need to have personally held the job. You do need to have studied it closely enough to know where the work actually breaks.

The failure I see most often in life sciences is a product built for another industry, now sold here, pointed at a workflow its builders have not studied. The mechanics look transferable from the outside. A lead is a lead, an account is an account, an outreach sequence is an outreach sequence.

Then it meets a market where the buyer is a scientist who will check the technical claim, where the trigger is a sponsor's programme moving rather than your quarter, and where a fabricated claim in an email is not an embarrassment but a liability. Understanding the workflow is the part that does not transfer between industries.

Adoption

The third is the one everyone nods at and nobody plans for. A workflow that a team does not use has failed, regardless of how well it performs in evaluation.

Adoption in a regulated commercial function is not a training problem. It is a trust problem, and trust is built by letting people inspect the work. I later tested what four models do when they are asked something the internet does not know, and one of them named a manufacturer seven times out of ten for companies that have never disclosed one. If a rep cannot see why the system suggested what it suggested, cannot follow the claim back to a source, and cannot decline it without breaking something, they will route around it. Reasonably.

Why pricing is not on the list

I left pricing out deliberately, and I was asked about it.

If the workflow is right and the team adopts it, the return is there. The budget conversation gets easier every quarter rather than harder. When a project dies over price, price is usually the reason given rather than the reason. Something upstream had already failed, and the renewal was where it surfaced.

That is worth knowing if you are the one preparing the business case, because the instinct is to solve for the number. The number follows the other three.

The data question underneath all of it

The host raised garbage in, garbage out. My answer was that with AI it is just garbage out at an accelerated rate.

This is the part teams most want to skip, because getting data ready is unglamorous and it delays the interesting work. It is not the step before the work. It is the work. A system reasoning over incomplete account history does not produce nothing; it produces something confident and wrong, faster than a person would have produced it, and with more apparent authority.

What I would do before the next pilot

Write down the workflow, not the task. Name what it costs when it goes wrong today. Check whether whoever is building it can describe where the work breaks without being told. Decide how a person will inspect and decline the output before you decide anything about the model.

Then pick the model. It will matter less than any of the above.

The full conversation is on the GeneCoda episode page, with the host, Don Alexander.

Disclosure: I build ARIA at LuminOne, a reasoning platform for life sciences commercial teams. The argument above is why it is built the way it is, and you should read it with that interest in mind.