The Accountability Gap That's Killing Hospital AI Voice Deployments

There is a particular kind of vendor meeting that has become something of a ritual in hospital IT circles. It goes like this: a company with a name that sounds like someone lost a Scrabble game — three consonants, a vowel, lowercase — flies in to demonstrate their AI voice product. The demo is immaculate. The AI sounds warm and vaguely like someone's favorite nurse. It schedules appointments with an effortlessness that makes you wonder why you ever paid a human being to do this. The CIO is impressed. The VP of Patient Access is impressed. The CFO is doing the math on how many FTEs this replaces.

Six months later, the product is off.

I've had this conversation with hospital technology leaders more times than I can count over the past two years. And the postmortem almost always sounds the same: the AI worked fine when it worked. The problem was what happened when it didn't.

The Call That Fails at 2am on a Saturday

Here is a scenario that is less hypothetical than it should be. A patient calls the hospital's main line at 2:07am on a Saturday — not because they want to, but because they're frightened and they need to speak with someone about a symptom that showed up three hours ago. The AI answers. Or it should. But something in the call path breaks — a latency issue, a handoff failure, a timeout in the integration layer — and the call drops.

The hospital's IT director gets a ticket Monday morning. He calls the AI vendor. The AI vendor's engineers look at their logs and confirm their system was functioning normally. The issue, they explain, is in the telephony layer — specifically, a configuration in the SIP trunk managed by the hospital's telecom provider. The IT director calls the telecom provider. The telecom provider looks at their logs and confirms their infrastructure was operating within normal parameters. The AI vendor must have mishandled the handoff.

The IT director is now in the middle of a support ticket that will take eleven days to resolve, during which neither vendor will admit fault, both will perform extensive due diligence, and the patient who called at 2:07am will have either found another way to get help, called a competitor, or stopped trying.

This is not a technology failure. This is a structural failure. And it is, in my experience, the most common reason hospital AI voice deployments fail.

Why the Demo Always Works

It is worth pausing to observe that AI voice demos almost never fail, which is a little like noting that restaurants always look their best on opening night. In a controlled demonstration environment, with a curated call flow, a pre-configured test EHR connection, and a support engineer standing just off camera, of course the AI sounds good. The variable that the demo doesn't — and can't — test is the one that matters most at scale: what happens when the infrastructure underneath the AI has a bad day.

The infrastructure underneath matters because AI voice products don't float in the cloud, independent of the physical world. They terminate on your hospital's telephony environment, route through your carrier, hand off to your contact center platform, and write back to your EHR. Every one of those connections is a potential failure point, and every one of them belongs to a different company if you've assembled a typical enterprise AI stack.

When those are four different companies, you don't have a unified system. You have a coalition of vendors, each with their own SLA, their own support queue, their own definition of what constitutes their problem — and a gap in the middle where accountability goes to die.

The vendors who have built real market presence in this space — Hyro, Syllable, Assort Health — are not bad companies. Their demos are good for the same reason everyone else's demos are good: a controlled environment with a support engineer nearby is not a hospital contact center at 2am on a Saturday.

The Question Nobody Asks Their AI Vendor

Most hospital AI voice deals don't go through a formal RFP process. They go through a demo. A sales conversation. A follow-up call with the technical team. And in those conversations, buyers ask a lot of good questions — about EHR integrations, HIPAA compliance, uptime guarantees, language support, call containment rates, escalation logic, and implementation timelines. The one question that almost never gets asked is the one I would argue is more predictive of deployment success than any of those combined:

Who manages the communications infrastructure this product runs on end to end — and do you have a single contractual relationship that covers it when something fails?

Most AI voice vendors will tell you they have 'carrier-grade telephony' or 'enterprise-grade infrastructure.' What that phrase means, in practice, is that they have licensed telephony from a CPaaS provider, plugged it in, and moved on. Nobody on their team manages that infrastructure day to day. Nobody has a deep operational relationship with the carrier. And when something breaks, the AI vendor opens a support ticket with their CPaaS provider — exactly like you would, except you don't have a contract with the CPaaS provider, so you can't even do that.

What 'End-to-End Management' Actually Means

The obvious response to all of this is: fine, but how realistic is it to expect a single vendor to manage the full communications stack and build the AI? And this is a fair question. Most AI voice companies are software companies. Operating a carrier-grade communications platform is a different discipline entirely — one that takes decades of infrastructure relationships, not a Series B.

Which is precisely the argument for looking at this problem from a different direction. Rather than asking 'can we find an AI vendor who also manages the infrastructure,' the question becomes 'can we find an infrastructure company that has built the AI?' The difference in accountability is structural. When the AI and the communications platform are managed end to end by the same organization under a single contract, there is no gap between the carrier layer and the application layer. There is no intermediary pointing exercise. There is one team that can see the entire call path and one contract that covers it — which means there is one team that cannot, in good conscience, point at anyone else when something breaks.

Three Questions Worth Asking Before You Sign Anything

I am not suggesting that infrastructure ownership is the only thing that matters in evaluating an AI voice product. The AI has to be good. The EHR integrations have to be real. The implementation timeline has to be honest. But before any of that evaluation happens, these three questions belong in the next conversation you have with any AI voice vendor:

1. Who manages the communications infrastructure this product runs on — and is that the same company I'm signing a contract with?

If the answer is 'we use [CPaaS provider]' or 'our telephony runs on [third-party platform],' your next question is: what does your operational relationship with that provider look like? There's a meaningful difference between a vendor who licensed a carrier API and a vendor whose team actively manages the communications platform day to day. The latter can actually fix something when it breaks. Watch how quickly the answer comes — a vendor with a real infrastructure relationship answers this without hesitating.

2. When a call fails at 2am on a Saturday, who calls whom — and who is contractually on the hook?

Push on this one. A vendor with genuine end-to-end accountability will answer it directly and specifically. A vendor who doesn't will give you a version of '[X]% uptime' that applies only to their application layer and goes quiet when you ask about the carrier. The commitment that matters covers the entire call path — from the moment the patient dials to the moment the appointment confirms in your EHR — not just the software in between.

3. Is your EHR integration a live FHIR API connection, or something else?

This matters more than which EHR logos appear on the vendor's website. A live bidirectional FHIR API reads real-time provider availability and writes confirmed appointments directly back to the EHR — no batch sync, no manual reconciliation, no lag between what the AI scheduled and what appears in your system. 'We integrate with Epic' is a very different claim than 'we have a live FHIR connection that writes back in real time.' Ask specifically. The technical answer tells you whether the integration will hold up at scale or create a new set of problems to manage.

None of these are hostile questions. A vendor with nothing to hide will answer all three in about ninety seconds. The conversation that follows those answers will tell you more about the deployment you're about to make than any demo ever will.

A Note on What This Isn't

Continuant has spent thirty years managing communications infrastructure inside hospitals and health systems — and that has recently built an AI voice product, ConnectAI, on top of that managed platform. I want to be transparent about that, because it is obviously relevant to why I find this particular argument persuasive.

But the argument predates the product. I was making some version of it before we built ConnectAI, when I was watching hospital CIOs I've known for years try to untangle failed AI voice deployments that had gone sideways not because the AI was bad but because nobody had thought clearly about who was responsible for the communications layer when it had a bad day.

The point is not 'buy ConnectAI.' The point is: infrastructure accountability is a real risk that most hospital AI do not adequately address, the risk has a specific failure mode that is almost entirely predictable, and there is a question you can ask before signing anything that will tell you whether you're exposed to it.

What you do with that information is, as always, your problem to solve.