Ask a healthcare AI team whether they've vetted a new AI vendor, and most will describe a model evaluation: accuracy benchmarks, hallucination rates, maybe a red-team exercise. Ask whether that vendor has a signed Business Associate Agreement, and whether protected health information is already flowing to them, and the conversation gets quieter.
That second question is the one that actually determines HIPAA exposure. Model quality is a clinical and product concern. A BAA is a legal precondition for the disclosure itself. Under HIPAA, a covered entity has to have a BAA in place before disclosing PHI to a business associate, and a business associate, for this purpose, is any vendor performing a function on the covered entity's behalf that involves PHI. An AI vendor evaluating clinical notes, summarizing calls with patients, or processing support tickets that reference members fits that definition whether or not anyone thought about it in procurement terms. There's no informal-use exception. A prompt is a disclosure.
Where the exposure actually comes from
The scenario compliance teams worry about, a structured, deliberate data pipeline pushing PHI to an unvetted vendor, is the one that's easiest to catch, because someone had to build it, document it, and probably get sign-off along the way.
The exposure that's harder to catch is smaller and more human. A nurse pastes a chart note into a chatbot to get help summarizing it. A support rep drops a ticket with a member ID into a tool that drafts a reply. Someone on the billing team uses an AI assistant to reformat a batch of claims and doesn't think about what's in the batch. None of this goes through procurement. None of it shows up in an architecture diagram. It shows up, if it shows up anywhere, in logs nobody's reviewing.
This is the gap the BAA question is meant to catch and usually doesn't, because most compliance teams don't have a way to see it. They can audit contracts. They can't audit what employees are actually pasting into tools in the course of a normal day, at least not without a lot of manual log review that doesn't scale past a handful of vendors.
What the PHI Egress Scan does
We built the PHI Egress Scan as a triage tool for exactly that gap, not a replacement for legal review, a first pass that tells a compliance team where to look.
The workflow is deliberately simple. You paste a representative sample of what's actually heading to a given AI vendor, the kind of prompts or tickets or notes that would realistically get sent, and note whether a BAA is on file for that vendor. The scan then flags content shaped like PHI: Social Security numbers, medical record numbers, dates of birth, ICD-10-style diagnosis codes, insurance member IDs, and keyword patterns like "chart note" or "treatment plan" that tend to co-occur with clinical content even when no structured identifier is present.
Every match gets a confidence score rather than a flat yes/no. That distinction matters more than it might seem. A Social Security number is a nine-digit structured pattern with very few plausible false readings, it's about as close to a definitive PHI signal as free text gets. A phone number, by contrast, could belong to a patient, a vendor, or a delivery driver, and shows up constantly in non-PHI text. Treating those two hits identically would either bury real signal under noise or force teams to manually re-triage everything the tool flags. Weighting them differently means the output roughly tracks how worried a human reviewer should actually be.
The sample itself is scanned in memory and never stored, which matters given what it necessarily contains. Scan history retains only the redacted matches and the source label, enough to show a pattern over time (this vendor, this content type, this frequency) without retaining a second copy of the PHI the scan was built to catch in the first place.
What the scan is not
Two limits are worth stating plainly, because a tool like this is genuinely more useful when its boundaries are clear than when it's oversold.
First, it's regex and keyword matching, not clinical natural language processing. It will catch a diagnosis code. It's much less reliable against a diagnosis described in careful prose with no code attached, "the patient's condition has progressed since the last visit" carries no structured signal a pattern matcher can catch, even though a human reader would recognize it as clinical. That means false negatives on cleverly or casually phrased content are possible, and the flip side, false positives on a support ticket that happens to mention a nine digit number that isn't an SSN, is possible too.
Second, and this follows directly from the first: a flagged result is a prompt for compliance review, not a HIPAA violation determination, and a clean result is not proof the data is PHI-free. The scan narrows where a human needs to look. It doesn't replace the judgment of someone who understands both the regulation and the specific business context of what's in front of them.
Putting the two questions together
"Is the model safe" and "is this vendor's PHI handling compliant" are different questions, and healthcare AI procurement tends to over-invest in the first and under-invest in the second. A capable model behind an unreviewed BAA and unmonitored data flow is still a HIPAA exposure, regardless of how well it performs.
The practical fix isn't complicated, even if it requires more first: for every AI vendor a healthcare organization sends data to, know whether a BAA is in place, and have a way to see, not assume, what's actually going to that vendor. The BAA question is a compliance and legal exercise. The visibility question is where a tool like the PHI Egress Scan is meant to help, by giving compliance teams a fast, honest first read on the second half of that pair before it becomes a bigger problem than a triage flag.