Does a BAA with the AI vendor cover clinical documentation risk?

A Business Associate Agreement is necessary and does not, on its own, control what leaves your environment. The BAA sets the legal terms for how the vendor handles PHI once it arrives. It says nothing about which clinician sent which encounter, whether the prompt carried more identifiers than the task required, or what record exists on your side. Those are request-layer questions, and they need enforcement and audit at the point where the documentation tool calls the model, in addition to the contract.

How does AI clinical documentation create HIPAA exposure?

The exposure is the model call itself. To generate a note, the tool sends the encounter content to an LLM over HTTP, which is a disclosure of PHI. If that call is unauthenticated to a specific clinician, carries more than the minimum necessary, or leaves no independent record, the covered entity cannot demonstrate control over the disclosure. The tool is useful and the risk is real, and both live on the same request path.

What belongs in the boundary and what does not?

A gateway governs the HTTP call between the documentation tool and the model, and the response that returns. Audio capture on the device, the EHR integration, and the provider's internal processing sit outside that boundary. The gateway controls who sent what to the model and produces the audit record. Endpoint and EHR access controls remain separate obligations a documentation program has to meet.

Can the model be blocked from receiving direct identifiers?

Yes. The gateway classifies the outbound prompt against PHI types before it reaches the model, so policy can allow clinical content while redacting a direct identifier or blocking the call when an identifier appears that the task does not require. Because the decision happens inline, the identifier never reaches the model on a blocked or redacted call, and the outcome is recorded either way.

AI Security for Clinical Documentation: Governing the PHI That Reaches the Model

An AI clinical documentation tool works by moving protected health information across the network. An ambient scribe records the visit, transcribes it, and sends the transcript to an LLM with an instruction to produce a structured note. That send is an HTTPS POST to a model endpoint, and the body of it is the patient encounter: symptoms, history, medications, sometimes an identifier. The note that comes back is convenient. The request that produced it is a disclosure of PHI, and HIPAA holds the covered entity responsible for it.

The scale of this is already large and mostly unsupervised. Cloud Radix found that 57% of healthcare professionals use unauthorized AI to process PHI such as SOAP notes and diagnostic plans without a Business Associate Agreement in place. The convenience arrived before the controls, which is the recurring shape of shadow AI in regulated settings.

Draw the boundary around the model call

A gateway governs the HTTP traffic between the documentation tool and the model. It does not govern the microphone, the EHR, or the device.

Inside the boundary:

The tool's HTTP call to the LLM, carrying the transcript or note content.
The model's response returning to the application.

Outside it:

Audio capture on the local device and the EHR write-back. Those are application and endpoint concerns.
The model provider's internal handling once the request is inside their environment, which the BAA and the provider's own controls govern.

The gateway is the control on what leaves for the model and who sent it. Device security and EHR access control are separate jobs that a documentation program still has to do.

Bind every note to a clinician identity

The default deployment authenticates the whole documentation service to the model with one key. Every clinician's dictation reaches the model as the same credential, so an audit cannot say which clinician's encounter was sent, only that the service sent something. HIPAA audit controls under 45 CFR 164.312(b) expect the record to identify activity in systems that handle PHI, and a shared key defeats that at the AI boundary.

Route calls through the gateway and bind each to the clinician identity the application already holds from its own login. Now every prompt that carries PHI is attributable to a person, which is the precondition for both minimum-necessary policy and a usable audit trail.

Enforce minimum necessary on the prompt

HIPAA's minimum-necessary standard says a use or disclosure should be limited to what the task requires. A note-generation prompt frequently carries more than the task needs: a full history when the visit was a follow-up, a direct identifier when a token would do. The gateway classifies the outbound prompt against PHI types and applies policy on the class, so a documentation call can be allowed to send clinical content while a direct identifier is redacted or the call is blocked. Classification happens on the actual request, which is where the prompt-level data lives, not on a document the tool was configured to handle in the abstract.

Produce the audit record a HIPAA review will ask for

Every documentation call produces a decision record: the clinician identity, the PHI class in the prompt, the pass, block, or redact outcome, the policy version, and a timestamp. The record commits before the note returns, on a write path the documentation application does not control. That independence is what separates it from an application log the same tool could write selectively or lose when a session drops. When a review asks what patient data went to which model and under whose authority, that record is the answer, per encounter.

DeepInspect

This is the problem DeepInspect was built to solve. A clinical documentation tool sends PHI to an LLM over HTTP, and DeepInspect sits inline at that boundary between the tool and the model endpoint it calls.

For every request, DeepInspect binds the call to the clinician identity the application supplies, classifies the prompt against PHI types, applies minimum-necessary and per-role policy, and makes a deterministic, fail-closed decision before the transcript reaches the model. Every decision commits a signed, identity-bound audit record before the note returns, on a write path the application never controls, which is the evidence a HIPAA audit control expects. DeepInspect governs the model traffic and does not replace device security or the BAA you still need with any provider that receives PHI. If your organization is running ambient scribes and cannot show which clinician sent which patient's data to which model, let's talk today.