BAAs for AI vendors: what to require before any PHI touches an AI tool

AI tools are moving into healthcare operations faster than many compliance programs can review them. Staff may paste referral notes into chat assistants, vendors may add language models to scheduling and intake products, and product demonstrations may invite a sample file. Each situation calls for a documented data-flow review before protected health information (PHI) moves.

A generic BAA can satisfy HIPAA's required contract elements without addressing every question raised by an AI system. The agreement may say nothing specific about model training, prompt retention, a model subprocessor, or change notifications unless the parties add those protections.

This guide separates the HIPAA-required BAA provisions from additional AI-era contract controls, then gives administrators and compliance leads a practical review workflow. It is operational guidance, not legal advice. Have counsel review the final agreement.

What a business associate agreement is

A business associate agreement is a written contract between a covered entity and a business associate, or between a business associate and its subcontractor, when the latter performs covered functions or services involving PHI. The U.S. Department of Health and Human Services (HHS) publishes both the underlying guidance and sample business associate contract provisions.

The required contract terms address these obligations:

A BAA is a contract; signing one does not by itself establish that a product is configured or operated securely. The contract is the legal foundation. A security review, appropriate configuration, workforce controls, and ongoing vendor oversight remain separate work.

When an AI vendor is a business associate

The analysis turns on the vendor's function and data flow, not on whether the product is described as AI. Ask whether the vendor will create, receive, maintain, or transmit PHI on the organization's behalf while providing its service. If it will, the parties should execute the appropriate BAA before that data flow begins.

Common operational examples include:

• A voice agent that receives patient information while answering calls or booking appointments.
• A document tool that reads referral packets or faxes containing PHI.
• A prior authorization service that processes clinical documentation.
• An EHR-connected assistant that receives patient context.
• An analytics or transcription service that handles identifiable records.

The difference between operational AI and clinical AI may affect other risk questions, but it does not replace the HIPAA data-flow analysis.

If a proposed use relies on de-identified data, document who performs the de-identification and which HIPAA method is used. Have privacy or legal reviewers confirm the data is de-identified before it reaches a vendor that has not executed a BAA. A general writing tool used without patient information may fall outside the BAA workflow for that use, but the organization still needs controls that keep PHI out of the tool.

Terms to review in an AI vendor BAA

The distinction matters because several sensible AI-vendor protections are not standalone clauses that HIPAA expressly requires every BAA to contain. They are negotiated controls that can make the required uses, safeguards, subcontractor, reporting, and termination duties more specific.

HIPAA minimums and negotiated protections are not the same list

AI vendor contract checklist

After confirming that the draft contains the HHS-required provisions, review these AI-specific terms against the proposed data flow and your organization's policies:

1. Model use. State whether the vendor may use PHI to train, fine-tune, evaluate, or improve its own or a third party's models. If the organization does not permit those uses, put the prohibition in the agreement.
2. Service boundaries. Describe the service-delivery uses that are allowed and the approval process for anything outside them.
3. Subprocessor visibility. Request the current subprocessor list, identify which parties handle PHI, and define how changes will be communicated.
4. Retention and deletion. Address prompts, transcripts, audio, logs, and backups, including retention periods and what proof of deletion will be provided.
5. Incident notice. Align the contractual notice process with the organization's own response and notification duties.
6. Assessment rights. Define which security materials can be requested and what assessment rights apply after an incident.
7. Data residency. If organizational policy or another contract requires a location commitment, cover inference, storage, backups, and support access.
8. De-identification. If the vendor proposes product-improvement use of de-identified data, specify the de-identification method, who applies it, and whether the customer permits that use.
9. Termination and survival. Define termination rights and which confidentiality, deletion, and notification duties continue afterward.

Red flags that should stop the conversation

These signals warrant a pause, a written answer, or a different vendor:

• No BAA for the proposed service tier. If the vendor will not execute an appropriate BAA, do not provide PHI for that service.
• Privacy language instead of contract terms. General statements about enterprise privacy do not define permitted uses, subcontractor duties, deletion, or incident notice.
• A "HIPAA certified" product claim. Ask what independent assessment or control evidence the vendor actually means rather than treating the phrase as evidence by itself.
• A settings-page training opt-out. A dashboard control can be useful, but it does not replace the contract position the customer requires.
• No subprocessor transparency. The vendor should be able to identify the parties that handle PHI and explain how equivalent restrictions reach them.
• Pressure to test with real patient data before contracting. Use synthetic data, or data that privacy or legal reviewers have confirmed is de-identified under HIPAA, until the required agreement and review are complete.

The broader process in our guide to evaluating healthcare AI vendors should treat the BAA and data-flow review as an early gate, not the entire diligence program.

How to run the BAA review

1. Classify the data flow. Document what data the tool will receive, where it comes from, where it goes, and which parties can access it.
2. Send requirements early. Give the vendor the HHS baseline and your AI-specific contract positions with the first diligence request.
3. Review the BAA and subprocessor list together. Confirm that the parties doing the processing are covered by the required restrictions and conditions.
4. Focus the redline. Ask counsel to address model use, prompt and transcript retention, deletion, incident notice, and other terms that matter to the actual system.
5. Gate PHI use on the agreement. Keep pilots and demonstrations on synthetic data, or data that privacy or legal reviewers have confirmed is de-identified under HIPAA, until the required BAA is executed.
6. Schedule oversight. Track security evidence, subprocessor changes, and offboarding obligations instead of treating the signed agreement as the last step.

Questions for voice and conversational AI

Voice agents and chat assistants can create several artifacts that contain PHI. If a system records or transcribes calls, review the audio, transcript, extracted fields, logs, and downstream records separately. Each artifact can have its own storage, access, and deletion path.

When reviewing HIPAA considerations for voice AI, ask where recordings and transcripts reside, how long they persist, whether they are used in any model-improvement process, and how the vendor would locate and delete the organization's data. Apply the same questions to conversational AI in healthcare when chat logs contain patient identifiers.

Also review identity-verification behavior. The BAA defines contractual responsibilities, while the product's access and verification design affects how the service handles PHI in daily operation.

The bottom line

When an AI vendor performs a service on your behalf that involves PHI, execute an appropriate BAA before the data flow begins. Start with the provisions HHS requires, then add the AI-specific protections your use case needs. Those may include a model-training prohibition, subprocessor transparency, detailed retention and deletion terms, defined incident notice, assessment rights, and a residency commitment when policy requires one.

A signed BAA is necessary for the covered relationship, but it is not the whole vendor review. Read the contract beside the architecture, configuration, security evidence, and operating workflow.

Frequently asked questions

Sources

• U.S. Department of Health and Human Services: HIPAA for Professionals
• HHS: Business Associate Contracts and Sample Provisions
• HHS: Breach Notification Rule
• HHS: Methods for De-identification of PHI