Deleted But Not Gone: The Johns Hopkins Shadow AI Incident and the PHI Persistence Problem

AI Security

A Johns Hopkins Bayview Medical Center employee uploaded a spreadsheet containing patient health information to a public AI tool the hospital had not approved. When the mistake was discovered, the worker did what most people would do — deleted the prompt, the thread, and the uploaded file. Johns Hopkins then spent weeks investigating, contacted the AI vendor requesting deletion, and ultimately mailed breach notification letters to 3,182 patients. The data may or may not be gone. Nobody can confirm it.

That sequence is the story. Not the breach itself, which is a known risk. The story is what happened after — and what it reveals about a dangerous gap between how healthcare workers think AI tools handle their data and how those tools actually work.

What Happened

On September 21, 2026, a workforce member at Johns Hopkins Bayview Medical Center in Baltimore uploaded a spreadsheet to an unapproved public AI tool. The spreadsheet contained admissions and treatment data for patients seen at Bayview between May and September 2026. The hospital discovered the incident and launched an internal investigation.

Johns Hopkins did not name the AI tool in its public communications. The hospital identified 3,182 patients whose information was in the spreadsheet, began mailing breach notification letters on October 22, 2026, and is offering credit monitoring to affected individuals.

The exposed data included names, medical record numbers, treatment dates, medications, and provider names. Social Security numbers and financial account information were not in the spreadsheet.

The "Delete the Chat" Problem

The immediate containment response is worth examining closely because it reflects a belief that is almost certainly widespread across healthcare organizations — and it is wrong.

After discovering the upload, Johns Hopkins had the employee delete the initial AI prompt, the conversation thread, and the uploaded document from the tool's history. From a user perspective, this looks like remediation. The file is gone. The conversation is gone. Problem contained.

It isn't. Deleting a conversation in a web-based AI tool removes it from your view. It does not remove it from the vendor's infrastructure. Depending on the platform, the data may persist in logs, training pipelines, abuse review queues, or backup systems — for days, weeks, or longer. The deletion action is a UI event, not a data destruction event.

Johns Hopkins understood this, which is why the hospital separately contacted the vendor requesting deletion. But as of the time breach notifications went out, Hopkins had not confirmed the vendor actually deleted the records. The patients who received those letters cannot verify where their information currently resides.

What This Means for Healthcare

This incident is not a Johns Hopkins story. It is a pattern that is playing out across healthcare organizations wherever AI tool adoption is running ahead of governance — which is most places.

Shadow AI Is a Clinical and Administrative Reality

Healthcare workers face real efficiency pressures. AI tools that summarize, draft, and analyze are genuinely useful, and the approved alternatives are often slower, more cumbersome, or simply nonexistent. The employee who uploaded that spreadsheet was almost certainly trying to do their job better. Shadow AI adoption in healthcare is not primarily a recklessness problem — it is a tooling gap problem.

That framing matters for how organizations respond. Training that says "don't use unapproved tools" without addressing why staff are reaching for those tools in the first place produces awareness without behavior change.

The Deletion Misconception Is Structural

Most users do not have a working mental model of how cloud AI services store and process data. When they delete a conversation, the system confirms the deletion in the UI. That confirmation feels like closure. It is not.

Healthcare security awareness programs need to explicitly address this gap. Workers should understand that any data submitted to a third-party AI platform should be treated as potentially retained by that vendor regardless of subsequent deletion actions in the UI. The only reliable containment is not submitting the data in the first place.

Business Associate Agreements and the Unapproved Tool Problem

Under HIPAA, covered entities can share PHI with vendors only when a Business Associate Agreement is in place. An unapproved AI tool, by definition, has no BAA with the hospital. That makes any PHI upload to that tool a potential HIPAA violation, regardless of intent and regardless of whether the data is subsequently deleted.

Johns Hopkins has not characterized this incident specifically as a HIPAA breach in its public communications. Whether HHS investigates or a formal breach determination is made will depend on factors that have not been disclosed — including the identity of the AI vendor, the vendor's data handling practices, and whether the data was actually deleted.

The Vendor Deletion Request Is a Weak Control

When an organization contacts an AI vendor after an unauthorized upload requesting deletion, the outcome depends entirely on that vendor's policies, technical capabilities, and responsiveness. There is no standardized process, no guaranteed timeline, and no verification mechanism. In the Johns Hopkins case, the hospital asked. Whether the vendor complied is unknown. Affected patients cannot independently confirm their data has been removed.

This is a gap in the current AI governance landscape that is likely to produce repeated incidents. Until AI vendors offer standardized, verifiable deletion processes — and until healthcare organizations require those processes contractually before any deployment — the "request deletion after the fact" response will remain a weak control with an unknown success rate.

What Healthcare Security Teams Should Do Now

Audit which public AI tools staff are actively using — the list will likely be longer than policy reflects
Update acceptable use training to explicitly address the UI deletion misconception
Establish a rapid-response process for unapproved AI uploads that includes documentation, vendor contact, and confirmation of deletion
Evaluate approved AI alternatives that address the workflows driving shadow AI adoption
Confirm that any AI vendor with potential access to PHI has a current, signed BAA

The Bigger Picture

Johns Hopkins has strong AI governance infrastructure — formal guidelines, approved tool lists, oversight groups focused on privacy and ethics. This incident happened anyway. That is not a criticism of Johns Hopkins. It is the honest reality of deploying AI governance in environments where thousands of workers make daily decisions about tools and workflows.

The incident also highlights something important about how breach response will evolve as AI adoption accelerates. Traditional breach response assumes a defined scope — a system was accessed, a file was copied, here is the dataset. AI platform uploads introduce scenarios where the scope is genuinely uncertain post-incident. Data submitted to a cloud AI service may have been processed, stored, fragmented across systems, or used in ways the vendor's own support team cannot fully account for. "We asked them to delete it" is a reasonable first step. It is not a complete remediation.

Healthcare organizations need breach response playbooks that specifically address AI platform incidents — including escalation paths to vendors, documentation standards, and criteria for breach determination under HIPAA. The Johns Hopkins response reflects an organization taking the incident seriously and moving methodically. The playbook to handle these incidents cleanly, across all healthcare organizations, does not yet widely exist.

This is an entry in the AI Security series. For related coverage, see AI Agent Unintended Actions: What Anthropic and OpenAI's Own Research Tells Healthcare Security Teams.