The Short Answer
Shadow AI in healthcare is a product-feedback signal: in a December 2025 Wolters Kluwer Health survey, almost half of the healthcare workers who used unapproved AI did so for a faster workflow, and one in three said approved tools were missing or lacked the features they needed. The fix is a sanctioned platform clinicians prefer — on ibl.ai you own all the code and the data.
Policy still matters, but it is not sufficient. Johns Hopkins had AI guidelines and its own approved AI platform, and in September 2026 a Johns Hopkins Bayview worker still uploaded a spreadsheet covering 3,182 patients to an unapproved tool.
A rule that loses to a faster tool is telling you what the approved tool needs to do. Having a sanctioned tool is not the bar; winning the task is. Read the reasons clinicians give, build against them, and keep PHI on infrastructure the hospital runs.
Did a physician upload patient records to ChatGPT at Johns Hopkins Bayview?
No public source says a physician did it, and none names ChatGPT. What the reporting on Johns Hopkins Bayview Medical Center in Baltimore does establish is narrower, and serious enough on its own.
According to WMAR-2 News, a staff member uploaded a spreadsheet to an outside AI platform the hospital had not approved. It covered 3,182 patients admitted and treated from May through September 2026.
The spreadsheet may have included names, admission and treatment dates, medical record numbers, account numbers, medications given and provider names. Social Security numbers and financial account details were reportedly not included.
The hospital found the upload during an internal review on September 21, 2026, and notification letters began going out on October 22, 2026, with a year of free credit monitoring. The worker's role and the AI company have not been disclosed.
Straight Arrow News reports that the first fix was to have the worker delete the chat and ask the company to delete the data. Hopkins did not say whether the company confirmed deletion, whether the data could be used for training, or whether it reported the incident to HHS.
The detail that matters most for this argument: Johns Hopkins published AI guidelines in May 2025, and Straight Arrow News reports they told the community not to enter clinical records into unapproved third-party generative AI tools.
Hopkins also had a sanctioned option. It announced HopGPT in December 2025, a private generative AI platform giving its community access to large language models from providers including OpenAI, Anthropic and Meta.
Whether the Bayview worker had access to HopGPT, or why they used another tool, has not been reported. What is known is that a written policy and an approved platform both existed, and the upload happened anyway.
How many clinicians use unapproved AI tools at work?
The best recent measurement is a Wolters Kluwer Health survey, Shadow AI: A hidden risk to healthcare. It was an online survey of 518 full-time hospital and health system staff (256 providers and 262 administrators), conducted in December 2025.
| Wolters Kluwer Health finding (n=518, Dec 2025) | Providers | Administrators |
|---|---|---|
| Admitted using an unapproved AI tool | 15% | 19% |
| Encountered unapproved AI tools but did not use them | 40% | 40% |
| Aware a colleague has used unapproved AI tools | 41% | 41% |
| Shadow-AI users who did it out of curiosity and experimentation | 26% | 10% |
Across all respondents, 17% admitted using an unapproved tool and 57% had encountered or used one. Two cautions apply. "Providers" is broader than physicians, and the survey measured use of unapproved tools, not uploads of patient records.
Wolters Kluwer also sells clinical AI (the report closes by promoting UpToDate Expert AI), so treat it as a vendor-sponsored survey. It is still the clearest published data on why clinicians reach for tools their employer did not approve.
Why do clinicians use shadow AI instead of their hospital's approved tools?
Clinicians use shadow AI in healthcare because it is faster and because the approved option is missing or weaker. In the Wolters Kluwer Health survey, almost 50% of respondents asked why they used unapproved tools cited a faster workflow.
One in three pointed to either a lack of approved tools or approved tools lacking the desired functionality. That is two failure modes a hospital can fix: no sanctioned tool at all, and a sanctioned tool that does not do the job.
The demand behind those answers is large. The AMA's 2026 Physician AI Survey, fielded January 15 to February 2, 2026 across 1,692 physicians, found 81% reporting awareness or use of AI in their practice, up from 66% in 2024.
The AMA found use centered on documentation and summarization.
Nearly 40% of respondents use AI for summaries of medical research and standards of care, 26 points higher than in 2024. Those are the same tasks a general-purpose chatbot is good at, which is why a clinician with no sanctioned option opens one.
Why is shadow AI in healthcare a product-feedback signal rather than only a compliance problem?
Shadow AI in healthcare is a product-feedback signal because each reason a clinician gives for going around the approved tool maps to a requirement the approved tool failed.
The compliance exposure is real, but it is the symptom. The cause is a gap between what clinicians need and what they were given.
Wolters Kluwer's own recommendation points the same way: addressing shadow AI "is not about restricting access to productivity tools." Leaders, it says, must understand which challenges their teams are trying to solve.
Here is that translation, from the stated reason to the requirement it implies.
| What the clinician said (source) | What it tells the hospital | Requirement for the sanctioned tool |
|---|---|---|
| "Faster workflow" — almost 50% (Wolters Kluwer) | The approved path costs more clicks than a chatbot tab | Answers in the place the work happens, at chatbot speed |
| No approved tool, or it lacks functionality — 1 in 3 (Wolters Kluwer) | The use case is unserved, or served by a weaker model | Freedom to run the strongest model for each task, and to switch |
| Curiosity and experimentation — 26% of providers (Wolters Kluwer) | Clinicians want to try things, and will do it somewhere | A sanctioned sandbox where experiments touch only approved data |
| Data privacy assured by my own practice/hospital and EHR vendor — 86% important (AMA) | Physicians want privacy their own institution stands behind, not a consumer app's terms | PHI stays on infrastructure the hospital controls |
| Want to be consulted or responsible for adoption — 85% (AMA) | Tools chosen without clinicians get routed around | A platform clinicians can shape, with a feedback channel |
Read this way, a shadow-AI incident is a free user-research finding. The clinician who pasted a spreadsheet into a public chatbot has shown, at real risk, which task the hospital's tooling did not cover.
What does HIPAA require when PHI goes to an outside AI tool?
HIPAA lets a covered entity disclose PHI to a business associate only after obtaining satisfactory assurances, normally a written business associate agreement, that the vendor will safeguard it. HHS sets out the required terms in its business associate contract guidance.
An unapproved public AI tool comes with no such agreement with the hospital. That is why an upload like the one at Johns Hopkins Bayview is handled as a potential breach rather than a policy slip.
The HHS Breach Notification Rule requires notice to affected individuals without unreasonable delay and no later than 60 days after discovery. Breaches affecting 500 or more people must also be reported to the HHS Secretary within that window.
A breach affecting more than 500 residents of one state also requires notice to prominent media outlets serving it. If treated as a breach, the Bayview incident, at 3,182 patients, is well above the 500 threshold; the hospital has not said publicly whether it reported to HHS.
A signed agreement does not solve the underlying problem either. As we covered in a BAA is not the same as HIPAA-compliant AI, a contract allocates responsibility after the fact; it does not keep PHI from leaving the building.
What do physicians say would make them trust a hospital AI tool?
Physicians say they would trust a hospital AI tool that the hospital itself vouches for on privacy and safety. In the AMA's 2026 Physician AI Survey, the top factors for adoption were validated safety and efficacy (88% important) and data privacy assurances (86% important).
The wording of the privacy item matters: "Data privacy is assured by my own practice/hospital and EHR vendor." Seventy percent gave it the top rating. Physicians are asking for privacy their own institution can stand behind, which a consumer chatbot account cannot provide.
The AMA also found 85% of physicians want a direct role in AI decisions: 55% prefer to be consulted and 30% want responsibility for implementation. A designated feedback channel when issues arise ranked among the top adoption requirements.
Training has a preferred place too. Asked how they want AI training delivered, 49% chose "as part of my EHR training" and 46% "as I'm doing my job". A sanctioned tool rolled out inside the existing workflow meets clinicians where the AMA says they are.
How does ibl.ai give clinicians a sanctioned AI tool they will actually choose?
ibl.ai is the agentic AI platform a hospital runs on its own servers or in its own cloud account, so the sanctioned tool can be as capable as the chatbot it replaces while PHI stays inside the hospital's environment.
You own all the code and the data, under a perpetual Full Code License.
That answers the 1-in-3 complaint about missing functionality directly. The platform is model-agnostic: a hospital can run an open-weight model on its own GPUs for PHI workloads and a frontier model for non-PHI tasks, and switch either without re-platforming.
It answers the AMA's 86% as well. Every PHI access and agent action is logged on systems the compliance team controls, with minimum-necessary access by role, so privacy assured by the hospital itself is a description of the architecture rather than a promise in a vendor's terms.
Agents connect to Epic, Oracle Health and MEDITECH through HL7 FHIR and MCP servers the health system owns, so answers can appear where clinicians already work. The healthcare deployment is described on the ibl.ai medical and healthcare page.
Refusal rules belong to the hospital too. After a lawsuit alleging ChatGPT drafted an antiseizure-medication taper, we described how structural refusal for healthcare AI works when you own the guardrails rather than rent them.
Pricing follows the same logic. ibl.ai has no per-seat pricing, so every clinician, coder and front-desk employee can use the sanctioned tool, instead of a licence count deciding who gets the safe option and who keeps the chatbot tab open.
What should a hospital do in the next 30 days about clinician shadow AI?
A hospital should treat its next 30 days on clinician shadow AI as user research, not only enforcement. The Wolters Kluwer data says 57% of staff have encountered or used unapproved tools, so the question is which tasks pushed them there.
Ask, without amnesty theatre. Survey clinicians and administrators on which AI tools they use and for what task. The Wolters Kluwer split (15% of providers, 19% of administrators) says both groups need asking.
Rank the tasks, not the tools. Group answers by task (summaries, discharge instructions, portal replies, billing documentation). The AMA found discharge instructions, care plans and progress notes already used by 30% of physicians answering that question.
Ship one sanctioned replacement per top task. Pick the highest-volume task and deploy an agent for it on infrastructure the hospital controls, then tell staff in EHR training, where 49% of physicians say they want it.
Keep the policy, and measure the gap. A rule against unapproved tools still belongs in the handbook. Track how often it is broken as a measure of where the sanctioned platform still falls short.
Our earlier guide to shadow AI in healthcare and patient safety covers the 90-day governance side, the cost comparison and which workloads can run in a vendor cloud.