The AI notetaker nobody vetted

A BCBA started using an AI scribe last month. It is a business associate, it may be training on your clients' sessions, and nobody signed anything. The questions to ask, and what the vendor's answers actually mean.

Last verified: 2026-07-12

A BCBA on your team is drowning in documentation, finds an AI scribe that turns a session into a clean note in nine seconds, and starts using it. It works. Within a month two colleagues are using it too. Nobody hid anything; nobody was asked.

That is how every one of these arrives. Nobody decided to send a child’s session to an AI company. Somebody just found a tool that worked. The compliance question is not whether your clinician did something wrong. It is whether your clinic has any idea where a child’s session audio currently lives.

It is a business associate. That part is not complicated.

A business associate is anyone outside your workforce who creates, receives, maintains, or transmits PHI while performing a function or service for you (45 CFR 160.103). An AI scribe receives session audio or session content and creates clinical text from it. That is two of the four verbs on the first day.

“Nobody decided to send a child's session to an AI company. Somebody just found a tool that worked.”

Which means the ordinary rules apply, with no AI exception anywhere in them: you may disclose PHI to it only after a signed business associate agreement is in place (45 CFR 164.502(e), 45 CFR 164.308(b)), with the required contents (45 CFR 164.504(e)). And the sequence is not negotiable: the BAA precedes the first session, because the impermissible disclosure begins with the first record, not the first invoice. A pilot is not a grace period.

Most reputable clinical AI vendors will sign. Consumer AI assistants and free tiers generally will not, and that refusal is not an obstacle to route around; it is the vendor telling you plainly that PHI is not supposed to be in their product. Believe them.

The question that actually decides it: does it train on your data?

Here is where AI differs from every other vendor on your list, and where a signed BAA can still leave you exposed.

Ask the vendor, in writing: do you use our data to train or improve your models? Three possible answers, and they are not equally acceptable.

No, never, for any customer. Clean. The data is processed to produce your note and is not repurposed. This is the answer enterprise clinical vendors typically give, and it should be in the contract, not just the FAQ.

Only with your permission, and it defaults to off. Workable, if you leave it off and confirm the setting per account. Verify it, because defaults change with product updates and nobody sends an email that says “we turned your children’s sessions back on.”

Yes, we train on customer data. Now you have a problem a BAA does not solve. A BAA permits a business associate to use PHI for the services it performs for you, plus narrow exceptions for its own management and data aggregation (45 CFR 164.504(e)). Improving the vendor’s commercial model is a use for the vendor’s benefit, not a service performed for you, and it is not one of those exceptions. Getting there lawfully would require an authorization from each individual (45 CFR 164.508), which for children means from each parent, for a purpose they would have to be told plainly: we would like to send your child’s therapy sessions to an AI company so it can improve its product. Ask yourself whether you want to send that form home. That question is the answer.

The de-identification escape hatch (45 CFR 164.514) is narrower than vendors imply. You may create de-identified data and let a vendor use it, but session audio is not de-identifiable in any practical sense: voice is a biometric identifier, and names, places, and family details are embedded throughout ordinary conversation. “We only train on de-identified data” deserves a follow-up question about what exactly they think they are de-identifying and how, and if the answer is vague, treat it as a no.

Ask about the plumbing

AI tools are rarely one company. The scribe you signed with may send audio to a speech-to-text service and text to a large model provider, each of which is receiving PHI. Under HIPAA those are subcontractors, and your business associate is required to bind them to the same restrictions (45 CFR 160.103, 45 CFR 164.504(e)).

So the second written question is: who else touches this data? A vendor that can name its subprocessors and confirm its agreements with them is running a real program. A vendor that gets vague at this question is telling you it has not thought about the chain, which means the chain is where your clients’ sessions are.

Two more worth asking while you have their attention: how long do you retain the audio and the transcripts, and can we delete them? And where is the data stored, and is it encrypted at rest and in transit? Retention is the sleeper: a scribe that keeps session audio indefinitely has quietly become the largest repository of raw clinical content your clinic has ever had, sitting somewhere you have never visited.

The recording nobody consented to

One more layer specific to ABA, and it sits outside HIPAA: a scribe that listens to a session is recording a session. HIPAA’s TPO permissions may cover using PHI for treatment documentation, but state wiretap and recording laws are separate, and many states require consent from all parties to record a conversation. A session with a child and a parent in the room is a conversation with parties in it.

That is a state-law question, not a HIPAA question, and this page will not pretend to answer it for your state. But it is a question, and “the AI just listens, it does not really record” is not a legal theory. If sessions are being captured, families should know, in writing, before it happens.

The real finding is not the tool

Every question above is answerable in an afternoon. The uncomfortable part is what the tool’s arrival revealed: a system where a clinician can begin sending children’s sessions to an outside company, in good faith, without anyone asking a single question, and nobody notices for a month.

That is the finding. The AI scribe is not a technology problem; it is a governance gap that happened to be discovered by a technology. The fix is one habit, applied at every new tool, forever: before this touches a client, what does it hold, who else sees it, and have they signed. Put the tool on the vendor list, or take it out of the clinic. Those are the two options, and doing neither is the one that ends up in a settlement.

The short version

  • An AI scribe, summarizer, or transcription tool that receives session content is a business associate; it needs a signed BAA before the first session, not after the pilot.
  • The question that decides everything: does the vendor train its models on your data? A yes without an authorization is a use no BAA can bless.
  • Free tiers and consumer AI assistants generally do not sign BAAs, which is your answer about free tiers and consumer assistants.
  • Ask about subprocessors: the scribe may be sending audio to a model provider, which is a subcontractor that must be bound by the same terms.
  • This is a governance problem before it is a technology problem: the tool arrived without a decision, which is how every one of these arrives.

This article is educational information about the HIPAA regulations, not legal advice. It describes what the rules say; it does not tell you what to do about your specific situation, and reading it does not create an attorney-client or consultant-client relationship. Regulations change, and enforcement positions change with them. For advice on your clinic, talk to a qualified professional.

Sources

New tool, same question, asked before the first session.

Every tool that touches a session belongs on a list with a signed BAA behind it. WiseUpHIPAA keeps the vendor inventory current and shows you honestly which tools are papered and which arrived without a decision.