Who actually blocks AI in healthcare (and why)

Co-authored by
Charles_Wallace

This is Part 1 of a three-part series on the organizational readiness work between a Copilot proof-of-concept and AI at scale. Part 2 covers why identity is the technical gate that decides whether Copilot turns on. Part 3 finishes with agent governance as organizational readiness. 

Who this is for: IT leaders, M365 admins, and project sponsors who keep losing AI pilots in committee. 

I've watched a lot of Microsoft 365 Copilot pilots succeed technically and die anyway. 

The deployment worked. Licenses were assigned, Conditional Access held, the data didn't leak. Early users loved it. The ambient documentation pilot was reportedly saving clinicians the better part of twenty minutes a visit. Then it sat in a steering-committee queue for two quarters and the funding lapsed. 

That pilot didn't fail on technology. It failed on people. In healthcare, that's the failure mode nobody puts on the project plan. 

If you've deployed AI in other industries, you know change management is hard everywhere. Healthcare is a different kind of hard. Not because the people are more resistant—it's that the structure of who can stop you looks nothing like other industries. This post maps the people who decide whether your AI program ships, what they actually worry about versus what they say, and the order to engage them in.

Why healthcare's stakeholder map is different 

In most enterprises, an executive sponsor with budget can clear the path. A VP says: "We're doing this," and the organization moves. 

Healthcare doesn't work that way and the reasons are structural. Physicians aren't employees in the ordinary sense. In teaching hospitals, they're often represented by a residents' association or a faculty practice plan. In community systems, admitting privileges give independent physicians real leverage. They can decline to change a workflow and clinical leadership will usually back them.  

On top of that professional autonomy, several European countries, most notably Germany, give works councils legally protected co-determination over technical systems that can monitor staff behavior or performance. How broadly that gets read varies by jurisdiction. Anything that touches care delivery draws scrutiny from patient and family advisory councils and ethics committees. Under all of it runs one constant question: if this goes wrong, who gets sued? Malpractice liability colors every workflow change, whether anyone says so out loud or not. 

None of this shows up in a generic readiness checklist. All of it can stop an AI deployment cold. 

The blockers nobody puts on the project plan 

Physicians and clinical staff control whether AI ever touches clinical workflow. The stated concern is usually speed or accuracy: "This will slow me down; the model isn't good enough." The real concern is autonomy and trust in a tool they didn't choose. Union strength sharpens this in teaching hospitals. Independent-physician leverage does the same in community systems. 

Works councils, especially in European systems, hold co-determination rights. The stated concern is data protection. The real one is surveillance of their members. The behavioral signals a security team can switch on, things like Insider Risk analytics and detailed usage tracking, read as monitoring and can trigger a formal consultation. 

Patient advocacy groups and ethics committees speak for the people receiving care. The stated concern is privacy. The real one is consent and algorithmic harm: was the consent genuinely informed and voluntary? Do patients understand what algorithmic help means for their care? That gets sharper with anything patient-facing.

Legal and Compliance gets misread more than any other group. The stated concern is almost always HIPAA. The real one is liability and organizational risk aversion. HIPAA usually permits what you're trying to do if you design for minimum-necessary use and get the vendor agreements right. The regulation is rarely the real blocker. Liability and vendor risk are. The vendor terms that matter are the ones on sub-processing, restrictions on model retraining with PHI, and data deletion. You answer that with a named governance owner and an audit trail, not by arguing with the statute. 

The CISO and security team own breach liability and they hold a veto most IT leaders forget to plan for. The stated concern is data loss and audit coverage. The real one is that the needs of logging and monitoring an AI rollout can collide with the access model they already run. They're the ones accountable if it goes wrong. On a security-led program, this is your closest ally or your hardest gate, depending on whether you bring them in to co-design the controls or hand them a finished plan to approve.

The CMO, CNIO, and CMIO hold a veto that surprises most IT leaders. Clinical leadership can stop an IT-led initiative if they believe care continuity is at risk. A CIO can fund and deploy a program that either the Chief Medical Officer or the Chief Nursing Information Officer, depending on clinical scope, can still kill. The Chief Medical Information Officer sits between IT and clinical leadership. In practice, they often decide whether that co-sponsorship materializes at all, so engage the CMIO before you assume you have the others. If clinical leadership isn't a co-sponsor, you don't have a sponsor.

Stated concern vs. actual concern 

The most useful habit you can build is separating what a stakeholder says from what they mean and then answering the real objection. The stated concern is the door you knock on. The actual concern is the room you have to walk into. 

"HIPAA won't allow it" almost never means the regulation forbids it. It means "I don't want to own the risk of this change." Argue the regulation and you lose. Offer a governance owner and an audit trail, and you're past it. 

When a physician says the model isn't accurate enough, they've usually not benchmarked anything. They mean "I didn't pick this and I don't trust being second-guessed by software." The fix isn't a better accuracy number. It's bringing them into scope and giving them a way out if it isn't working. 

When a works council raises data-protection concerns, the subtext is often that their members feel watched. The fix is being precise about what is and isn't logged and involving them before you deploy instead of after. 

When a CMO or CNIO raises care-continuity risk, they're often right, but underneath it sits a simpler ask: "I want a vote on this, not a notice." Co-sponsorship, where they review the real architecture and workflow decisions and not just the rollout message, is the key. 

A stakeholder map for healthcare AI 

Before you write a deployment plan, map the people. For each group, you want four things: their veto power, their stated concern, their actual concern, and your first move. Run this in a sixty-minute working session with your project lead before the kickoff deck exists. Rank by veto power. Anyone in the high rows who isn't engaged yet is a risk on your plan, not a footnote. The actual-concern column tells you what to bring to the first conversation.

Three examples from the field 

The teaching hospital. A 500-bed academic medical center piloted ambient clinical documentation and the clinicians loved it. The residents' association still invoked a workflow-change review because the rollout hadn't been brought to them first. The pilot froze for six weeks and only restarted once the CNIO came on as co-sponsor and the residents had a say in scope. Clinical co-sponsorship wasn't a formality. It meant the CNIO reviewed the workflow design, not just the rollout message. That was what moved it. 

The European works council. A health system planned to turn on usage analytics and Insider Risk signals alongside Copilot. The works council read the activity logging as surveillance and opened a formal co-determination consultation that took several months. In those jurisdictions, organizations engage the works council before enabling anything that logs clinician behavior, and they are specific about what is and isn’t captured. 

The community network. A community hospital network wanted a patient-facing scheduling agent. The patient and family advisory council required a consent-and-disclosure design, so patients knew they were talking to an agent and agreed to it before going live. For anything patient-facing, consent design is a gate, not a finishing touch.

Three systems, three different blockers, one pattern: the technology was never the problem. 

Who to talk to first 

Mapping the stakeholders is half the job. Sequencing the conversations is the other half. The order that holds up across most healthcare deployments looks like this: 

1. Clinical leadership first. Without a clinical co-sponsor, nothing else matters. Get the CMO or CNIO on board and the CMIO in to scope the workflow before you build a deck. 
2. Security and the CISO early, as co-designers. Bring them the logging and access model while it's still a draft so the controls get built in instead of bolted on.
3. Legal and Compliance early, for partnership rather than permission. Bring them a governance owner and an audit-trail plan and ask them to help you de-risk, not to bless without oversight.
4. Frontline champions. Find the physicians and nurses who'll co-scope and advocate and give them real influence over what gets piloted.
5. Works councils, where they exist, before any logging goes live. Treat the consultation as a prerequisite, not a reaction.
6. Patient advocacy and ethics for anything patient-facing. Consent and disclosure design before go-live, every time. 

Put these conversations on the calendar before the technical project plan, not after. You won't finish all of them before the kickoff deck, but if any of these people first hear about your plan in a steering-committee meeting, you've already lost ground. If you can't name the person on the other side of each one, your pilot is already at risk, however clean the deployment. 

You can't engineer your way around a broken stakeholder map. The readiness work nobody talks about starts here. Not with licenses or Conditional Access, but with an honest map of who can stop you and why. Get the people right, address their concerns, and the technical deployment turns into the easy part. 

Part 2, "Why Identity Is the Copilot Unlock," takes on the first hard technical gate: why so many health systems have bought Copilot and still can't turn it on, and how to work through the Okta-to-Entra migration without breaking 24/7 care. 

Charles Wallace is a Senior FastTrack Architect at Microsoft. He works on Microsoft 365 Copilot and agent adoption across healthcare and life sciences and on the security, identity, and governance foundations that decide whether AI deployments actually succeed.