Your compliance program covers the tools you approved, not what your staff opened in a browser tab this morning. AI tools like ChatGPT or Gemini are often downloaded, bookmarked, or accessed via the web across clinical, administrative, and operational workflows.
Most of the people using them believe they’re working efficiently and have no idea they may be triggering a HIPAA exposure event with every prompt.
This is the healthcare data security gap that mature compliance programs keep missing. Not because they’re underfunded or understaffed, but because it’s structurally invisible to the tools they use to find it.
Why Compliance Programs Miss This
The staff reaching for ChatGPT, Microsoft Copilot, or Gemini aren’t acting maliciously. They’re solving a real problem: approved tools are slow, inaccessible, or not available for the task at hand. Generic AI is fast, free or nearly free, and good enough. So they use it.
What they don’t consider, because no one has told them in a way that lands, is what happens to the data after the prompt is submitted. Every vendor’s terms of service have specific answers to these questions, and the answers are rarely what a HIPAA-covered entity would accept in a formal vendor agreement:
- Does the vendor retain prompt data, and for how long?
- Are inputs used to train or improve future models?
- Who within the vendor’s organization has access to submitted data?
- What happens if the vendor experiences a breach involving that data?
More than half of employees now use personal generative AI accounts for work purposes, and a third admit to entering sensitive information into unapproved tools. In healthcare, where sensitive information means protected health information (PHI), that statistic carries regulatory weight that it doesn’t in other industries.
The governance infrastructure hasn’t kept pace. 97% of organizations that experienced an AI-related security incident lacked proper AI access controls, and 63% had no AI governance policy at all. That’s not negligence. It’s the natural result of adoption outrunning oversight. The blind spot isn’t a failure of intent. It’s a structural lag.
A policy that staff work around isn’t a control. It’s documentation that a gap exists.
What HIPAA Actually Requires
The regulatory standard here is specific, not aspirational. Under 45 CFR § 160.103, any vendor that creates, receives, maintains, or transmits PHI on behalf of a covered entity is a business associate. A signed Business Associate Agreement (BAA) must be in place before any PHI flows to that vendor. No exceptions. The AI vendor’s general terms of service do not substitute for a BAA.
Beyond the BAA, three additional requirements apply directly to AI tool use:
- Minimum necessary standard. Access must be limited to only the PHI required for the specific task. A general-purpose language model that ingests full patient records to answer a narrow clinical question does not meet this standard.
- Audit logging. HIPAA’s Security Rule requires a record of all PHI access under 45 CFR 164.312(b), including prompts, responses, timestamps, and requestor identity. If a tool can’t produce that log, it can’t satisfy this requirement.
- Breach notification. If PHI is disclosed to a vendor without a BAA, that disclosure is itself a reportable breach, regardless of whether any data was misused.
The consequences of getting this wrong are not theoretical. Current enforcement data makes the stakes clear:
- Penalties reach $1.5 million per violation category per year for willful neglect
- OCR’s Risk Analysis Initiative, launched in fall 2024, produced seven enforcement actions in its first six months
- OCR has reported a 264% increase in large breaches involving ransomware since 2018
The regulatory environment is not softening. The 2025 HIPAA Security Rule NPRM proposes the first major Security Rule overhaul in over a decade.
The final rule timeline remains uncertain under the current administration, but its proposed requirements, including stricter BAA verification and expanded technical safeguards, are already shaping what auditors look for.
What Generic AI Vendors Actually Commit To
This is where a HIPAA advisory conversation usually gets vague. It shouldn’t. The commitments and the gaps are documented in vendor terms and product configurations. Here’s what the landscape actually looks like for the three tools most likely running in your health system right now.
| Tool | Consumer tier BAA? | Enterprise BAA available? | Key carve-outs |
| ChatGPT (Free / Plus / Team) | No | Yes, Enterprise and API only | Multi-step Agent and Codex excluded from BAA scope even at enterprise tier |
| Gemini | No | Yes, Workspace Enterprise with Healthcare add-on | Consumer Gemini (gemini.google.com) is not covered; NotebookLM excluded |
| Microsoft Copilot / GitHub Copilot | No | Yes, via licensed M365 with Azure OpenAI pathway | GitHub Copilot is not under Microsoft’s BAA; consumer Copilot in browser is not covered |
A few things to understand about this table:
- The versions most of your staff are using are the consumer or mid-tier versions, which have no BAA available.
- Enterprise BAA availability does not equal compliance. A BAA is a starting point. It still requires correct configuration, appropriate access controls, and an internal process wrapped around it.
- What enterprise vendors typically do not commit to in writing:
- Specific data retention timelines
- Whether inputs are used to improve future models
- Audit log access for the covered entity
- Breach notification windows shorter than the HIPAA maximum
Most health systems currently live in the gap between “we offer a BAA” and “this deployment is HIPAA-compliant,” assuming incorrectly that the former implies the latter.
Where Exposure Lives
The exposure isn’t abstract. It lives in specific workflows, the ones your staff already use these tools for every day.
Clinical documentation. A clinician uses ChatGPT to draft a referral letter and pastes in the patient’s name, diagnosis, and medication history. That data has now been transmitted to a vendor with no BAA. That transmission is a breach.
Administrative summaries. A billing coordinator uses Copilot to summarize a patient account. The summary includes diagnosis codes, dates of service, and insurance identifiers. Same problem.
Drug diversion investigations. Most compliance programs treat this as a pharmacy operations issue. It’s also a data exposure issue.
What is drug diversion in healthcare? It is the theft or misuse of controlled substances by healthcare workers. Fentanyl is the most commonly diverted drug in the healthcare setting. The scale is larger than most compliance teams account for:
- Researchers estimate 10–15% of healthcare workers divert drugs at least once in their careers
- More than 9 in 10 facilities investigated at least one suspected diversion incident in 2023
- Only 5–10% of diversion events are ever detected and reported
That means active investigation files exist at nearly every health system in the country. Those files contain employee names, behavioral documentation, controlled substance transaction records, and in many cases, employee health information related to substance use disorder.
When a staff member drafts an investigation summary or pulls transaction data through a generic AI tool, they have transmitted PHI and protected employee health information to a vendor with no BAA.
That is a reportable breach, and it is happening at organizations that believe their drug diversion monitoring program is fully compliant.
Shadow AI added an average of $670,000 to data breach costs in 2025. Healthcare already carries the highest breach costs of any industry. At $7.42 million per incident on average, it has held that position for 14 consecutive years.
The Framework Compliance Leaders Should Apply Now
A HIPAA advisory without a decision framework is just a threat inventory. Here’s how to move from awareness to action.
Step 1: Inventory what’s actually in use.
Not what’s sanctioned, but what’s running. Shadow AI audits, browser extension scans, and direct staff surveys consistently surface tools that never appeared in a procurement process. Start here before any other step.
Step 2: Consider if the tool processes PHI.
If the answer is yes, or possibly yes, a BAA is required before use continues. This is not a gray area under HIPAA.
Step 3: Identify which tier is in use.
Verify the specific product and configuration for each tool, not just the vendor name. A Microsoft enterprise agreement does not automatically extend to GitHub Copilot. A Google Workspace contract does not cover consumer Gemini.
Step 4: Determine what the BAA actually covers.
Read it. Request data retention terms, breach notification timelines, and a list of features excluded from BAA scope. If the vendor won’t provide that documentation, treat the deployment as uncovered.
Step 5: Assess whether the tool meets the minimum necessary standard.
Evaluate how it limits PHI exposure per session. Does it have role-based access controls? Does it prevent users from inputting more than is needed for the task?
Step 6: Check for an auditable access log.
If the tool cannot produce a log of prompts, responses, timestamps, and requestor identity, it cannot satisfy 45 CFR 164.312(b). That is a disqualifying gap for any PHI-adjacent deployment.
Step 7: Verify whether the tool is built specifically for healthcare.
General productivity tools adapted to clinical use carry assumptions about data handling, retention, and model improvement that were not designed with HIPAA in mind. The evaluation does not end at the BAA signature.
What Purpose-Built Healthcare AI Looks Like
The difference between generic AI and purpose-built healthcare tooling isn’t a compliance checkbox. It’s how the product was built and what it was built for.
Purpose-built healthcare AI tools enter BAA relationships as a condition of deployment, not an optional enterprise upgrade. Audit logging, access controls, and data minimization are built into the product, not configured by the compliance team after the fact.
In drug diversion surveillance, that distinction is material. Detecting behavioral patterns in controlled substance transactions requires healthcare-specific data governance and chain-of-custody integrity.
A general language model processing the same data doesn’t know what a waste discrepancy is, why it matters, or that the employee record attached to it is protected health information. It just processes the prompt.
The same logic applies to patient privacy monitoring. A tool designed to surface privacy violations should not itself be capable of creating one.
Bluesight builds compliance tooling for exactly this environment: ControlCheck for diversion surveillance, PrivacyPro for patient privacy monitoring, and Prism as an AI platform designed for health system teams operating under real regulatory constraints.
The blind spot exists because sanctioned and in-use are two different lists. Closing it means making them the same one.
See how Bluesight’s purpose-built AI platform works. Request a demo today.