HIPAA and AI Email Assistants: When You Need a BAA

Whether you can use a HIPAA compliant AI email assistant with protected health information (PHI) comes down to one document: a signed Business Associate Agreement, or BAA. "HIPAA compliant" is not a badge you buy or a certification a vendor earns once. It is a shared, contractual state between you and every party that touches PHI on your behalf — and for an AI email tool, that contract has to exist before the first patient detail reaches it.

This guide is written for a covered entity — a clinic, a practice, a health plan, a billing service — deciding whether an AI email assistant can go anywhere near clinical mail. It walks through when an AI vendor becomes a business associate, what a BAA has to cover, why a BAA signed after the fact does not repair a disclosure that already happened, and how to keep working safely in the meantime. The costly mistake here is not choosing the wrong tool. It is letting PHI flow through any tool before the paperwork that authorizes it exists.

The short answer: no BAA, no PHI#

You can use an AI email assistant with PHI only if the vendor will sign a BAA, and only after they have. The Security Rule is explicit that a covered entity may let a business associate create, receive, maintain, or transmit electronic PHI on its behalf only once it has obtained satisfactory assurances — a BAA — that the associate will safeguard the information. An AI email tool that reads a message, drafts a reply, or stores mail is doing exactly those things.

So the decision is binary before it is anything else. If the vendor does not offer a BAA, the evaluation is over for any mailbox that carries PHI, no matter how good the product is. Encryption, a slick interface, and a strong privacy policy are all worth having, but none of them is a substitute for the contract. The rest of this guide assumes the vendor clears that first bar and asks what else a serious buyer should demand.

When your AI email tool becomes a business associate#

The trigger is function, not intent. Under HIPAA, a company becomes a business associate when it creates, receives, maintains, or transmits PHI to perform a service for you. An AI email assistant that ingests a patient's message to summarize it, or drafts a reply that quotes a diagnosis, is handling PHI on your behalf — which places it squarely inside that definition whether or not its marketing mentions healthcare.

Crucially, the chain does not stop at the vendor you sign with. Most AI email tools pass content to other companies — a large language model provider, cloud storage, email infrastructure. Each of those downstream parties that touches PHI is also a business associate, and HIPAA requires the vendor to hold a BAA with every one of them before disclosing PHI to it. A BAA that covers the front-door vendor but leaves the model provider uncovered is a chain with a broken link.

• The AI email vendor itself — reads, summarizes, drafts, and stores your mail on your behalf.
• The model provider — the LLM that generates summaries and drafts sees whatever content the vendor sends it.
• Storage and infrastructure — wherever message bodies and attachments physically live, and whatever moves them.
• Any subcontractor further down the chain — each must agree in writing to the same PHI restrictions before receiving it.

Criteria that actually matter#

Once a vendor will sign a BAA, the real evaluation begins. HHS publishes sample BAA provisions that spell out what the contract must contain, and those provisions are the checklist a buyer should read the vendor's answers against. A BAA is not a formality; it is where the vendor's specific obligations live.

The criteria below are the ones that decide HIPAA fit. Notice that most of them are contractual and organizational, not features you can see in a demo. A vendor can have a beautiful product and fail every one.

• A signed BAA that covers the HHS-listed provisions — permitted uses, safeguards, breach reporting, subcontractor terms, and return or destruction of PHI at termination.
• Named subprocessors with their own BAAs — you want to know who the model provider and storage provider are, and that each is under contract.
• Encryption of ePHI in transit and at rest, with keys the vendor controls rather than shares — a core Security Rule technical safeguard.
• A contractual no-training commitment — PHI fed to a model that trains on it is a further disclosure you did not authorize.
• Access controls and an audit trail — unique user identities and a tamper-evident log of who saw and did what, which the Security Rule requires.
• A written breach-notification timeline — the associate must report any unauthorized use or disclosure of PHI to you, and the BAA should say how fast.
• Support for the minimum-necessary standard — the ability to limit what PHI the AI actually sees, rather than exposing an entire mailbox by default.

Scoring the vendor: a rubric you can apply#

Turn those criteria into a scorecard and run every candidate through it, in the vendor's own words and in writing. If a row cannot be answered with a document — a BAA, a subprocessor list, a security page — treat the answer as a no.

A worked example: the retroactive BAA that fixes nothing#

Picture a small clinic that turns on an AI email assistant to help staff clear the inbox. A patient emails a question about a lab result. A staff member lets the assistant draft the reply, and the message — result values, the patient's name, an implied diagnosis — is sent to the AI vendor and, behind it, to the model provider. No BAA is in place with either. The moment that content leaves the mailbox, an impermissible disclosure of PHI has occurred.

A week later someone catches the gap and asks the vendor to sign a BAA. Say the vendor agrees and signs it today. That contract governs what the vendor may do with PHI from today forward. It does not reach backward and authorize the disclosure that already happened, because the authorization has to exist at the time of the disclosure, not after it. The earlier exposure remains an unauthorized disclosure that may be a reportable breach of unsecured PHI under the Breach Notification Rule.

The lesson is narrow and absolute: the BAA has to precede the first byte of PHI, not follow the first incident. A retroactive agreement is a fix for the future and no fix at all for the past. This is exactly why the tempting workaround — "we will just get the paperwork sorted once we see the tool is useful" — is the one move you cannot make.

Red flags when a vendor talks about HIPAA#

Marketing language around HIPAA is loose, and the gap between what a page says and what a contract delivers is where risk lives. Treat the following as reasons to slow down and ask for documents.

• "We're HIPAA compliant" with no offer of a BAA. Compliance is a contractual state you share with the vendor, not a property the product has on its own.
• A BAA available only on a top enterprise tier while the tool already ingests PHI on lower tiers — the exposure starts long before the contract does.
• No named subprocessor list, or a refusal to say which model provider processes your mail. You cannot cover a chain you cannot see.
• "Your data is encrypted" with no detail on encryption at rest, key control, or what happens inside the AI pipeline.
• A "HIPAA certified" badge. There is no official HIPAA certification issued by HHS, so the badge is self-styled at best.
• A BAA offered after you have already sent PHI, presented as though it repairs the earlier exposure. It does not.

How to work safely while you wait: segregate the PHI#

If a tool you like does not sign a BAA, or you are still evaluating, you do not have to stop using AI email entirely. You have to keep PHI out of it. The Privacy Rule's minimum-necessary standard already points the way: limit PHI to the smallest set of people, systems, and messages that genuinely need it.

1. 1

   Map where PHI actually enters your email

   Find the mailboxes and threads that carry patient names, conditions, results, or anything that could identify a person's care. That is your PHI perimeter, and it is usually smaller and more concentrated than people assume.

2. 2

   Turn AI features off on PHI-bearing mailboxes

   Until a BAA is in place, disable AI drafting, summarizing, and any AI processing on those mailboxes entirely. Off means off — not "only for routine messages," because you cannot reliably predict which thread turns clinical.

3. 3

   Route PHI through a BAA-covered channel

   Move genuinely clinical communication to a secure messaging tool or patient portal whose vendor has signed a BAA with you. That is where PHI belongs, not in a general-purpose AI inbox tool.

4. 4

   Reserve AI assistance for genuinely non-PHI mail

   Vendor and supplier threads, scheduling logistics that name no patient or condition, recruiting, and internal operations are usually safe. Be strict about the line — even metadata like a sender's identity can be PHI in the right context.

5. 5

   Document the decision

   Record the segregation choice and the reasoning as part of your risk analysis. If a question ever arises, a written decision that you kept PHI out of an un-covered tool is far stronger than an after-the-fact explanation.

What we'd pick — and where AI Emaily honestly fits#

We build AI Emaily, so we will be direct about where it sits in this decision. AI Emaily does not currently sign a BAA and is not a HIPAA-compliant product. If your email carries PHI, AI Emaily's AI features are not the right tool for that mail today. Do not route PHI through them — there is no configuration or workaround that changes that, because the missing piece is a contract, not a setting.

That is the honest verdict for the reader this guide is written for. A covered entity or business associate that needs PHI to travel through email should choose a vendor that signs a BAA and holds BAAs across its subprocessor chain, and should route clinical communication through BAA-covered channels — a secure messaging platform or patient portal built for that job. On the specific question of PHI in email, that is the pick, and it is not us.

Where AI Emaily can genuinely help a healthcare organization is the large share of practice email that carries no PHI at all: supplier and vendor threads, scheduling logistics that name no patient or condition, recruiting, billing-software administration, and internal operations. On that mail, the things we do build are real advantages — no training on your mail, approve-before-send with undo, and a full audit trail of every action. Those are good privacy engineering, and we say plainly that they are not a BAA and do not make the tool usable for PHI. Keep the clinical mail on a covered channel; let an AI inbox help with the administrative rest. You can read exactly how we handle data on our security page and privacy model doc before deciding.