HIPAA Compliant AI Tools: What the Phrase Actually Means

It means less than the badge implies, and the gap is where organisations get into trouble. HIPAA regulates covered entities and their business associates. It regulates organisations and their conduct, not software. There is no federal certification scheme for products, and HHS does not endorse, certify or approve any vendor as HIPAA compliant.

So when a vendor site carries a HIPAA badge, the honest translation is that the vendor believes its product can be used by a covered entity without breaking the rules, provided the covered entity configures and supervises it properly. Sunoh.ai says this out loud in its own FAQ, noting that no hardware or software is HIPAA compliant by itself and that users must meet their own obligations. Every vendor on this page could truthfully say the same thing. Most do not.

What that means in practice is that the burden does not transfer with the purchase order. You remain accountable for the disclosure, the access controls, the workforce training and the incident response. The vendor becomes accountable to you through a contract. Understanding that split is the whole of this page, and the rest of it is detail. Our HIPAA and AI compliance page sets out the underlying obligations in full.

The business associate agreement is the instrument that makes a vendor answerable to you. HHS publishes sample provisions, and every serious vendor's paper starts from something close to them. The clauses that matter for AI specifically go beyond the sample.

• Permitted uses and disclosures. Precisely what the vendor may do with the data, and explicitly whether product improvement counts as a permitted use. This is the clause where model training hides.
• Subcontractors. AI vendors run on other people's infrastructure and often other people's models. You need the list and the requirement that subcontractors are bound by equivalent terms.
• Retention and return or destruction. How long inputs, outputs, audio and transcripts are kept, and what happens at termination.
• Breach notification timing. The rule sets an outer limit; a good agreement sets a shorter internal one, because you have your own clock to meet.
• Audit and evidence rights. The right to see current certification reports, not just to be told they exist.

Read the agreement before the pilot, not after. Pilots are where protected health information moves under no agreement at all, and the fact that it was only a trial is not a defence. The procurement checklist puts these into a form you can send to a vendor.

Four controls carry most of the weight, and all four are checkable before you buy.

Minimum necessary. The tool should receive only the data it needs for its function. An ambient scribe needs the encounter; it does not need the whole chart. A phone agent needs to confirm an identity; it does not need a problem list. Vendors that ask for broad access because it is simpler are asking you to carry their integration cost as risk.

Encryption in transit and at rest. Table stakes now, and any vendor that cannot answer this crisply has told you something important about the rest of its programme.

Access control and audit logging. Who at the vendor can see your data, under what circumstances, and is that access logged in a way you can review. Support access is the usual gap: a support engineer reproducing a bug is looking at real patient data unless the vendor has built for that case.

Segregation. Whether your data is logically separated from other customers, and whether outputs generated for you can surface anywhere else. This becomes the training question, which is important enough for its own section.

Ask in writing, and read the answer twice. This is the single most consequential question in an AI procurement and the one most often answered with a sentence that sounds reassuring while committing to nothing.

The answers you will meet fall into four groups. Some vendors state that customer data is never used for training. Some use de-identified data for training, in which case the de-identification method and who validates it are the questions. Some use data for training with customer consent, where the default setting is what matters. And some say nothing, which in a negotiation means the right is retained.

The reason this deserves its own clause is that model training is generally not a treatment, payment or operations use. If your agreement permits training as product improvement, you have permitted a disclosure for the vendor's commercial benefit, and you should have decided that deliberately rather than discovered it later. Enterprise buyers can usually negotiate this out. Self serve buyers accept the standard terms, which is a real difference between the two ends of every category on this page, and one our scribe pricing comparison traces through to the price.

They tell you a vendor has been examined against a control framework. None of them is a HIPAA certification, because no such thing exists.

• SOC 2 Type 2 reports on whether controls operated effectively over a period, usually six to twelve months. It is the most common claim in this market. Ask for the report and read the scope section, because a report can cover a narrow slice of a company.
• HITRUST CSF is the most demanding of the three in a healthcare context and maps to HIPAA requirements explicitly. Phreesia publicly claims it, which is a meaningful signal.
• ISO 27001 certifies an information security management system. It is a good sign and is not healthcare specific.
• TX-RAMP and similar state programmes matter if you are a public entity in that state and are otherwise a general positive signal.

The practical rule: a certification without a current report and a stated scope is a logo. Ask for the report under a mutual non disclosure agreement, and note the date. Certifications lapse, and a vendor that grew fast in the last eighteen months may be operating well outside the scope its last report covered.

The table above records what each vendor in our registry documents publicly, grouped by category. Three patterns are worth naming.

First, the ambient documentation market publishes more than any other category. Every scribe vendor we track publicly documents a business associate agreement, which reflects a market that has been through hundreds of hospital security reviews and learned what buyers ask. Compare the same column for the prior authorization vendors, where three of five publish nothing, and the maturity difference is visible.

Second, published pricing and published compliance detail correlate loosely with each other and strongly with self serve distribution. Vendors selling to individual clinicians publish because they have to; vendors selling to health systems negotiate instead. Neither is better, but they demand different diligence from you. The prior authorization comparison, the phone agent comparison and the patient intake comparison each work through their own category in detail.

Third, voice is the category where the gap between what is published and what matters is widest. A scribe's risk is largely retention and training. A phone agent's risk includes what it will say to an unverified caller in real time, and no vendor publishes that behaviour.

Ten questions, in writing, before money moves. The written answers are the artefact; a demo is not.

1. Will you sign a business associate agreement, and may we see your standard form now?
2. Is our data used to train or improve your models, in identified or de-identified form?
3. Which subprocessors and model providers touch our data, and where are they located?
4. How long are inputs, outputs, audio and transcripts retained, and what happens at termination?
5. Which of your staff can access our data, under what conditions, and is that access logged?
6. What certifications do you hold, what is the scope, and when was the last report issued?
7. How quickly will you notify us of a suspected breach, and through which channel?
8. Where does the data physically reside?
9. What happens to our data and our configuration if you are acquired?
10. Can we export our data, in what format, and at what cost?

Question nine is asked least and matters more each year, because this market consolidates. If you want these run as a structured assessment against your own risk register, that is what our AI governance and compliance work covers, and vendor selection sequences it before you are emotionally committed to a product.

Plan for it before it happens, because the clock starts at discovery and not at the point you finish investigating. Under the HIPAA Breach Notification Rule, a covered entity must notify affected individuals without unreasonable delay and no later than sixty calendar days after discovery of a breach, and a business associate must notify the covered entity within the same outer limit. Breaches affecting five hundred or more individuals carry additional notification obligations to HHS and to the media.

The AI specific complication is discovery. A model that includes another patient's information in a note, or a phone agent that discloses to an unverified caller, may not trigger any alert. It surfaces when a human notices. That is why your acceptance testing should include deliberate probing for these failure modes, and why the first month of any deployment needs a review process rather than a dashboard.

Decide in advance who at your organisation owns the call, what evidence the vendor must supply and how fast, and how you would reconstruct what the tool did. If the vendor cannot produce an audit trail of what it processed and returned, you cannot investigate, and the sixty days will pass regardless.

Start with an inventory, not a purchase. Most organisations already have AI in the building, usually because a clinician signed up for a free scribe tier or a department bought a tool on a card. Knowing what is already processing patient data is the cheapest risk reduction available to you, and it is usually uncomfortable reading.

Then set a standard that applies to everything, so each purchase is not renegotiated from first principles: a signed agreement before any pilot, a written model training position, retention terms in the contract, and a named owner for every tool. Attach it to your procurement process rather than to an individual, so it survives that person's departure. The AI readiness assessment gives you a starting picture, and the ambient documentation use case shows what that standard looks like applied to the tool most organisations buy first.

Organisations that do this well are not the ones with the strictest policy. They are the ones whose policy is short enough that a department head can follow it without calling legal, and specific enough that a vendor cannot answer it with a badge.