How to Make the Case for an AI Tool When Your Org Is Still Figuring Out Governance

Somewhere in a healthcare organization right now, a prior auth coordinator is tabbing out of her organization's approved, HIPAA-covered AI tool to search Google for payer-specific denial codes.

Not because the AI tool can't search the web. Because the feature hasn't been approved yet.

The broader AI usage policy is still being written. The governance committee tabled the feature request until it is finished. So she Googles. The billing coordinators Google. The scheduling staff cross-references insurance coverage rules on public websites. All of it outside any governed system, with no documentation, no audit trail, no oversight.

This is not an edge case. It is the operational reality for a significant portion of healthcare organizations in 2026: organizations that have invested in enterprise AI tools, signed the BAAs, completed the security reviews, and are now watching their staff work around those tools because the internal approval process has not caught up to what the tool can already do.

The governance team is trying to reduce risk. What they are producing, without meaning to, is a different kind of risk entirely.

This situation is not unusual. It is, at this point, the defining operational tension of AI adoption in healthcare.

According to a 2026 joint report from Eliciting Insights and HFMA, 75% of U.S. health systems have deployed or plan to deploy at least one AI tool. Only 18% have mature AI governance. That is a 57-point gap between what organizations are running and what they can account for.

Forty-two percent of health systems have neither a documented AI strategy nor a functioning governance structure. They are running AI tools with no policy in place and no committee with the authority to make decisions about them.

Here is the number that should concern ops leaders most: 47% of health systems cite data sharing as a top barrier to AI adoption. The absence of a governance policy has itself become a brake on using the tools that governance was supposed to enable. The policy meant to manage risk is creating operational standstill.

This is not a critique of governance teams. Writing an enterprise AI policy in 2026 is genuinely difficult. Regulatory frameworks are still evolving. Vendor terms are inconsistent. The range of AI use cases inside a single health system spans clinical documentation, revenue cycle, scheduling, compliance research, and a dozen other workflows, each with its own risk profile. Building a policy that addresses all of it coherently takes time.

The problem is what happens in the meantime.

When staff cannot access useful tools through approved channels, they find other ways.

According to TechTarget's 2025 survey of healthcare IT executives, 86% reported instances of shadow AI in their organizations, up from 81% the year before. Shadow AI means staff using AI tools that IT has not reviewed, approved, or configured with appropriate controls. It means prior auth coordinators using free browser-based AI tools to draft appeal letters. It means billing specialists pasting claim data into consumer chatbots to look up coding guidance. It means the exact data exposure the governance policy was designed to prevent, happening quietly, at scale, with no documentation.

The breach data reflects this. Organizations that experienced shadow AI incidents had a 20% breach rate. Those using sanctioned tools had a 13% breach rate. The 7-point difference is the cost of keeping people away from governed tools.

This is the argument that most governance teams have not yet seen framed this way: blocking a specific capability inside an already-approved, already-BAA-covered enterprise tool does not reduce risk. It relocates it. The risk moves from a monitored, admin-controlled environment to an unmonitored, uncontrolled one.

Every major framework for healthcare AI governance, including guidance from the AMA, HIMSS, and the peer-reviewed literature published in journals like npj Digital Medicine, uses a risk-stratification model. The question is not whether an enterprise policy is complete. The question is whether the specific risk profile of a specific capability has been assessed and whether appropriate controls are in place.

These are different questions. One takes months. The other can be answered in a focused review.

Anthropic's own guidance for healthcare organizations, published in their Enterprise AI Transformation Guide for Healthcare and Life Sciences, describes governance as a framework that "enables innovation while managing risk through carefully designed policies that balance protection with productivity." Governance that only protects, without enabling, is not functioning as designed.

The data supports this. According to the same Eliciting Insights research, health systems with a functioning AI governance council reach return on investment in roughly 7.5 months. Those without one take 13.5 months. Governance accelerates adoption when it works. It only slows adoption when it functions as a checkpoint with no defined process for moving through it.

The ops leader sitting in this situation is not asking to circumvent governance. She is asking governance to do its job at the feature level, not just the enterprise level.

If you are in this position, or if you are preparing to make a similar request, here is what the evidence suggests a feature-level governance review requires. This is not a workaround. It is the process that credible frameworks actually describe.

A specific risk inventory for this capability, not a general AI risk assessment.

Web search within an enterprise AI tool carries a defined, bounded set of risks. The primary one is a user entering PHI into a search query, which would transmit that information outside the organization's controlled environment. This is a real risk. It is also a user behavior risk, not a platform architecture risk. The platform does not send conversation data to external parties for model training. Web search does not change that. The mitigation is documented user training on what not to include in queries, combined with clear guidance in your acceptable use policy, and admin-level logging that allows you to monitor usage patterns.

This is a narrower risk profile than many governance teams are initially assessing when they see "AI web search" on an approval request. Naming it specifically changes the conversation.

A description of what staff are doing instead.

The prior auth coordinator searching for payer-specific denial codes on Google is not doing something safer than using web search inside a governed AI tool. She is doing something less documented, less consistent, and less auditable. Naming this explicitly, with specifics about the workflows involved and the alternatives staff are currently using, gives the governance team a more accurate risk comparison. The question is not "is this risky" in isolation. It is "is this riskier than what is happening right now."

Admin controls documented as governance mechanisms.

Anthropic's HIPAA-ready Enterprise plans explicitly list web search as a configurable feature that plan administrators can enable or disable independently of other features. The governance team has control at the platform level. You can enable the feature for a defined set of users, in defined roles, with documented training completion as a prerequisite. This is not a binary choice between full access and no access. Scoped rollout to a specific team, with monitoring in place, is a governance mechanism.

Defined accountability before you ask for the yes.

The most common reason feature requests stall in governance review is that no one has answered the basic accountability questions in advance. Who owns the incident if something goes wrong? What constitutes a reportable event? What is the escalation path? If you can answer these three questions in writing before the request goes to review, you have built the governance layer that matters. You are not asking governance to create the oversight structure. You are presenting it.

A 90-day review checkpoint built into the request.

Ask for a time-limited, monitored rollout rather than permanent approval. Define what you will measure: query volume, any flagged incidents, user training completion rates. Commit to a review at 90 days with documentation of findings. This frames the request as a controlled pilot with defined accountability, which is easier to approve than an open-ended feature enablement.

The organizations that navigate this well are not the ones that waited for comprehensive policy before enabling any capability. The top 18% of health systems, those with mature governance programs, share a specific characteristic: their governance groups have the authority and the process to make decisions, not just to review and defer.

A governance committee that can only say "not yet" is not governing. It is delaying. The difference matters operationally, and it matters from a risk standpoint.

The AMA's guidance on developing AI policies frames it this way: before any AI solution is approved, there should be a structured assessment of the underlying problem, a justification for why AI is the appropriate tool, and a definition of how success will be measured. This is feature-level governance. It does not require a complete enterprise policy. It requires a structured process for evaluating a specific use case against a specific risk profile.

That process is what the ops leader in this situation is actually trying to initiate. She is not asking to skip governance. She is asking for a governance process that moves.

"We don't have a governance policy yet. Shouldn't we wait until it's done?"

The data suggests that organizations tying feature access to complete policy development end up with higher shadow AI exposure, not lower. The more defensible approach is a feature-specific risk review with defined controls. What are the specific risks of this capability? What controls address them? Those questions can be answered before the enterprise policy is finished, and the answers can inform the policy when it is written.

"What happens if a staff member enters patient data into a web search query?"

This is a legitimate risk, and it should be addressed directly rather than used as a reason to block access. The PHI exposure risk from web search is a user behavior issue, not a platform architecture issue. The mitigation is user training, acceptable use documentation, and admin-level monitoring, not feature disablement. The same staff member can enter PHI into a free consumer AI tool today with no controls at all. The governed tool is the safer environment.

"Is Claude.ai HIPAA compliant?"

Under Anthropic's HIPAA-ready Enterprise plan, with a signed Business Associate Agreement, yes. Web search is explicitly listed as a configurable feature within that compliance envelope. The BAA covers the platform. Admin configuration covers the feature. User training covers behavior. All three are required for HIPAA compliance, and all three are achievable before the enterprise AI policy is finished.

"How do we know web search won't return inaccurate information?"

This is a quality concern, not a compliance concern, and they require different responses. The mitigation for inaccurate web results is a human-review standard: AI-assisted research should be verified before driving a clinical or operational decision. This is the same standard you would apply to any research tool, including a staff member using Google. It belongs in your user training, not in your feature approval decision.

"Isn't this IT's decision, not operations?"

IT governs the infrastructure. Operations governs the workflow. Both perspectives are required for a sound feature-level decision. The operations leader is often the only person in the room who can describe what the risk actually looks like in practice, what staff are currently doing instead, and what the operational cost of delay is. That information is essential to an accurate risk assessment. If it is absent from the review, the governance decision is incomplete.

"What if something goes wrong after we enable it?"

Define that in advance. Who owns the incident? What constitutes a reportable event under your existing policies? What is the escalation path? If those three questions are answered in writing before the feature is enabled, you have governance. The enterprise policy can catch up.

Healthcare organizations are spending significant time and resources building AI governance frameworks. That work matters. The regulatory environment is complex, the stakes are real, and the organizations that invest in governance infrastructure now will be better positioned as compliance requirements continue to evolve.

What is worth examining is whether the governance process, as currently designed in many organizations, is producing the risk outcomes it was built to produce.

A staff member using a free consumer AI tool to draft a prior authorization appeal, outside any controlled system, with no audit trail and no organizational awareness, is a governance failure. It is just a quiet one. It does not show up on a committee agenda. It does not generate an approval request. It generates a breach statistic, eventually, and by then the connection to the governance delay is hard to trace.

The ops leader who surfaces this, names it specifically, and presents a feature-level case with defined controls is not working around governance. She is doing the work governance was designed to do.

What does that process look like inside your organization, and who has the authority to move it forward?