AI Scribes and HIPAA Compliance: A Framework for Evaluation

I've watched three mid-sized medical groups roll out AI medical scribes in the past 18 months. All three started with the same assumption: if the vendor says they're HIPAA compliant, that's enough. Two of them discovered during their breach notification drills that the vendor's idea of compliance looked nothing like theirs. The third caught it during contracting, but only because their general counsel flagged terms that would have left the practice holding all the liability.

The problem isn't that AI medical scribe vendors are lying about HIPAA compliance. Most aren't. The problem is that "HIPAA compliant" has become meaningless marketing language. A vendor can truthfully claim compliance while simultaneously maintaining terms that expose your practice to regulatory risk, operational chaos, and breach liability you never agreed to carry.

This article walks through a framework for evaluating AI medical scribe HIPAA compliance that goes beyond the marketing deck. These are the questions I ask vendors, the contract terms I demand, and the red flags that tell me to walk away.

The Business Associate Agreement Is Table Stakes, Not the Finish Line

Every AI medical scribe vendor will offer to sign a Business Associate Agreement. That's expected. What matters is what's in it and what happens when things go wrong.

The first thing I look at is the BAA's liability cap. I've seen vendors propose BAAs with liability caps at the annual contract value—sometimes less. If you're a practice with 50,000 patient records and the vendor has a $25,000 liability cap, you're self-insuring against a breach that could cost millions in notification, credit monitoring, regulatory fines, and litigation. That's not a partnership; that's offloading risk.

I want to see either no cap or a cap that reflects the actual exposure. If the vendor pushes back, I ask what their professional liability insurance covers and whether it specifically includes HIPAA breach response. Most don't have a good answer. Some don't carry coverage at all beyond general liability.

The second issue is breach notification timelines. HIPAA requires notification to affected individuals within 60 days of discovery. The BAA should require the vendor to notify you within 24 to 48 hours of discovering a breach, not when it's convenient or after they've finished their internal investigation. I've reviewed BAAs that gave the vendor ten business days to notify the covered entity. That leaves you almost no time to investigate, make decisions, and execute notification before the clock runs out.

Third is data retention and destruction. When the contract ends, what happens to the PHI? I want specific commitments: data deleted within 30 days, written certification of destruction, and an audit right to verify. The number of vendors who don't have a documented data destruction process is surprising. If they can't describe how they'll delete your data when you leave, they probably can't describe how they're protecting it while you're a customer.

Fourth: subcontractors. AI scribes often rely on third-party cloud infrastructure, transcription services, or AI model providers. The BAA must require that any subcontractor handling PHI also signs a BAA and meets equivalent security standards. And you need the right to know who those subcontractors are. I've seen vendors refuse to disclose their AI model provider on "proprietary grounds." That's a non-starter. If they won't tell you who's processing your patients' data, you can't evaluate the risk.

Finally, audit rights. You should have the right to audit the vendor's compliance, either directly or through a third party. If the vendor resists, they can provide a SOC 2 Type II report. But it has to be recent (within the past 12 months), and the scope has to cover the specific services you're using. A SOC 2 report for the vendor's core platform doesn't tell you anything about the AI scribe module they bolted on six months ago. I discuss some of these dynamics in more detail in Do AI Vendors Need to Sign a BAA? The Answer Is More Complex Than You Think, which covers when and how BAAs apply to AI vendors more broadly.

Where the Data Actually Goes

Here's the question that separates serious vendors from those running on marketing fumes: "Where does the PHI go, in what format, and who can access it?"

An AI medical scribe records patient-clinician conversations, transcribes them, processes them through a language model, and generates clinical documentation. At every step, PHI is moving somewhere. You need to know where.

Start with the recording. Is the audio captured on the clinician's device, uploaded to the vendor's cloud, or streamed in real time to a third party? If it's uploaded, where is that server located? U.S.-based hosting doesn't automatically mean U.S.-based access controls. I've reviewed architectures where the audio landed on AWS in Virginia, but the vendor's engineering team in Eastern Europe had root access to the entire environment.

Next, transcription. Is the vendor using their own transcription engine, or are they sending audio to a third party like Google, AWS, or Microsoft? If it's a third party, is that party operating under a BAA? Some vendors use the consumer versions of these transcription APIs, which explicitly disclaim HIPAA compliance in their terms of service. That's a violation waiting to happen.

Then there's the AI model. Is the PHI being sent to a third-party LLM like OpenAI's API? If so, what tier of service? OpenAI's enterprise tier offers a BAA and claims not to train on customer data. The standard API does not. If your vendor is sending PHI to a non-BAA LLM, they're creating a breach every time they call the API. This is a problem I see more often than I should, and it's one I wrote about in ChatGPT in Healthcare: HIPAA Risks and How to Manage Them.

Finally, where is the output stored? The generated clinical note contains PHI. If it's being stored in the vendor's environment before it's pushed into your EHR, that environment needs to meet HIPAA standards. If the vendor keeps a copy for "quality improvement" or "training," you need to know how long they keep it, who can access it, and what safeguards are in place.

Data Flow Transparency

The best vendors will give you a data flow diagram that shows every system, every API call, and every place PHI lands. They'll label which components are in-scope for their SOC 2 audit, which operate under a BAA, and which don't. If a vendor can't produce this diagram, they either don't know their own architecture or they're hiding something. Either way, that's not someone you want processing your patients' data.

Model Training and Data Use Restrictions

One of the stickiest issues with AI medical scribe HIPAA compliance is model training. Vendors want to improve their models. That means training on real data. Your data.

The pattern I see most often: the vendor's BAA prohibits using PHI for purposes other than providing the service, but the terms of service reserve the right to use "de-identified data" for research, development, and training. The problem is that the vendor decides when data is de-identified, using their own process, with no obligation to get it right.

HIPAA's de-identification standard is high. You either follow the Safe Harbor method (remove 18 categories of identifiers and have no actual knowledge that remaining information could identify individuals) or get a statistical expert to certify that re-identification risk is very small. Most vendors do neither. They strip names and medical record numbers and call it good. That's not de-identification under HIPAA; it's a limited data set at best. And if it's a limited data set, it's still PHI, and using it for training violates the BAA.

Ask the vendor directly: "Will you use any data from our account to train your models?" If the answer is yes, ask to see their de-identification process and the expert determination or Safe Harbor compliance documentation. If they can't produce it, the answer should be no.

If they insist on using your data for training, the contract should require that you opt in, not opt out. And it should specify the de-identification methodology and give you the right to audit compliance. Anything less is the vendor taking a compliance risk and putting it on you.

Access Controls and Session Recording

AI scribes operate in real time during patient encounters. That creates unique access control challenges that don't exist with traditional transcription services.

First, who has access to live sessions? If the vendor's support team can listen to patient-clinician conversations in real time for "quality assurance," that's a problem. Those support personnel need to be trained on HIPAA, subject to the same confidentiality obligations as your staff, and their access needs to be logged. But more fundamentally, I want to know why they need live access at all. If it's for debugging, they should be reviewing recorded sessions on a sampled, as-needed basis, not monitoring live.

Second, session recordings. If the vendor is keeping copies of the audio or transcripts, how long are they retained, where are they stored, and who can access them? I've seen vendors retain everything indefinitely for "continuous improvement." That's a data retention policy written by product managers, not compliance officers. The longer you keep PHI, the longer it's a target and a liability.

The principle here is minimum necessary. The vendor should access and retain only what's required to deliver the service. Anything beyond that is scope creep and risk accumulation.

Credential Management and MFA

How does the clinician authenticate to the scribe app? If it's username and password, that's a red flag. Multi-factor authentication should be mandatory. If the vendor offers MFA as an optional "enterprise feature," walk away. This is basic access control, not a premium add-on.

Also ask about session timeout and device management. If a clinician's phone is lost or stolen, can you remotely revoke access? Can you see which devices are logged in and when they were last used? These are standard mobile device management controls, and they matter just as much for AI scribes as they do for EHR access.

Encryption Standards and Key Management

Every vendor will tell you data is encrypted. The question is how, where, and who controls the keys.

Data should be encrypted in transit using TLS 1.2 or higher. Anything less is outdated and vulnerable. Data should be encrypted at rest using AES-256 or equivalent. The vendor should be able to tell you exactly what encryption they're using without hedging or pointing to a generic "industry-standard encryption" line in their marketing materials.

Key management is where it gets interesting. Who holds the encryption keys? If the vendor controls the keys and an attacker compromises the vendor's environment, the attacker has everything. Some vendors offer customer-managed keys, where you control the key through a service like AWS KMS. That adds complexity, but it also means that even if the vendor's environment is compromised, the attacker can't decrypt your data without your keys.

I don't require customer-managed keys for every engagement, but I want to know the option exists. If a vendor doesn't support it and can't explain their key rotation and access policies, they haven't thought through their encryption architecture beyond checking a compliance box.

Incident Response and Breach Notification Process

At some point, something will go wrong. A misconfigured S3 bucket, a compromised credential, a ransomware attack, a rogue employee. The question isn't if; it's when and how the vendor responds.

Ask the vendor to walk you through their incident response plan. Not the high-level "we take security seriously" summary—the actual plan. What's the escalation path? Who gets notified and when? How do they determine whether an incident is a breach under HIPAA? How do they conduct forensics? What's their communication protocol with customers?

If they don't have a documented incident response plan, that's disqualifying. If they have one but it doesn't specifically address HIPAA breach notification timelines and requirements, that's almost as bad. You're trusting this vendor to handle your patients' data in a crisis. They need to know what to do before the crisis happens.

Also ask about their breach history. Have they had any security incidents in the past three years? If yes, what happened, what was the root cause, and what did they change afterward? A vendor that's never had an incident is either very small, very new, or not telling the truth. A vendor that's had incidents and learned from them is more trustworthy than one that pretends they're invulnerable.

Tabletop Exercises

For critical vendors, I sometimes ask to run a tabletop exercise. We simulate a breach scenario and walk through the response together. It's the fastest way to find out whether their incident response plan is real or aspirational. The vendors who agree to this are usually the ones who have their act together. The ones who deflect or claim it's not necessary are the ones I worry about.

Contract Terms That Shift Risk

Beyond the BAA, the master service agreement often contains terms that reallocate risk in ways that aren't obvious until something breaks.

Look for indemnification clauses. Does the vendor indemnify you for their HIPAA violations, or do you indemnify them for your misuse of their platform? I've seen contracts where the customer indemnifies the vendor for any regulatory fines resulting from the customer's use of the service. That turns the liability model upside down. If the vendor has a breach and HHS fines you, you're left holding the bag while the vendor walks away.

Check the termination and data portability terms. If you terminate the contract, how long do you have to export your data? What format is it provided in? Can you get the raw audio, the transcripts, and the generated notes, or just the final output? If the vendor controls the format and the timeline, you're at their mercy during a transition. I want at least 60 days of post-termination access and data export in a standard, non-proprietary format.

Look at service level agreements and remedies. If the vendor has an outage and your clinicians can't document patient encounters, what's the remedy? Is it a service credit, or is it actual liability for the business disruption? A 10% service credit doesn't help if you're paying locum tenens to hand-write notes for three days because the AI scribe is down.

Finally, look at modification and update terms. Can the vendor change the terms of service or the BAA unilaterally, or do they need your consent? Some vendors reserve the right to modify terms with 30 days' notice. If they change the data use terms to allow model training and you don't notice, you're stuck unless you terminate the entire contract.

Questions to Ask During the Sales Process

Here's the list I use when evaluating an AI medical scribe vendor. These aren't gotcha questions. They're basic diligence. A competent vendor should be able to answer all of them without escalating to legal or getting defensive.

• Where is PHI stored, processed, and transmitted? Get specifics: cloud provider, region, data centers. "The cloud" is not an answer.
• Who has access to PHI in your environment, and what access controls are in place? I want to know about employees, contractors, and third-party service providers.
• Do you use third-party AI models or transcription services? If so, which ones, and do they operate under a BAA? If they're evasive, that's a red flag.
• What is your data retention policy, and how do you handle data destruction at the end of the contract? Get it in writing.
• Will you use our data to train your models? If yes, what's the de-identification process? If no, can we add a contractual prohibition?
• What encryption do you use for data in transit and at rest? Ask about protocols, key lengths, and key management.
• What is your breach notification timeline, and what's your incident response process? If they can't walk you through it, they don't have one.
• Can we review your most recent SOC 2 Type II report? What's the scope and date? If they don't have one or won't share it, that's a problem.
• What are the liability caps in the BAA, and what insurance do you carry? You're trying to understand who's covering the risk if something goes wrong.
• What happens if we need to terminate the contract? How do we get our data, and in what format? This tells you whether you're locked in or whether you have real portability.

If the sales team can't answer these questions and has to loop in someone from legal or engineering, that's fine. What's not fine is if no one can answer them or if you get contradictory answers from different people at the same company. That tells you the organization doesn't have alignment on how they handle PHI, and that's a governance failure.

Red Flags That Should End the Conversation

Some issues are negotiable. Others aren't. Here's what makes me walk away:

The vendor won't sign a BAA or wants to delay it until after contract signature. Non-starter. If they're processing PHI, the BAA is mandatory from day one. Any delay is either ignorance or an attempt to limit their liability exposure. Either way, it's disqualifying.

The vendor can't or won't disclose where data is processed or who their subcontractors are. You can't assess risk you can't see. If the vendor considers basic architecture transparency to be proprietary, they're not serious about compliance.

The vendor uses consumer-tier APIs or services that explicitly disclaim HIPAA compliance. I've seen this with transcription APIs and LLM services. If the upstream provider's terms of service say "not for use with PHI," and your vendor is using it anyway, they're creating a violation every time they call that API. You don't want to be the customer who discovers that during an OCR audit.

The BAA has a liability cap lower than your potential exposure. If the vendor caps liability at $50,000 and you have 100,000 patient records, the math doesn't work. You're self-insuring a risk that could run into the millions.

The vendor doesn't have a documented incident response plan or won't share it. This means they're making it up as they go. When a breach happens, you'll be the one dealing with the chaos while they figure out what to do.

The vendor resists or refuses audit rights. If they won't let you audit and won't provide a recent, in-scope SOC 2 report, you have no way to verify their controls. You're taking their word for it. That's not diligence; it's hope.

The terms of service allow unilateral changes to data use or privacy terms. If the vendor can change the rules mid-contract and your only remedy is to terminate, you've given them leverage you shouldn't give.

What Good Looks Like

In my experience, vendors who have their HIPAA compliance together share a few characteristics.

They're transparent about their architecture. They'll give you a data flow diagram, tell you which subcontractors they use, and explain how encryption and access controls work. They don't hide behind "proprietary technology" when you ask basic security questions.

They have recent, in-scope third-party audits. A SOC 2 Type II report from the past 12 months that covers the AI scribe product, not just the company's general infrastructure. Bonus points if they also have HITRUST certification, though that's still rare in the AI scribe space.

They separate production and development environments, and they don't use customer PHI for testing or training without explicit, documented consent and proper de-identification.

They have a real incident response plan that includes HIPAA breach notification timelines, and they've tested it. Ideally, they've had a minor incident, handled it well, and can walk you through what they learned.

Their contracts are reasonable. The BAA doesn't cap liability at a token amount. The MSA includes strong data protection terms, clear termination and data export rights, and doesn't try to reallocate all the risk to the customer.

Their sales and technical teams give consistent answers. If the salesperson says one thing and the engineer says another, that's a sign the organization doesn't have its story straight. Good vendors have alignment across the company on how they handle PHI and what their obligations are.

The Strategic Implication for Healthcare Leaders

AI medical scribes have real potential to reduce clinician burnout and improve documentation quality. I've seen them work. But deploying them without rigorous HIPAA compliance diligence is a shortcut that leads to long-term risk.

The challenge is that most medical practices don't have in-house expertise to evaluate these vendors. The office manager is comparing feature lists and pricing. The clinicians are evaluating usability. No one is reading the BAA, asking about subcontractors, or pressure-testing the incident response plan. That's how practices end up with contracts that look good until the vendor has a breach, and then it turns out the liability cap is $10,000 and the practice is on the hook for everything else.

If you're evaluating AI scribes, bring in someone who knows HIPAA. That might be your compliance officer, your attorney, or an outside consultant. It's worth the cost. A few hours of expert review during the contracting phase can save you from a multi-million-dollar problem later.

And if you're a vendor reading this: the bar is rising. Healthcare organizations are getting smarter about AI risk, and the regulatory environment is tightening. OCR has made it clear that covered entities are responsible for their business associates' HIPAA compliance. That means your customers are going to start asking harder questions. The vendors who can answer them will win. The ones who can't will get pushed out. For more on broader AI compliance trends in healthcare, see HIPAA and AI Tools: What Healthcare Leaders Are Getting Wrong.

The opportunity is real. So is the risk. The difference between the two is diligence.