The HIPAA Checklist to Send Before You Book an AI Scribe Demo

Because after the demo you are no longer neutral. Somebody in the room will have liked it, a clinician will have said it looked good, and the compliance questions arrive as obstacles to a decision people have already half made.

Sent first, the same questions cost nothing and sort the market quickly. A vendor that has been through health system security review answers within a day, usually with documents attached. One that has not will take a week and send marketing copy. That signal alone is worth the email.

It also changes the demo. Vendors who know you have read their data terms demo differently, and the conversation starts several levels above the feature tour.

Five questions, and ask for the document rather than a description of it.

1. Will you sign a business associate agreement, and may we see your standard form now?
2. Which legal entity signs it, and where is that entity established?
3. Which subprocessors are covered, including the providers of any underlying models?
4. What is your breach notification timeline to us, in hours?
5. What audit rights do we have, and has any customer ever exercised them?

The subprocessor question is the one most often answered vaguely. An ambient documentation product typically involves a cloud provider, sometimes a separate speech service and sometimes a separate model provider. All of them touch protected health information, and all of them need to be flowed down.

Getting a business associate agreement signed is the easy part. Most vendors in this category will sign one. The traps are in what the signed document covers, and four of them come up often enough to be worth checking before you rely on it.

The entity that signs is not the entity that operates. Companies in this market restructure and get acquired often, and the agreement in front of you may name a holding company while the product runs inside a subsidiary or a recently bought brand. Ask which legal entity operates the service, then make sure that entity is either the signatory or is bound through the subprocessor terms.

The agreement covers the product but not the pilot. Trials, sandboxes and proof of concept environments get carved out or simply forgotten, and a pilot is exactly where real audio starts flowing before anyone has read the terms. If the pilot touches patient information, the agreement has to cover the pilot, in writing, before the first clinic.

Support access is left undefined. An engineer looking at a failing transcript is making a use or disclosure of protected health information. That is permitted and often necessary, but the agreement should say who may do it, under what controls, and whether it is logged. Silence in the document is not the same as a prohibition in practice.

Termination says nothing about the model. Deletion clauses are almost always written about records and databases. If the vendor trained on your data, deleting the records does not remove what the model learned from them. Either you decline the training right at the start or the termination clause has to address it explicitly, and vendors rarely volunteer that distinction.

None of this shifts as much risk as it looks like it does. HHS treats business associates as directly liable for a defined set of HIPAA obligations, so a weak agreement leaves you exposed on both sides of it. Our HIPAA and AI page sets out which duties land where.

Almost nobody building an ambient documentation product builds the whole stack. A typical chain has four links, and each link is a separate company with its own terms.

1. The application vendor, whose name is on your contract.
2. The cloud provider hosting the service and storing the audio.
3. A speech recognition service, which may or may not be the same company.
4. A model provider that turns the transcript into a structured note.

All four need to be flowed down under the agreement, and all four are places where retention and training terms can differ from the ones you were shown. A vendor can tell you honestly that it does not train on your data while sitting on a model provider whose default terms say something else. So the question that separates the answers is not whether the vendor trains on your data. It is which of its subprocessors could, under their current terms, and what the vendor has contracted to prevent.

Ask for the subprocessor list as a document rather than as a sentence in an email, and ask how you will be told when it changes. A change of model provider is a change of subprocessor. It happens more often in this category than in any other, and the notice usually arrives as a product announcement rather than as a contractual one. Ask whether you have any right to object when it does.

Then check where each link sits. A data residency commitment made by the application vendor does not automatically bind the model provider underneath it, and that gap tends to surface during a security review rather than before one.

This is where the answers vary most between vendors, and where assumptions are most often wrong.

1. Is raw audio retained after the note is drafted, and if so for how long?
2. Can we configure retention, or is it fixed?
3. Is our data used to train shared models, and can we decline without losing function?
4. If de-identification is claimed, by which method, and who verified it?
5. Are transcripts and model prompts logged, and who at your company can read them?
6. What happens to everything at termination, and how quickly?
7. In which country is data stored and processed?

Question five surprises people. Support access to logs containing clinical conversations is normal and often necessary, but it should be controlled, logged and disclosed rather than discovered.

Compliance and safety are separate reviews with separate approvers, and the second one is easy to skip because nobody owns it.

1. Does the product ever suggest a diagnosis, an order or a treatment, or does it only draft what was said?
2. What stops a note being signed without being read?
3. How does the product behave when audio quality is poor, and does it flag low confidence?
4. What happens with multiple speakers, accents and languages other than English?
5. Has the product been evaluated outside primary care, and can you share how?

The first question matters more than it looks. A tool that only drafts what was said sits in a different regulatory position from one that recommends, and the answer should be in writing rather than in a sales call.

HIPAA is the floor rather than the ceiling. Three states now impose duties that can reach a documentation tool, and the trigger is usually what the tool produces for the patient rather than what it drafts for the clinician.

California. AB 3030 has been in force since January 1, 2025 and covers generative AI used in patient communications about clinical information. A draft note that a licensed provider reads and reviews before it goes anywhere falls inside the statute's read and reviewed exception. An after visit summary generated from that note and sent to the patient unreviewed does not, and it needs a disclaimer plus instructions for reaching a human. Most scribe deployments start on the safe side of that line and drift across it the day somebody switches on patient facing summaries. The detail is on our California healthcare AI page.

Texas. HB 149 took effect on January 1, 2026. Where an AI system is used in relation to a health care service or treatment, the provider has to disclose that to the patient by the date treatment is first provided. Note who that binds. The duty is yours, not the vendor's, and no procurement document discharges it. See the Texas page.

Utah. The AI Policy Act, as rewritten in 2025, requires a person providing services in a regulated occupation to disclose proactively in a high risk interaction, and medical advice is named as high risk. Licensed clinicians are in scope. See the Utah page.

None of these are vendor questions, which is exactly why they get missed in a procurement that is otherwise thorough. Add one line to the checklist about your own organisation: in every state where we practise, who tells the patient, at what point, and in what words. The regulations index tracks the rest of the set.

Three questions that are not about compliance at all but predict how the first year goes.

1. What does setup require from us, in hours, in week one?
2. Who do we contact when it fails during a clinic, and what is the response time?
3. What does your onboarding look like for a clinician who is not enthusiastic about this?

The third is the honest test of whether a vendor has deployed at scale. Enthusiastic early adopters make any product look good. The rollout is decided by everyone else, and vendors who have done it have a real answer.

Twenty questions, grouped, with the reason each one earns its place. Print it, take it into procurement, and write the vendor's own words in the column you add on the right.

Add two columns of your own: the answer in the vendor's words, and the date they gave it. Both matter later. A retention answer given in March and quietly revised in September is only visible if somebody wrote down what was said in March.

If you have room for a third column, score clarity separately from content. A vendor that returns all twenty answers in one document has been asked before, and that is worth more than any single answer on the list.

Put them in a table, keep the vendor's own words, and keep the date. Six months later, when someone asks why you chose what you chose, that table is the answer, and it is also what a regulator would want to see.

Score on clarity as well as content. A slightly worse retention policy stated plainly is a better sign than a better one you had to extract over three emails, because it tells you how the relationship will run when something goes wrong.

Then decide before the demos rather than after. Vendors who fail the compliance screen do not get a demo slot, which saves everyone time and stops a good product tour from overriding a bad data policy.