An AI Scribe’s BAA Does Not Show Where Patient Data Goes

Start with one ordinary encounter: a follow-up visit recorded by a tablet beside the exam-room keyboard. The AI scribe captures speech, converts it into text, sends some representation of that text to a model, generates a draft note, and returns the note for clinician review before it reaches the electronic health record.

That sequence sounds contained. It often is not.

Audio may first pass through a mobile operating system or browser component, then reach a transcription service, an application database, a model provider, an observability platform that records system behavior, and a support tool used to investigate failures. The final note may be the only artifact visible to the clinician, while partial transcripts, model prompts, error traces, and backups remain elsewhere under different retention rules.

A business associate agreement, or BAA, sets contractual duties for a company handling protected health information on behalf of a covered entity. It matters. It does not replace the data map.

Follow the recording, not the product label

Vendor documentation commonly describes an AI scribe as “HIPAA compliant” or says that the company will sign a BAA. Neither statement answers the operational question raised by the tablet in that exam room: which legal entities and technical systems receive data from this particular account, with these settings, in this region?

The first artifact to request is a diagram or written data-flow description covering the deployed product. It should begin at capture and end at deletion, rather than stopping when the draft note appears. Ask the vendor to mark where it stores the original audio, speaker-separated transcript, generated note, model input, model output, user corrections, application logs, support attachments, and backups.

“Model input” deserves close attention. A scribe might send a full transcript to a large language model, or it might split the transcript into sections and send each section with instructions for producing the note. Either way, the model request can contain protected health information even when the model provider never receives the original recording.

The same applies to telemetry, the operational data used to monitor software. A well-designed log may record only an error code and request identifier. A poorly scoped log can capture transcript fragments, prompts, generated text, patient names, or the contents of a failed request. Privacy documentation aimed at end users rarely describes logging at that level, so the practice may need a security questionnaire, architecture document, or written clarification from the vendor.

A generic infrastructure diagram is not enough if the service has optional features. Dictation, ambient recording, automated coding suggestions, EHR export, and human quality review can take different routes. The answer must match the functions the practice will enable.

Read the BAA for the downstream obligation

HIPAA’s business associate contract provision says a business associate must “ensure that any subcontractors that create, receive, maintain, or transmit protected health information on behalf of the business associate agree to the same restrictions and conditions” that apply to the business associate. That requirement appears in 45 CFR 164.504(e).

The wording is useful because it follows the data. A cloud host, transcription provider, model operator, or support platform may qualify as a subcontractor when it handles protected health information for the scribe vendor. The label that the vendor uses in marketing does not decide the issue.

A practice should compare the BAA with the vendor’s subprocessor list, meaning the list of outside companies engaged to process customer data. Check whether the list identifies each company’s function and processing location, whether changes trigger notice, and whether the practice can object or terminate if a new subprocessor changes the risk materially. A list containing only corporate names leaves substantial work undone because it does not show which company transcribes audio, runs inference, stores backups, or receives support tickets.

The BAA should also address permitted uses, safeguards, incident reporting, access to records, return or destruction, and subcontractors. Contract language can allocate responsibility, but it does not prove that a control operates. Evidence comes from settings, architecture, audit material, deletion tests, and records showing who accessed the data.

This distinction matters during procurement. A signed promise is enforceable according to its terms. A feature described as planned, available on a roadmap, or subject to future certification is proposed. It should not be counted as a deployed control.

Test retention one artifact at a time

Return to the exam-room tablet. Suppose the clinician approves the draft and sends it to the EHR. What remains in the scribe application afterward?

“Data is deleted after processing” can mean that the primary audio object is removed while the transcript remains in visit history, a generated note persists for account convenience, and encrypted backups expire on a separate schedule. The phrase can also exclude security logs, fraud-prevention records, legal holds, and support cases. None of those exceptions is automatically improper, but each changes the exposure and should be stated.

Ask for retention periods by artifact and by storage layer. Then determine which periods are fixed, which an administrator can configure, and which require a support request. If zero-retention or shortened retention is available only on a higher-priced plan, that is a procurement cost attached to the privacy design, not an incidental feature difference.

Deletion also needs a verb and an actor. Can a practice administrator delete a visit? Does account closure trigger deletion? Are backups overwritten on a defined cycle?

Can the vendor provide confirmation tied to the customer account? If the practice must open a ticket, support staff and the ticketing platform may receive identifiers or screenshots during the request.

Run a deletion test before broad deployment using synthetic information, which is fabricated data that does not identify a real patient. Record an encounter, generate a note, delete it through the documented method, and verify what disappears from the clinician view and administrative exports. Ask the vendor what remains outside those views and when it expires. The test cannot inspect the vendor’s backend, but it exposes discrepancies between product behavior and procurement answers.

Separate model use from model training

A vendor may state that customer data is not used to train models. That is an important restriction, yet it answers only one use question.

The practice still needs to know whether prompts and outputs are retained by the model provider for abuse monitoring, debugging, service improvement, or legal compliance; whether humans may inspect them; and whether the terms differ between the vendor’s enterprise API agreement and a consumer-facing model service. “No training” does not mean “no storage,” “no human access,” or “no subprocessor.”

Request the exact contractual and technical basis for the claim. Useful evidence includes the relevant model-provider terms, a product-specific privacy statement, the subprocessor entry, and a vendor explanation of retention for inference requests. If the scribe vendor routes traffic among several models, ask whether the route changes by feature, availability, customer region, or administrator setting.

Some vendors reduce exposure by removing direct identifiers before model processing. That control has limits. A clinical narrative can remain identifiable through uncommon diagnoses, locations, dates, family relationships, or quoted conversation, and aggressive removal can damage the note’s accuracy. The practice should learn what is removed, at which stage, and whether the clinician sees the original transcript when correcting the result.

Turn the answers into an approval record

The practical output should be a one-page record for the exact scribe configuration, supported by the vendor documents behind it. Name the capture device, enabled features, EHR connection, storage regions, relevant subprocessors, retention periods, administrator controls, support-access procedure, and incident-notification route. Record document versions or retrieval months because public policies and subprocessor lists change.

Assign an owner to review change notices. A new model provider or support platform can alter the data path without changing the clinician’s screen, which is why the tablet may behave identically while the contractual and geographic route behind it changes.

Access controls belong in the same record. Confirm that the product supports individual accounts, appropriate administrator roles, multifactor authentication, and audit logs showing actions such as recording access, note export, deletion, and support impersonation. An audit log is a time-stamped record of system activity; it is useful only if the practice can retrieve it for the period relevant to an investigation.

If a vendor cannot explain where transcript fragments enter logs, which entity operates the model endpoint, or what survives deletion, pause the deployment rather than filling gaps with the existence of a BAA. The fallback is less convenient but concrete: disable ambient recording, use ordinary dictation with an approved service, or keep clinician-authored notes until the unanswered route is documented.

This checklist is an operational verification aid, not legal or medical advice. HIPAA is also not the only rule that may apply; state privacy, recording-consent, medical-record, contractual, and professional requirements can impose additional constraints.

Questions people ask

Does signing a

BAA make an AI medical scribe HIPAA compliant?

No single contract proves compliance for an entire deployment. A BAA establishes required promises between parties, while the practice still needs to verify configuration, access, retention, subprocessors, incident procedures, and the route taken by audio and derived data. The vendor must also operate the promised safeguards rather than merely describe them.

Does

“no model training” mean the vendor does not retain patient data?

No. A no-training commitment may prohibit using customer content to improve model weights while still allowing temporary storage for inference, security monitoring, debugging, or support. Ask separately about audio, transcripts, prompts, outputs, logs, human review, and backups, then connect each answer to a contract or product-specific document.

Should a practice require immediate deletion of recordings?

That depends on the clinical workflow, correction needs, contractual obligations, and applicable law. Short retention reduces exposure but can remove material needed to review a bad transcript or investigate an incident. The important step is to choose a period deliberately, configure it where possible, and verify how primary storage and backups differ.

What should a practice do if the vendor will not disclose every subprocessor?

Treat the missing information as an unresolved procurement risk. Ask for the company name, function, processing location, data category, and applicable contractual protection for each relevant provider. If the vendor cannot identify who handles the exam-room recording or transcript, keep ambient capture disabled and document why approval was withheld.