A health plan builds the fix its own operations team needs: the same NPPES-and-TIN matching logic, now correctly routed to a fast-tracked credentialing queue instead of auto-creating records on its own. It's the right build, and three months later the credentialing team is still manually re-checking every single AI-flagged match before acting on it anyway. The queue barely moves faster than before, and half the team calls it “the thing IT gave us.” Nothing was wrong with the model. What was missing was the answer to a set of questions no one asked before go-live: are the people who have to use this every day comfortable enough, and confident enough, to actually rely on it? Does it fit into their current workflow, or does it feel like an inconvenient extra step? Does it make their jobs easier, or does it just add a new burden on top of the old one?
This is a different failure mode than a bad build, and it comes down to two separate questions: whether the workflow itself was designed with the right payer operations and systems knowledge, and whether the operations team on the receiving end trusts and adopts what was built for them. A plan can get the first question exactly right and still watch adoption stall on the second. Readiness isn't just a property of the AI, but of the relationship between AI and the people whose job it now touches.
The confidence gap that shows up between competing plans, the one where most believe they're ahead while few actually are, shows up inside a single organization. Accenture's 2025 Pulse of Change survey found the same split: 92% of C-suite leaders believe their organization is trained to use AI efficiently, while only 72% of employees agree. The leadership team announcing a win and the staff being asked to adopt it are describing two different rollouts.
What Operational Readiness Actually Means
It means staff understand precisely what the AI is and isn't authorized to decide on its own, so they're not left guessing whether to double-check everything or nothing. The AI is never a black box to the people using it: staff can see the basis for a recommendation, not just the recommendation itself, so trust doesn't depend on blind faith. Staff trust the model's outputs enough to act on them without redundant manual verification, because that trust was built through a visible track record and visible reasoning, not just a rollout email. They know exactly how and when to escalate or override a recommendation, and that doing so is part of the process, not a failure. Every override is feedback: it gets captured, reviewed, and used to refine the workflow, so the AI gets more accurate the longer the team works with it. And it means the staff who held the undocumented exception knowledge, the people who used to make the judgment calls, were consulted while the workflow was being designed, not informed about it afterward.
Signs the Buy-In Isn't There
A plan doesn't need to ask staff whether they trust the tool. Four behaviors already answer the question:
- Shadow workarounds: staff quietly keep using the old manual process alongside the new AI-driven one, “just in case.”
- Redundant verification: every AI output gets manually re-checked in full, which erases most of the efficiency gain the build was supposed to deliver.
- Escalation creep: staff route routine, in-bounds cases to a supervisor anyway, because they don't trust their own authority to act on the AI's recommendation.
- Language that distances: staff describe the tool as something that was done to their workflow, not something that's now part of it.
Building Buy-In Before Go-Live, Not After
The fix starts earlier than launch, in a few concrete steps:
- Involve frontline staff in design sessions, especially the tenured ones holding undocumented judgment calls. Don't just bring them in for user-acceptance testing at the end.
- Pilot with a real feedback loop, and keep it running after go-live. Early mistakes get corrected visibly, and staff can see the model improve in response to what they flagged, during the pilot and long after it.
- Define override and escalation authority explicitly, in writing, so staff know using their judgment against the AI's recommendation is expected, not a workaround.
- As much as possible, design the interaction to sit inside the workflow staff already use, rather than bolting on a new screen, login, or step. The goal is that adopting the tool feels like less work, not more, and that it fits into their day rather than interrupting it.
- Communicate what changed and why in terms of the job, not the technology: what decision now moves faster, what stays exactly as it was, and what's different about their role.
Buy-In Alone Isn't Enough
Operational readiness is necessary, but it isn't sufficient on its own. A plan can have a well-designed build and a frontline team that trusts it, and still watch the initiative stall if the data, governance rules, and accountability structure behind it were never put in place. Readiness has to hold at every layer: the build, the people using it, and the organization around them.
i2 Health builds operational buy-in into the deployment plan from day one, so adoption isn't left to chance after go-live.
Not sure whether the people who have to use what you built actually trust it? Start with an AI readiness assessment.
Frequently Asked Questions
Q: Why do AI implementations stall in health plan operations even when the model works?
Because readiness gets measured on the technology, not on the operation around it. If staff don't know what the AI is authorized to decide, can't see the basis for its recommendations, and don't have override authority in writing, they re-verify every output or keep the old process running alongside it. The build is sound, and the efficiency gain never shows up.
Q: If staff can override the AI whenever they want, doesn't that undercut the whole point of automating the work?
No. Overrides are how AI gets better. In a human-in-the-loop workflow, every override is captured, reviewed, and used to refine how AI handles similar cases, so the share of cases that need a human call shrinks over time. The real failure mode is staff re-checking everything AI already got right. Redundant verification erases the efficiency gain a build was supposed to deliver. Override authority is what keeps improving it.
Q: We already piloted an AI tool and staff still don't trust it. What's the most common reason that happens?
Almost always, override and escalation authority was never put in writing. Staff assume using their own judgment against the tool's recommendation will get flagged as a mistake, so they either quietly work around the tool or route everything to a supervisor to be safe. Naming that authority explicitly, before the next pilot, usually moves faster than rebuilding the model.
Q: What's the difference between staff not using an AI tool and staff not trusting it?
Not using it shows up as a shadow workaround: the old manual process keeps running quietly alongside the new one. Not trusting it looks like adoption on paper — staff click through the tool, but they re-verify every output before acting on it. The second failure is more expensive, because it looks like success in a usage dashboard while the promised efficiency gain never shows up.
