What Is a BAA — and Will Your AI Vendor Actually Sign One?

Compliance|10 min read|Updated 2026-07-19
Written byMoneli Automation
Technically reviewedMoneli Automation
Last verified2026-07-19
This guide is notlegal advice

Disclaimer: This content is for educational purposes only and does not constitute medical, legal, or financial advice. CPT descriptions are original summaries — not official AMA text. Always verify billing and credentialing details with your payer. Read full disclaimer

If you run a clinic, a therapy practice, or any office that touches patient records, sooner or later a software vendor's sales page stops you cold with one line: "We'll sign a BAA." Or worse, the line is missing, and you're left wondering whether that means yes, no, or "please don't ask." This guide is for the non-technical owner trying to figure out what that acronym actually obligates — and whether the AI tool you're eyeing will really stand behind it.

The short answer: a BAA — Business Associate Agreement — is a written contract that U.S. health-privacy law (HIPAA) requires whenever you let an outside company use or store protected patient health information on your behalf. It's not optional paperwork and it's not a marketing badge. Per the U.S. Department of Health and Human Services, you must obtain "satisfactory assurances" from that company, and those assurances "must be in writing, whether in the form of a contract or other agreement" (HHS — Business Associates). The BAA is the U.S. instrument, but the underlying logic — the moment you disclose data to an outside company that handles it for you, a binding contract has to govern what they do with it — drives equivalent rules wherever your building is, like Europe's Data Processing Agreement, which we compare below. Many AI vendors will sign one — but only on their paid business tiers, only if you ask, and never on the free or consumer version most people try first. Everything below is the detail behind that, plus the questions to ask before you send a vendor a single record.

What Is a BAA, Exactly — and Who Counts as a "Business Associate"?

Start with the person you'd never think of as a contractor. HHS defines a business associate as "a person or entity that performs certain functions or activities that involve the use or disclosure of protected health information on behalf of, or provides services to, a covered entity" (HHS). "Covered entity" is the regulator's term for you — the clinic, the practice, the provider. "Protected health information" (PHI) is patient data tied to a person: names attached to diagnoses, appointment notes, billing records, audio of a session.

So the moment an outside AI service uses that data on your behalf — transcribing a visit, summarizing a chart, drafting a letter from a patient file — that service becomes a business associate. And a business associate needs a BAA. The trigger isn't how careful the vendor is or how good their encryption looks. It's simply that the data left your control and landed with someone else who is doing something with it for you.

That's the whole logic, and it's worth holding onto, because it also tells you exactly when a BAA isn't needed — a point we'll return to at the end.

What Does a BAA Actually Require the Vendor to Do?

A BAA is not a vague "we take privacy seriously" statement. HHS says the contract must contain the specific elements set out in the rule at 45 CFR 164.504(e). Among them, the contract must (HHS):

  • Describe the permitted and required uses of protected health information by the vendor.
  • Provide that the vendor will not use or further disclose the information other than as permitted by the contract or as required by law.
  • Require the vendor to use appropriate safeguards to protect it.

In plain terms: the vendor has to write down what it's allowed to do with patient data, promise not to do anything else with it, and agree to protect it. This is the substance the acronym is standing in for.

There's also a part that surprises office owners, because it lands on you. HHS explains that where a covered entity "knows of a material breach or violation" by the business associate, the covered entity "is required to take reasonable steps to cure the breach or end the violation," to terminate the contract if those steps fail, and — if termination isn't feasible — "to report the problem to the Department of Health and Human Services (HHS) Office for Civil Rights (OCR)" (HHS). That is the rule, not a story about anyone getting fined. But it reframes what a BAA is: not a shield you file and forget, but an ongoing responsibility to watch the vendor and act if they mishandle data.

BAA vs DPA vs NDA: Three Contracts People Constantly Confuse

Vendors — and buyers — mix these up all the time, sometimes offering one when the law calls for another. They do different jobs.

What it isWhat law requires itDoes it make an AI vendor a compliant handler of patient data?
BAA (Business Associate Agreement)The HIPAA contract for U.S. protected health information, with legally dictated contentsHIPAA — required contents at 45 CFR 164.504(e) (HHS)Yes — this is the specific document HIPAA requires
DPA (Data Processing Agreement)The roughly equivalent contract under Europe's privacy law, governing a vendor ("processor") handling personal dataGDPR Article 28(3), which requires processing "be governed by a contract... binding on the processor" that sets out the subject-matter, duration, nature and purpose of the processing (GDPR Art. 28)For EU personal data, yes — but a DPA is not a HIPAA BAA and doesn't substitute for one
NDA (non-disclosure agreement)A generic promise to keep something confidentialNone — it's an ordinary business contract with no statutory contentsNo. An NDA has no required terms and no regulator behind it; signing one does not make a vendor a compliant business associate

The trap is the NDA. It feels protective — "they promised to keep it secret" — but it carries none of the specific obligations HIPAA demands and no built-in breach-remediation duty. If a vendor offers to sign an NDA "instead of" a BAA for patient data, that's not equivalent, and it's a signal to slow down. (For the European side of this, our data residency and sovereignty guide goes deeper on where the DPA fits.)

Will Your AI Vendor Actually Sign One? What the Big Providers Say

Here's the part sales pages tend to blur. The major AI providers do offer BAAs — but on narrow terms.

OpenAI states plainly that it can sign one: "We are able to sign Business Associate Agreements (BAA) in support of customers' compliance with the Health Insurance Portability and Accountability Act (HIPAA)," and adds, "Please reach out if you require a BAA" (OpenAI — Enterprise privacy). Read the scope carefully: that's stated for its API Platform and business products, not consumer ChatGPT. OpenAI also says it does "not train our models on your data by default" and now offers "ChatGPT for Healthcare... a secure workspace designed to support HIPAA compliance" (same page). Encouraging — but you have to ask, and you have to be on the right product.

Google is even more explicit about the boundary. Its admin guidance says customers subject to HIPAA who want to use certain Workspace or Cloud Identity services "must enter a Business Associate Amendment (BAA) with Google," and then draws the line in one sentence: "Customers who have not signed a BAA with Google must not use PHI in Google Workspace or Cloud Identity services" (Google Workspace Admin Help). The BAA covers only paid services on Google's "HIPAA Included Functionality list" — not a personal Gmail account, not services outside that list.

Put those two together and the pattern is unmistakable: BAAs are offered on business and paid tiers, not on free or consumer accounts. That's the concrete reason the free version of a tool won't cover you — there is simply no BAA on offer for it, and without one you're told not to put patient data in at all.

(We did not verify Microsoft Copilot's BAA terms for this guide, so we're not characterizing them here — check Microsoft's own current policy page before relying on it. For the ChatGPT-specific version of this question, see Is ChatGPT HIPAA compliant?)

What Questions Should You Ask an AI Vendor Before Sending Patient Data?

A short, unglamorous checklist saves a lot of grief:

  1. "Will you sign a BAA — and on which specific plan?" Get the tier in writing. A "yes" that only applies to a product you're not paying for is a no for your situation.
  2. "Which of your features does the BAA cover?" As Google's list shows, a BAA can cover some services and not others. Assume a feature is not covered until the vendor says it is.
  3. "Are you offering a BAA, a DPA, or an NDA?" If they answer "NDA" when you asked about patient health data, that's the wrong document.
  4. "Do you train on our data, and how long do you retain it?" These are product-privacy questions the vendor must answer from their own policy, not a salesperson's reassurance.
  5. "What happens to the data if we leave?" The BAA's whole point is defined, bounded handling — so the exit should be defined too.

If a vendor can't answer these crisply, that itself is the answer. Our private AI options comparison lays out how different tools stack up on exactly these points.

The Option That Skips the Contract Entirely

Here's the thread from the very beginning of this guide, pulled tight. A BAA is required because PHI is disclosed to a third party who handles it on your behalf — that's the literal trigger in HHS's definition of a business associate. So flip the premise: what if there is no third party?

When an AI model runs entirely on hardware your office owns — a desktop or small server in your building, using free software that works with the internet off — the patient data never leaves your control. Nothing is disclosed to anyone. And with no third party receiving the data, there is no business associate to obtain "satisfactory assurances" from, and therefore no BAA to negotiate, sign, or police. The hardest, most ongoing part of the compliance chore — vetting a vendor, tracking which features are covered, watching for their breaches — simply doesn't exist, because the vendor doesn't. This is the same logic that makes on-device tools attractive for the most sensitive data a clinic holds, like raw session audio; our local AI scribe and transcription guide walks through what that looks like in practice.

That's not a free lunch, and honesty requires the trade-offs. Keeping AI on hardware you own means real money up front for a capable machine, a computer your office has to maintain and back up, and models that run a step behind the very largest cloud systems on the hardest tasks. You also still owe your own duties — controlling who can log into the machine, securing the room, being sensible with what the AI produces. A BAA never disappears those; it just moves them off a contract with a stranger and back onto your own housekeeping.

So the real choice for a small office is between two legitimate routes. Use a cloud AI vendor on a business tier, get a signed BAA that actually covers the features you'll use, read it rather than the ad copy, and accept the ongoing job of monitoring a third party. Or keep the sensitive work on hardware you own, pay for it once, maintain it yourself, and let the question "will the vendor sign?" stop mattering — because wherever your building is, the data never leaves it, and there's no one to ask.

Next step

Wondering if this fits your office?

The readiness assessment walks through your data sensitivity, current AI use, and what a local setup would actually involve — with an engineer, not a salesperson.

Assess your readiness →

Frequently Asked Questions

Ask about this article

Get a plain-language answer drawn from this article. Answers are AI-generated from the text on this page.

Please don’t paste confidential or client information.

500 left

External Resources

Authoritative references and tools related to this documentation type.