After patient data reaches a public AI tool, which cleanup steps are still yours?
On 21 September 2026, according to WMAR-2 News, a staff member at Johns Hopkins Bayview Medical Center uploaded a spreadsheet covering 3,182 patients to a public AI tool the hospital had not approved, and the hospital found it the same day. Most of the cleanup it could run itself. One step, deleting the data from the operator's systems, could only be requested. Test that step in a shadow AI incident response tabletop before you need it.
What happened at Johns Hopkins Bayview?
On 21 September 2026, WMAR-2 News reports, a staff member at Johns Hopkins Bayview Medical Center in Baltimore uploaded a spreadsheet of patient information to “an outside AI platform that was not cleared for that use”. The hospital found the upload in an internal review the same day.
The spreadsheet covered 3,182 patients admitted and treated between May and September 2026, the figure both WMAR-2 and The Baltimore Banner give. It held names, dates of admission and treatment, medical record numbers, account numbers, the treating department, medications given and provider names. Social Security numbers and financial account details were not in it. Letters to patients began going out on 22 October, with 12 months of credit monitoring.
Finding an upload on the day it happened, investigating it and writing to every patient affected is a privacy office doing its job, and the hospital deserves credit for it.
The act itself was ordinary. A spreadsheet and a question is how most people use these tools at work. The reports put it down to an employee's mistake, and this post leaves it there. Neither report names the tool.
Which steps of the response could the hospital run itself?
The hospital's own people carried out four of the five steps the two reports describe; deleting the data from the operator's systems could only be requested. The figure sets the five out in the order they happened, with who could carry out each one.
The five reported steps of the response, and who could carry each one out
Three of those four ran entirely on the hospital's own systems. The second step ran in the operator's interface. What it removes from the operator's own systems, whether in logs, in backups or in any later use of the data, is set by the operator.
The third step settles what happened to the data after it left: the hospital asked the company that runs the tool to delete it. The reports do not say what the operator replied.
Why does the operator's reply matter to whoever signs the notice?
When personal data leaves an organisation, the privacy office and counsel describe the exposure to the people affected and, where the rules require it, to regulators. Most of that description comes from the organisation's own records: what was in the file, whom it covered, when it left and when it was found.
Once the data sits with a third party, the account of what happened next comes from somewhere else. Whether it was kept, for how long, in which systems, and whether anyone or anything read it afterwards can only come from the third party's answer and its own records. The organisation can ask, and can record that it asked. It has no log of its own to check the answer against.
Every AI route your staff use is part of your incident response plan, whether or not anyone wrote it down.
How common is a shadow AI breach?
IBM's Cost of a Data Breach Report 2025, published on 30 July 2025, studied 600 organisations that had a breach between March 2024 and February 2025. One in five of them reported a breach due to shadow AI, the AI tools staff use without the organisation's sanction. Where shadow AI use was high, IBM found that breaches cost an average of $670,000 more than where it was low or absent. Those incidents also reached personal information more often than the average breach in the study.
Shadow AI incidents exposed personal information more often than the average breach
Share of breaches in which personally identifiable information (PII) was compromised, percent. IBM Cost of a Data Breach 2025, 600 breached organisations.
- 1 in 5
organisations studied reported a breach due to shadow AI.
Source: IBM, Jul 2025 (600 breached organisations) - $670,000
higher average breach cost where shadow AI use was high.
Source: IBM, Jul 2025 - $7.42M
average cost of a healthcare breach, the highest of any industry studied.
Source: IBM, Jul 2025
Would banning unapproved AI tools have closed the gap?
Bayview is limiting unapproved apps and AI tools and retraining staff on the approved ones, which is the right first move. A restriction makes the unapproved route harder to reach. Whether the work then moves to the approved route depends on that route answering the same question as fast. Where it cannot, the spreadsheet question goes to a personal phone or to a tool nobody has listed yet, and the privacy office stops seeing it.
IBM measured how often organisations look for that drift: of those in its 2025 study with AI governance policies, only 34% audit regularly for unsanctioned AI. An approved route that people use also shows the privacy office where the work goes, because the work then passes through a system it can read.
How do you run a shadow AI incident response tabletop in 60 minutes?
The exercise needs an hour and a single scenario card: “A staff member pasted a patient list into a public AI tool this morning.”
Invite security, privacy, compliance, counsel and the business owner of the data. Walk the response step by step, in the order you would run it. For each step, write down who performs it, whether it depends on a third party, and the record you could produce yourself.
The tabletop worksheet
Example. The rows follow the steps reported at Bayview; replace them with your own response plan.
| Step | Who performs it | Depends on a third party? | Record you can produce yourself |
|---|---|---|---|
| Detect the upload | Security, internal review | No | Your own monitoring or review record |
| Remove it from the user's history | The employee, in the tool | Partly: the tool's interface | Screenshot or attestation only |
| Delete it from the operator's systems | The operator, on request | Yes | Whatever the operator sends back |
| Establish what was exposed | Privacy office | Partly: what happened after the upload rests on the operator | The original file and access logs |
| Notify and support patients | Privacy, compliance, counsel | No | Letters and credit monitoring records |
Then put three questions to every AI route your staff use, sanctioned or not:
- Where is the data processed, and on whose infrastructure?
- Who can delete it, and what record shows the deletion?
- Is there a per-person log of every read and write that can answer “who read this, and when?” in an afternoon?
A route that answers all three from your own systems brings the steps you marked “third party” back inside. The Agent Maturity Index scores the same ground across a whole AI programme, in two of its seven dimensions: Governance and Control, and Sovereignty and Residency.
If you sign the breach notice
Book the hour this quarter. Bring counsel and the business owner of one patient or customer dataset, run the scenario once, and leave with a list of every step marked ‘third party’. That list is the specification for the approved AI route, written around the task your staff were trying to get done when they reached for a public tool.
If a staff member pasted customer records into a public AI tool today, who could show what happened to the data?
Anonymous. One vote per browser.
Where does SynOS fit?
SynOS is the layer between a company's agents and its own systems. It is self-hosted by default, in your cloud account or on your hardware, so the data agents read stays on your infrastructure. Every read and write an agent can perform is listed in a tool inventory, scoped to the person asking, tied to an agent identity and logged, and connections start read-only. Agents built on it rehearse against real systems with writes recorded rather than executed, so a change can be reviewed before it reaches a record. If your tabletop turns up a task with no approved route, bring that workflow and we will start there.
Questions privacy and security leads ask about shadow AI
What happened at Johns Hopkins Bayview Medical Center?
On 21 September 2026 a staff member uploaded a spreadsheet with information on 3,182 patients admitted between May and September 2026 to an outside AI platform the hospital had not cleared for that use. The hospital found it in an internal review the same day, had the employee delete the prompt, thread and document from the tool's history, asked the tool's operator to delete the data, and began mailing letters on 22 October with 12 months of credit monitoring. Social Security numbers and financial account details were not included.
Can you delete data after an employee uploads it to a public AI tool?
The employee can remove the conversation and file from their own history in the tool. What the operator keeps beyond that, in logs, backups or anything else, is set by the operator's systems and terms, so the organisation can ask for deletion and then relies on the operator's answer. That is why the step belongs in an incident response tabletop before it is needed.
How common are shadow AI breaches?
In IBM's Cost of a Data Breach Report 2025, which studied 600 organisations that had a breach between March 2024 and February 2025, one in five reported a breach due to shadow AI. Those incidents exposed personal information 65% of the time, against 53% across all breaches studied, and breaches cost an average of $670,000 more where shadow AI use was high.
How do you run a tabletop exercise for a shadow AI incident?
Put security, privacy, compliance, counsel and the data's business owner in a room for an hour with one scenario: a staff member pasted a patient list into a public AI tool this morning. Walk the response step by step and mark who performs each one and whether it depends on a third party. Every step that depends on a third party becomes a requirement for the approved AI route: processed on your infrastructure, deletable by you, and logged per person.
Sources
- Johns Hopkins alerts 3,000+ patients after data sent to AI tool, WMAR Web Staff, WMAR-2 News (23 October 2026, updated 24 October; the 3,182 count, the 21 September upload and same-day discovery, May to September admissions, the fields included and excluded, deletion from the tool's history, the request to the operator, policy and training, letters from 22 October, 12 months of credit monitoring, and the quoted phrase)
- Johns Hopkins data exposure caused by employee using unauthorized AI tool, Shayla Colon, The Baltimore Banner (25 October 2026; the 3,182 count, the unnamed third-party platform, the request to the tool's parent company, policy and training, credit monitoring)
- IBM Report: 13% Of Organizations Reported Breaches Of AI Models Or Applications, 97% Of Which Reported Lacking Proper AI Access Controls, IBM Newsroom (30 July 2025; one in five reporting a shadow AI breach, $670,000, 65% and 53%, 34%, $7.42 million; 600 organisations breached between March 2024 and February 2025)