AI Tools Healthcare Practices US

An AI tool that listens to a patient session, drafts clinical notes, or handles scheduling and intake is processing protected health information the moment it touches any of that data. That single fact decides almost everything about how a US healthcare practice needs to evaluate and roll out an AI tool, and it's the step a lot of practices skip when a demo looks good and the sales team is moving fast.

The plain-English answer

AI tools are not banned from healthcare practices, and plenty of small US practices use them well. What HIPAA actually requires is narrower and more specific than most vendors' marketing pages let on: if the tool creates, receives, maintains, or transmits protected health information (PHI) on your behalf, the vendor is legally a business associate, and needs a signed business associate agreement before any real patient data goes near it. A practice that skips this step is in violation the moment the first patient encounter is processed, whether or not anything actually goes wrong.

Why this matters for your business

A 10-clinician allied health clinic evaluating AI scribe tools is a genuinely common position right now, documentation time is one of the biggest drains on a small practice's capacity, and the tools promising to fix it are improving fast. The risk isn't that AI scribes don't work, most of the well-known ones work reasonably well. The risk is signing up for one on a free trial, feeding it real patient sessions to test it, and only checking the BAA question after the practice is already dependent on the workflow.

The financial exposure is real and not hypothetical. The HHS Office for Civil Rights has settled HIPAA cases for significant amounts where the only substantive violation was a missing business associate agreement, no breach, no leaked data, just the absence of the required paperwork before PHI was shared with a vendor. A signed BAA alone doesn't guarantee compliance either, your practice remains responsible for a business associate's non-compliance, which is exactly why the vetting question matters more than the contract signature on its own.

This isn't a reason to avoid AI tools in a healthcare practice, plenty of well-run clinics have adopted them without incident. It's a reason to make the BAA question part of the sales conversation from the first call, not something raised after the team has already built the tool into daily workflow. A vendor genuinely built for healthcare will have an answer ready without needing to check with legal, that responsiveness is itself a useful signal about how seriously the company takes the requirement.

What US healthcare privacy law actually says

The relevant framework is HIPAA, administered and enforced by the HHS Office for Civil Rights (OCR). HIPAA's structure defines a covered entity (a healthcare provider, like your practice) and a business associate (any vendor that creates, receives, maintains, or transmits PHI on the covered entity's behalf). The moment an AI tool processes a patient encounter, whether that's transcribing a session, drafting a note, or scheduling around clinical information, the vendor providing that tool is a business associate under HIPAA. See HHS's own guidance on covered entities and business associates for the formal definitions.

Because the PHI an AI scribe touches is electronic, the HIPAA Security Rule also applies in full, meaning your practice's HIPAA Security Risk Analysis should include the AI tool: how it stores audio or transcripts even briefly, where that data is processed, and whether any of it is used to train the vendor's underlying model. That last point is genuinely one of the most commonly overlooked BAA gaps, a vendor can sign a standard BAA and still reserve the right to use de-identified interaction data for model training unless the agreement explicitly addresses it.

State-level health privacy laws on top of HIPAA

HIPAA isn't the only layer to check. A growing number of US states have passed their own health data privacy laws that apply on top of HIPAA, and some of them cover a broader category of "consumer health data" than HIPAA's definition of PHI, catching wellness and health-adjacent information that a traditional healthcare privacy law wouldn't. Washington's My Health My Data Act is the most-cited example, and other states have introduced similar frameworks since. These laws matter specifically for AI tools because some cover data types an AI scribe or intake tool might touch even when it isn't handling clinical PHI directly, appointment scheduling patterns, wellness questionnaire answers, or app-based intake forms.

The practical takeaway isn't that every practice needs a state-by-state legal review before adopting an AI tool. It's that "we checked HIPAA" isn't automatically the complete answer anymore in every state, and it's worth a direct question to your AI vendor about which state privacy frameworks they've built compliance for, not just whether they're "HIPAA compliant" as a blanket claim.

What this looks like in practice

Picture the practice manager at a 10-clinician allied health clinic, comparing two AI scribe tools that both look strong in the demo. One vendor sends over a signed, healthcare-specific BAA on request, with clear language about where audio is stored, how long transcripts are retained, and confirmation that patient data isn't used for model training. The other vendor's sales team says a BAA is "available on the enterprise plan" and directs the question to a form with no timeline for a response.

That second answer is the moment to stop, not a detail to chase up after signing. A vendor who treats the BAA as an enterprise-tier add-on rather than a standard requirement for handling PHI is signalling how seriously they take the obligation generally. The practice manager who catches this during evaluation, before a single real patient session goes through the tool, avoids the exact scenario OCR has settled cases over: PHI processed by a vendor with no BAA in place, discovered only after the fact.

There's a second, quieter evaluation step worth doing at the same time: asking each clinician what they'd actually want flagged if the AI tool got something wrong. An AI scribe that mishears a medication name or drops a detail from a session is a different kind of risk than a missing BAA, and it's one no contract fixes on its own. Practices that get the most value from AI scribes build in a quick clinician review step for the first few weeks of use, not because the tool is unreliable, but because catching a transcription error early is far cheaper than finding one in a chart months later.

What you can do about it

None of this needs to slow adoption down significantly, a proper vendor evaluation for an AI scribe tool usually takes a few days of back-and-forth, not weeks. The practices that end up with a real problem are almost always the ones that skipped the evaluation entirely because a demo looked convincing, not the ones that took the extra few days to get it right.

A short evaluation process catches nearly everything that matters before a vendor gets anywhere near real patient data:

• Ask for a signed business associate agreement before any trial that involves real patient sessions, not a generic privacy policy or terms of service.
• Confirm in writing whether the vendor uses your data, even de-identified, to train its underlying AI model, and require an opt-out if training use is on by default.
• Ask exactly what happens to audio recordings after a transcript is generated: are they deleted, and on what schedule.
• Include the AI tool in your practice's next HIPAA Security Risk Analysis, treat it as part of your technology footprint, not a separate category.
• If a vendor hedges, delays, or treats the BAA as a premium add-on, treat that as a disqualifying answer and move to the next option.

For a broader vendor-vetting process that applies beyond healthcare specifically, see our AI vendor due diligence checklist. If your practice includes allied health clinicians using AI for patient correspondence specifically, see ChatGPT for allied health for the documentation-specific version of this question.

Related reading: our AI governance by region.

Try our free AI Tool Selector to get a personalised AI tool recommendation for your business.

What exactly is a HIPAA business associate agreement?

A BAA is a legally required contract between a healthcare provider and any vendor that handles protected health information on its behalf. It sets out how the vendor will protect that data, what it can and can't do with it, and what happens if something goes wrong. Without one, using an AI tool with real patient data is a HIPAA violation regardless of whether any data is actually exposed.

Can we test an AI scribe tool with a real patient session before the BAA is signed?

No. The BAA needs to be in place before any protected health information reaches the vendor's systems, including a trial or demo. If you want to test a tool's quality without a BAA in place, use a fabricated or de-identified test session, not a real patient encounter.

Does a signed BAA mean the vendor is fully HIPAA compliant?

Not on its own. HHS guidance is explicit that a covered entity remains responsible for a business associate's non-compliance even with a signed BAA in place. Treat the BAA as the starting point for due diligence, not the end of it, and check the vendor's actual data handling practices, not just the contract language.

Are free or consumer versions of general AI chatbots ever safe to use with patient information?

Generally no. Consumer-tier AI tools not built for healthcare typically don't offer a BAA at all, and often reserve the right to use conversation data for model training. Reserve any general-purpose AI tool for administrative tasks that never involve real patient information, and use a healthcare-specific, BAA-backed tool for anything that does.

What should we check about where the AI tool stores audio and transcripts?

Ask specifically how long audio recordings are retained, whether they're deleted after a transcript is generated, and where the data is physically stored and processed. A vendor that can't answer these questions clearly and in writing hasn't built its product with healthcare's requirements in mind, regardless of how good the transcription quality is.