Using AI tools with PHI: what a BAA covers and what it does not

BAA availability alone does not establish that a particular AI workflow is covered. Before entering PHI, identify the data involved, the exact feature and plan, the applicable agreement, and every connected destination. Then review settings and access.

HIPAA guides

A BAA is a starting point—not approval for every AI feature

Keep these questions separate:

• Is a BAA available? The vendor offers an agreement under stated conditions.
• Has your organization executed it? Confirm the applicable agreement is in place.
• Does it cover this use? Match the agreement to the service, feature, plan, and workflow being evaluated.

A signed agreement alone does not establish that every AI feature—or the clinic’s overall workflow—is compliant.

Hypothetical clinic example: A clinic already uses a scheduling application. The application introduces an AI summary button. Before enabling it for patient-related content, the clinic checks whether its existing agreement covers that feature, any connected model, and the resulting summaries.

For the broader distinction between an agreement and operational responsibilities, see what a business associate agreement covers.

Map where PHI goes before evaluating the agreement

Start with an ordinary clinic task, not the vendor’s name.

Hypothetical clinic example: A scheduling assistant receives an appointment request, drafts a response, and creates a follow-up task. Review where patient names, appointment reasons, attachments, or other identifying health information might appear. Include generated content, not just the original request.

Use this diagram as an evaluation aid—not as a description of any vendor’s architecture:

Staff input or uploaded file
             ↓
Application and prompt preparation
             ↓
Model service, if used
             ↓
Generated response or summary
             ↓
Conversation history or saved output
             ↓
Connected task app or other destination, if enabled

For every step, record:

• What information enters and leaves?
• Which organization operates that component?
• Where might content, history, or logs remain?
• Which agreement and documentation address that handling?

Identify the application provider, any model provider, and external destinations separately. Do not assume their relationships from the interface alone; request documentation of the actual data flow.

Check the covered plan, AI feature, and service boundaries

Review the vendor’s BAA alongside its covered-services list, AI terms, and trust documentation. Check which documents are incorporated into the agreement and which terms control if descriptions differ. Trust documentation is not necessarily incorporated into the contract.

Compare the service you intend to use with the service named in those documents. If the vendor offers a consumer chatbot, business workspace, developer API, or embedded assistant, ask which offering the evidence addresses. Do not transfer an approval between them without checking.

Use a compact review record:

Field	What to record
Plan	Exact subscription and any eligibility conditions
AI feature	Feature name and intended clinic use
Covered service	Contractual service name and supporting passage
Exclusions	Features, models, data uses, or destinations excluded
Source	Vendor BAA, incorporated list, AI terms, or trust page
Unresolved questions	Missing evidence or conflicting descriptions

Ask whether the proposed AI use requires a separate agreement, addendum, approval, or configuration. These are questions to resolve, not requirements to assume for every vendor.

See how to read a vendor BAA for a broader scope review.

Review training, retention, logs, and human access separately

A statement that data is not used to train models does not, by itself, answer whether the service is covered by a BAA, retains content, creates logs, or permits human access.

Ask separate questions:

• Training: Which data and uses does the commitment address?
• Retention: How long are prompts, outputs, uploads, and history retained?
• Logs: Do operational or troubleshooting records contain submitted content?
• Deletion: What does deletion remove, and what happens to backups?
• Human access: Can support personnel or reviewers access content, and under what conditions?

Ask whether uploaded files, saved summaries, and feedback submissions follow the same rules as ordinary prompts. Do not assume an answer from a general privacy statement.

Hypothetical clinic example: Staff want an AI-generated summary of internal follow-up tasks. Review both the source content and the generated summary: what each contains, where each is saved, and who can access it.

Check connected models, plugins, and automation destinations

Approval of the visible AI interface should not substitute for reviewing connected destinations. Identify every service that receives information and determine which contractual arrangement addresses that transfer.

Hypothetical clinic example: An assistant turns an appointment request into a task in a separate task application. That application is another review point. Do not presume it is covered because the assistant’s provider offers a BAA.

Distinguish a provider’s documented subprocessors from integrations that your clinic enables. Do not assume those relationships create identical obligations—or that the clinic must sign a separate direct BAA with every subprocessor.

Ask:

• Who can enable a connection or change its permissions?
• What content and metadata does it receive?
• Can it retrieve additional information?
• Can the workflow operate without unnecessary transfers?
• What happens if someone changes the connected model or destination?

Use a workflow checklist before staff enter PHI

Build an approval record around the proposed task, not a broad label such as AI vendor approved.

• Use case: Describe the permitted task and intended users.
• Data flow: Identify inputs, outputs, storage, model services, and destinations.
• Agreement: Confirm the applicable agreement has been executed.
• Service scope: Match the plan, feature, and model to supporting documentation.
• Settings: Review training choices, retention, deletion, logging, and connections.
• Access: Define who may use the feature, view outputs, and change settings.
• Exclusions: Record limitations and unresolved questions.
• Staff instructions: Explain permitted uses, prohibited transfers, and escalation.
• Review triggers: Name the changes that require another review.

While coverage questions remain unresolved, use synthetic examples created for testing rather than patient records with names removed. Removing names alone should not be treated as verified de-identification. For this recommendation, synthetic examples means wholly fabricated test content containing no real patient information; the label alone does not establish de-identification.

Staff instructions should be concrete: which feature to use, what information may be entered, where outputs may be saved, and whom to contact if anything changes.

Use patient data security basics alongside this workflow review.

Record the decision and revisit it when the workflow changes

Use yes, conditional, no, or unknown for the documented workflow—not as an inherent property of the vendor.

• Yes: The evidence supports the stated workflow and its documented conditions.
• Conditional: Approval depends on explicit restrictions or actions.
• No: Documented scope or exclusions rule out the proposed use.
• Unknown: Primary-source evidence is missing, unclear, or insufficient.

Missing evidence means an unknown vendor verdict, not inferred approval or an accusation of noncompliance.

Keep a decision record:

Record field	Entry
Decision	[yes / conditional / no / unknown]
Workflow	[plan, feature, model, permitted data, and destinations]
Conditions and exclusions	[restrictions and unresolved questions]
Supporting vendor evidence
Verification date	October 26, 2026
Owner and review triggers	[responsible role and changes requiring review]

Revisit the record when the feature, model, connection, agreement, or handling settings change.

Use the directory to check the vendor's documented BAA scope, then compare that evidence with your exact workflow. For contractual changes, see what to do when BAA terms change.

FAQ

Does a signed BAA cover every AI feature a vendor offers?

Do not assume it does. Match the feature, plan, model, and connected services to the agreement’s documented scope and exclusions. A newly available feature should prompt a scope check, not automatic approval.

Does a promise not to train on my data mean an AI tool can handle PHI?

No-training language is not evidence of BAA coverage by itself. Check the applicable agreement separately from retention, logs, deletion, and human access. Each question needs its own answer. Distinguish content and abuse-monitoring logs from administrative audit logs, which may follow different rules.

Can a clinic use a consumer chatbot if it removes patient names?

Do not approve the workflow on name removal alone. Other details may still identify a patient, and removing names does not establish verified de-identification. Review the actual service terms, agreement coverage, and data involved.

What should we check when an AI assistant connects to another application?

Identify the receiving application, what it receives, who enables the connection, and which agreement addresses that handling. Distinguish provider-managed subprocessors from clinic-enabled integrations rather than assuming the same contractual arrangement applies to both.

What should staff do if AI coverage is unclear or undocumented?

Do not enter PHI into the unapproved workflow. Ask the designated privacy or IT contact to resolve the scope question, and use synthetic test content while the review remains open. Record an unknown verdict when primary-source evidence is insufficient. Use wholly fabricated test content containing no real patient information, and obtain qualified review if contractual scope remains ambiguous.

---

Ownership disclosure: Chanty, Inc. publishes HIPAA Compliant Wiki. The directory reports vendors’ published terms; it does not audit vendors or provide legal advice.