Why Healthcare AI Pilots Die: An Operator Post-Mortem

Healthcare AI pilots die because they get designed as demonstrations instead of as phase one of a rollout. I spent eight years selling into hospitals as employee #2 at Verto Health, which ran 100+ deployments across Canadian and US health systems between 2018 and 2026. The post-mortems kept surfacing the same five patterns: nobody owns the expansion, no budget-holder ever signed the success metrics, the integration got scoped for the pilot instead of production, the champion left, and procurement treated the expansion as a brand-new purchase. All five are fixable. But only in the contract, before anyone signs.

"Pilot purgatory" is the polite name for the state most healthcare AI products end up in: live at one site, technically successful, referenced in the vendor's deck, and going absolutely nowhere. The pilot didn't fail. It just never became anything else. That distinction matters, because vendors keep trying to fix pilot purgatory with better product, and the product usually isn't the problem. The problem is the deal structure.

Here are the five patterns, in roughly the order they kill you.

Pattern 1: the pilot has no expansion owner#

Every pilot has a sponsor. Almost no pilot has an expansion owner, and those are different jobs. The sponsor's mandate is "get this pilot approved and running." The expansion owner's mandate is "if this works, carry it to the next three sites, with the budget authority to do it." When those responsibilities live in the same person, that person is usually a clinical innovation lead or a digital health director. Here's the uncomfortable part: their incentive often ends at the pilot. A completed pilot is a line on their internal scorecard whether or not it expands.

So the pilot succeeds, the readout gets presented, everyone nods, and then the question "who takes this to the other sites?" lands in a room where nobody's job description contains the answer. The vendor assumes the sponsor will drive it, the sponsor assumes the operational VP will, and the VP has never heard of the project.

I watched this movie enough times at Verto that we started asking, in the first sales conversation, "if the pilot hits its numbers, whose budget funds site two?" The quality of the silence that followed told you most of what you needed to know about the deal.

Pattern 2: success metrics no CFO signed#

Most pilot success criteria are written by the people who are excited about the technology. That means they measure what the technology does (accuracy, adoption, time saved per task, clinician satisfaction) rather than what the hospital buys things for (avoided costs, captured revenue, reduced length of stay, staffing hours redeployed). Those first metrics are real, but they're not the currency the expansion decision gets made in.

The trap is subtle because the pilot can succeed on its own terms. Adoption is strong, clinicians love it, the sponsor is thrilled. Then the business case goes up to finance, and finance asks a question nobody scoped: "what does this change in the operating budget?" If the pilot wasn't instrumented to answer that from day one, you now need another six months of measurement, and the momentum is gone.

In my experience the fix isn't better metrics after the fact. It's getting a finance stakeholder to sign the success criteria before the pilot starts, so that hitting the number is the business case, not the prelude to building one.

Pattern 3: the integration cliff#

This is the technical version of the same disease. Pilots run on the easy path: a CSV export, a sandbox environment, a nightly batch, a single department's data. Production runs on the hard path: real-time interfaces, patient identity matching across an enterprise master patient index (EMPI), FHIR endpoints that exist on the EHR vendor's roadmap but not in this hospital's version. Add a privacy review, a security review, downtime procedures, and an integration team whose queue is measured in quarters.

I spent years as the architect on the wrong side of this cliff (FHIR, EMPI, SMART on FHIR, the whole stack), and the pattern was consistent. The gap between "worked in the pilot" and "works in production" is not an engineering estimate. It's a governance and queue-position problem. The hospital's interface team has a backlog, and your project enters it at the back.

If the pilot was architected to avoid integration (which is exactly what makes pilots fast to stand up), the expansion inherits 100% of the integration cost with none of the pilot's goodwill. The people who loved the pilot are not the people who run the interface engine. The teams that escape this scope one real integration into the pilot itself, even a small one, so the security review, the data-sharing agreement, and the queue position are already behind them when the expansion conversation starts.

Pattern 4: your champion will change jobs#

Healthcare leadership turnover is high enough that on any 18-month arc (and healthcare AI arcs are rarely shorter), you should plan on losing at least one key person. When the pilot's institutional memory lives in one champion's head, their departure resets you to zero. The new person didn't pick your product, doesn't own the decision, and has every incentive to re-evaluate rather than inherit.

The defense is boring and it works: a working group instead of a person. Across the client working groups I sat in over the years at Verto, the projects that survived turnover were the ones where the pilot's rationale, metrics, and roadmap lived in a standing group with clinical, IT, and operational members. Meeting on a cadence, with minutes. When the champion left, the group remained, and the group had already absorbed the "why."

It feels like process overhead when you're trying to move fast. It's actually succession planning for your deal.

Pattern 5: the procurement reset#

Here's the one vendors see coming least: the pilot contract and the production contract are often different procurement events. The pilot went through an innovation budget or a discretionary spend threshold, which is why it moved quickly. The expansion crosses a dollar threshold that triggers full procurement: RFP, competitive evaluation, legal review, sometimes a mandated open tender. Your successful pilot buys you a reference and, occasionally, the privilege of competing for the deal you thought you'd already won.

I've written more RFP responses than I care to count. The version that stings is the RFP for an expansion of a pilot that already succeeded. The fix is contractual and has to happen up front: negotiate conversion terms into the pilot agreement itself. Pre-agreed expansion pricing, a defined conversion trigger tied to the signed success metrics from Pattern 2, and (where the hospital's procurement policy allows it) language that the pilot constitutes the evaluation. Not every institution can agree to that. But asking the question early tells you whether you're piloting toward a purchase or toward a second sales cycle.

The escape plan: what to negotiate into the pilot before signing#

Pulling it together, this is the checklist I'd bring to any healthcare AI pilot negotiation. Every item goes in before signature, because your bargaining position after go-live is roughly zero.

1. A named expansion owner. A specific person, with budget authority beyond the pilot, named in the project charter. If the hospital can't name one, you've learned the pilot is a science project.
2. CFO-visible success metrics with a conversion trigger. Two or three metrics finance has signed, with thresholds, and contract language that says what happens when they're hit.
3. One real integration inside the pilot scope. Enough to force the security review, the data agreements, and the interface queue position during the pilot, not after it.
4. A standing working group, minuted, with IT and operations in the room. Your insurance policy against champion turnover.
5. Pre-negotiated expansion terms. Pricing, sites, and procurement path for phase two, written while everyone is still optimistic.
6. A calendar that respects hospital time. Budget cycles, EHR upgrade freezes, and accreditation windows will not move for your pilot. Map them before you commit to a timeline (a 12-week pilot that straddles a fiscal year-end is really a 30-week pilot).

None of this makes the pilot easier to run. It makes the pilot mean something, which is the actual job. A pilot that proves the product works is the easy part; something north of half the battle is proving, in advance, that success has a pre-agreed consequence.

If you're earlier in the process and still figuring out how hospital buying works at all, how to sell AI to hospitals covers the full sales motion, and the longer version of what eight years of this taught me has more of the post-mortem material. And if you're a founder heading into a pilot negotiation and want a second set of eyes on the deal structure, that's squarely the kind of thing I do in advisory engagements. Worst case, steal the checklist.