Most healthcare teams treat a website chatbot as a widget, and widgets do not feel like the sort of thing procurement gates. That assumption is what stalls the deal three weeks later, when legal asks a single question nobody prepared for: is the chatbot vendor a business associate?
A few terms first, because the rest of this depends on them. HIPAA is the Health Insurance Portability and Accountability Act, the US law covering how patient information is handled, and PHI, or protected health information, is any health detail that can be traced back to a person. A business associate, sometimes shortened to BA, is an outside vendor that handles PHI on behalf of a healthcare organization; a BAA, or Business Associate Agreement, is the contract that permits it.
HHS answered that question directly. The Department of Health and Human Services enforces HIPAA, and its business associate guidance lists, among the examples, a third-party vendor AI chatbot on a provider's patient portal that handles patient data for services such as symptom assessment, medical reminders, and appointment scheduling.
So the interesting question is not whether a chatbot can be a business associate. It is whether yours is, and what it costs if you get that wrong.
iShort answer
A chatbot vendor is a business associate when it creates, receives, maintains, or transmits patient data on your behalf, and you need a signed BAA before any of that data reaches them. The conduit exception does not save a chatbot: HHS limits it to transmission-only services with transient access, and a chatbot stores transcripts. Launching without a BAA is a violation in itself, before any breach happens. On SiteGPT the BAA is available on the Enterprise plan only, at custom pricing, and the standard document is published in full so counsel can read it before a sales call.
Three questions, in the order that settles it fastest.
Can the bot ever receive information that identifies a patient?
Judge this by what a visitor can type into the box, not by the use case you scoped. A free-text field on a clinic site will be asked about a specific appointment, symptom, or prescription.
Does the vendor store or process what is said?
Transcripts, chat history, logs, analytics, lead records. Storing patient data on your behalf is exactly what makes a vendor a business associate under HIPAA.
Is the vendor doing more than passing data through?
The conduit exception covers transmission only, with access that is transient. A chatbot retrieves from a knowledge base and keeps the conversation, which is persistent access.
Verdict: a BAA before launch
Two yeses and the answer is settled. On SiteGPT that means an Enterprise agreement, because BAAs are not available on Starter, Growth, or Scale.
Key takeaways
| Question | The short answer |
|---|---|
| What triggers the obligation? | The vendor creating, receiving, maintaining, or transmitting patient data on your behalf. Storing transcripts counts. |
| Does the conduit exception apply? | Almost never. It covers transmission only, with transient access, plus storage that is temporary and incidental to it. |
| When must it be signed? | Before any patient data reaches the vendor. Signing later does not cure the earlier disclosure. |
| What if you skip it? | That is a violation on its own. HHS cites a case with over 3,000 individuals' data on an uncovered cloud server, settled for $2.7 million. |
| Who notifies patients after a breach? | You do. The covered entity is ultimately responsible for individual notice, within 60 days of discovery. |
| Which SiteGPT plan? | The Enterprise plan, at custom pricing. Not Starter, Growth, or Scale. |
The short answer, and the two facts that decide it
Yes, if the chatbot vendor handles patient data on your behalf. That is the whole test, and it turns on two facts you already know about your own deployment.
Fact one: can patient data reach the bot? Not "is it supposed to", but "can it". A chat box is an open text field, and patients type what is on their mind.
Fact two: does the vendor keep what is said? Almost every chatbot stores transcripts, so it maintains that data on your behalf. Maintaining patient data for a covered entity is the definition of a business associate, not an edge case within it.
Two yeses mean a BAA before launch. Everything below is why those two facts carry so much weight, and what the answer costs when it is no.
What a business associate actually is
Under HIPAA, a business associate is a person or organization outside your workforce that performs functions or activities for you involving creating, receiving, maintaining, or transmitting protected health information, or that provides certain services to you involving the disclosure of PHI. Those four verbs are the whole hinge, so it is worth mapping each one onto a chat widget.
| The verb in the rule | What it looks like in a chatbot | Present in a typical deployment? |
|---|---|---|
| Creates | The bot generates a reply that restates or summarizes what a patient said | Yes |
| Receives | A visitor types a symptom, an appointment, or a prescription into the widget | Yes |
| Maintains | Transcripts, chat history, logs, analytics, and lead records sit on the vendor's servers | Yes, for nearly every product |
| Transmits | The conversation is passed to an AI model, a helpdesk, or a notification channel | Yes |
One of those four is enough. Most chatbots hit all four before lunch on launch day.
Two further points matter for procurement. First, the agreement has to exist before the disclosure: HIPAA permits a covered entity to disclose PHI to a business associate once it has satisfactory assurances, in the form of a written agreement, that the data will be safeguarded. Second, the obligation flows downhill. A business associate must establish a BAA with a subcontractor before disclosing PHI to it, and every downstream subcontractor is a business associate too.
That second point is the one to press a chatbot vendor on, because a chatbot is never one company. There is a hosting provider underneath it and an AI model provider behind the answers, and each of them is inside the chain.
HHS does list exceptions to the business associate definition, and it is worth knowing that none of them describes a website chatbot. They cover disclosures to a provider for treatment, disclosures to a plan sponsor, certain public benefits programs, participants in an organized health care arrangement, and conduits. That last one is the exception vendors reach for, so it deserves its own section.
The conduit exception, and why a chatbot rarely qualifies
The conduit exception exists for the postal service, private couriers, and their electronic equivalents. HHS is specific about the limits: it applies to entities that only provide transmission services for PHI, including any temporary storage incidental to that transmission, and access by a conduit is transient in nature. Entities that access PHI on a regular or frequent basis to perform a service are not conduits.
The word doing the work is "transient". A courier holds an envelope for a day and hands it over. A chatbot keeps the conversation, indexes your content, retrieves from it, and logs what happened.
HHS has already applied this reasoning to the closest analogue. Asked whether a cloud service provider can be a conduit, the guidance answers generally no, and explains that a provider maintaining data for the purpose of storing it is a business associate rather than a conduit because it has more persistent access. The same guidance goes further: a cloud provider storing only encrypted data, with no decryption key, is still a business associate, because being unable to view the information does not change the fact that it maintains it.
| A conduit | A chatbot vendor | |
|---|---|---|
| Relationship to the data | Passes it along | Keeps it |
| Duration of access | Transient, incidental to transmission | Persistent, for the life of the transcript |
| Does it act on the content? | No | Yes, it retrieves and generates answers from it |
| Storage | Temporary and incidental only | Transcripts, logs, analytics, lead records |
| Real examples | Postal service, couriers, ISPs | Almost every chat widget on the market |
Three deployment patterns, and which ones need a BAA
Most chatbot projects in healthcare land in one of three shapes. The verdicts differ, though less than teams hope.
| Scenario | Best pick | Why |
|---|---|---|
| Marketing site bot answering hours, locations, insurance accepted | BAA in practice | The content holds no patient data, but the input box does not know that. Skipping the BAA only holds if visitors genuinely cannot submit free text, which is rare and fragile. |
| Patient portal or logged-in area assistant | BAA required | This is the exact example HHS names: a third-party AI chatbot on a provider's patient portal, handling things like symptom questions, reminders, and scheduling. |
| Intake, triage, or appointment booking bot | BAA required | The data is patient data by design. A reason for the visit attached to a name is protected health information the moment it is submitted. |
The first row is where teams argue, so here is the honest version. A bot with no free-text field, no access to records, and no route into a patient's own care sits outside the definition, because nothing it creates, receives, maintains, or transmits is patient data.
That configuration is unusual, and it is one product decision away from being wrong. If someone adds a "How can we help?" box in month four, the analysis changes and nobody re-runs it. Most compliance teams sign the BAA rather than defend that boundary in perpetuity.
Can a visitor type free text into the widget?
- If yes→Assume patient data will arrive, and get a BAA before launch
- If no, buttons only→Check what the buttons submit and where the answers go
Does the vendor store transcripts, logs, or lead records?
- If yes→The vendor maintains PHI on your behalf, which is business associate status
- If no, nothing is retained anywhere→Ask for that in writing, because it is an unusual claim
Is anything downstream of the bot also touching the conversation?
- If an AI model, helpdesk, or analytics tool→Confirm the vendor holds its own BAA with each, as flow-down requires
- If you are not sure→Treat that as unanswered, and ask before signing
Has the BAA been executed and HIPAA processing confirmed?
- If not yet→No patient data through the widget, including test conversations
- If yes, confirmed in writing→Launch, with training content kept free of patient data
What happens if you deploy without one
This is the part worth taking to whoever is deciding whether the chatbot can wait for legal. The exposure is not theoretical, and it does not require anything to go wrong first.
$2.7M
Oregon Health & Science University's settlement with OCR, alongside a three-year corrective action plan. HHS cites the case for a covered entity that stored the data of over 3,000 individuals on a cloud server without a BAA in place.
Source: HHS Office for Civil RightsUsing the vendor without a BAA is the violation. HHS states it directly: a covered entity that uses a cloud provider to maintain patient data without entering into a BAA is in violation of the HIPAA Rules. No leak is required for that sentence to be true, which is what makes the "we will paper it later" plan expensive.
A breach at the vendor is still your notification to make. The covered entity is ultimately responsible for ensuring individuals are notified, and that notice has to go out without unreasonable delay and no later than 60 days after discovery. If more than 500 residents of a state are affected, prominent media outlets get notified too, along with the Secretary of HHS.
Penalties scale with what you knew. Civil money penalties under the Enforcement Rule are tiered by culpability, so "nobody told us" and "we were told and shipped anyway" are priced differently. An unsigned BAA that legal flagged before launch is the second kind.
The uncovered vendor is entitled to assume there is no patient data. Without a BAA, nothing stops that vendor from processing the conversations through whatever subprocessors it chooses, or retaining them on its own schedule. The contract is what constrains the chain, which is why the chain is unconstrained until it is signed.
What to read before you sign
HIPAA sets the required contents of a BAA at 45 CFR 164.504(e). Every serious vendor clears that floor, which is precisely why the floor tells you nothing. The differences that matter are the numbers each vendor fills in.
Here is the required element, the question to ask, and what the published SiteGPT BAA says, as a worked example of what a specific answer looks like.
| Required element | The question that separates vendors | What the SiteGPT BAA states |
|---|---|---|
| Permitted uses and disclosures | Is patient data ever used to improve the product or train models? | PHI is never used to train AI models, and the AI layer runs on zero-data-retention endpoints |
| Safeguards | Are the security controls in the contract, or only on a marketing page? | Security Rule safeguards, including encryption in transit and at rest and access controls |
| Breach and incident reporting | How many days, counted from what? | Within five business days of discovery, plus security incident reporting |
| Subcontractor flow-down | Is the AI provider covered, and who confirms it? | Every vendor in the PHI chain operates under its own BAA, and SiteGPT countersigns only once that coverage is in place |
| Individual rights | Who handles an access or amendment request that arrives through the bot? | Prompt forwarding of access and amendment requests, plus accounting of disclosures |
| Return or destruction at termination | What happens to transcripts when the contract ends? | Return or destruction of PHI at termination |
| Retention, which HIPAA leaves to you | Is the number a contract term or a settings toggle an admin can change? | Conversation content redacted seven days after last activity, configurable on the order form |
Two things about that document are worth knowing before counsel opens it.
It is published rather than gated, so a lawyer can read the full text before anyone books a sales call. And it is the standard agreement rather than a fixed one: retention windows, breach notice timelines, notice contacts, and scoping are the provisions commonly adjusted during onboarding. Procurement teams tend to assume a published legal document is take it or leave it, which is the wrong assumption here.
Pros
- The full BAA is published at sitegpt.ai/legal/baa and readable before any sales conversation
- It is a standard document, not a fixed one; reasonable amendments are worked in during onboarding
- Breach reporting within five business days of discovery, a specific number rather than 'promptly'
- Subcontractor flow-down, with SiteGPT countersigning only after the full PHI vendor chain is covered
- PHI never used to train AI models, backed by zero-data-retention endpoints at the AI layer
- SOC 2 Type II completed with zero exceptions, and a published subprocessor list
Cons
- The BAA is Enterprise plan only, at custom pricing; Starter, Growth, and Scale do not include it
- A self-serve HIPAA tier is planned and is not available today
- Cloud drive sources and chat integrations are off by default in a covered workspace, and switch on only for vendors you hold your own BAA with
- Sources already connected to an account are switched off when HIPAA is enabled
- Training content must stay free of patient data, and nothing detects it for you
- The 'Responses are AI-generated' line stays on the widget, even with white-label branding
How to get a BAA in place
The mechanics are worth stating plainly, because "contact sales" is where most vendor pages stop and most procurement timelines slip.
The BAA is available on the Enterprise plan at custom pricing, and it is not available on Starter, Growth, or Scale. Enterprise is custom precisely because the BAA and the retention window are agreed with you rather than sold off a page.
- Request. Email SiteGPT with your organization and use case.
- Scoping. Confirm the deployment together, including which content sources and features will carry patient data.
- Legal review. Your team reviews the standard BAA, already published in full.
- Execution. Both parties sign. SiteGPT countersigns only after signed BAA coverage across the whole PHI vendor chain is in place.
- Enablement. HIPAA processing is enabled for the account and confirmed in writing.
Only after that written confirmation should patient data flow through the chatbot. Until then, keep it out of everything: training content, conversations, uploaded files, and lead capture.
Best forUS healthcare organizations that need the business associate question settled in writing before a chatbot goes live.
For the day-to-day behavior of a covered account, see the HIPAA workspace documentation and the HIPAA program page, which is the authoritative source for what is available today. If you are still comparing vendors rather than reviewing one, the roundup of HIPAA compliant AI chatbots covers the field.
Frequently asked questions
Does a website chatbot need a BAA? It needs one if the chatbot vendor creates, receives, maintains, or transmits protected health information on your behalf. For a chatbot that stores conversation transcripts, that is almost always true the moment a visitor can type a health detail into it. HHS guidance lists a third-party AI chatbot on a provider's patient portal as an example of a business associate, alongside cloud providers and app developers, so the question is not whether a chatbot can be a business associate but whether yours handles patient data.
Is a chatbot covered by the HIPAA conduit exception? Almost never. HHS limits the conduit exception to entities that only provide transmission services for PHI, including any temporary storage incidental to that transmission, and states that access by a conduit is transient in nature. A chatbot stores transcripts, retrieves from a knowledge base, and keeps logs, which is persistent access rather than transient. HHS applies the same reasoning to cloud providers: one that stores ePHI is a business associate even when the data is encrypted and the provider holds no decryption key.
When does the BAA have to be signed? Before any protected health information reaches the vendor. HIPAA permits a covered entity to disclose PHI to a business associate only once it has satisfactory assurances in the form of a written agreement, so signing afterwards does not cure the earlier disclosure. In practice this means the contract has to be executed before launch, not before the first complaint.
What happens if you launch a chatbot without a BAA? Using a vendor to maintain PHI without a BAA is itself a violation of the HIPAA Rules, separate from any breach. HHS cites a case where a covered entity stored the data of over 3,000 individuals on a cloud server with no BAA in place; Oregon Health & Science University settled that matter for $2.7 million with a three-year corrective action plan. If the uncovered vendor is then breached, the notification duty still lands on you, within 60 days of discovery.
Does an appointment booking or FAQ bot need a BAA? Judge it by what visitors can type, not by what the bot was built for. A booking bot that takes a name plus a reason for the visit is handling patient data, and HHS names appointment scheduling among the chatbot services that create a business associate relationship. A bot on a general marketing page with no free-text input and no way to reach patient records is a different case, but that setup is rare and stops being true the moment someone asks about their own care.
Which SiteGPT plan includes a BAA? The Enterprise plan only, at custom pricing. BAAs are not available on Starter, Growth, or Scale, and a self-serve HIPAA tier is planned rather than available. The standard BAA is published in full at sitegpt.ai/legal/baa so counsel can review it before any sales conversation, and it is a standard document rather than a fixed one: retention windows, breach notice timelines, notice contacts, and scoping are commonly adjusted during onboarding.
What should a chatbot BAA actually contain? HIPAA sets the required elements at 45 CFR 164.504(e): permitted and required uses of PHI, a commitment not to use or disclose it otherwise, safeguards, subcontractor flow-down, breach and security incident reporting, support for individual access and amendment rights, and return or destruction of PHI at termination. Read past that floor for the numbers that vary by vendor: how many days until a breach must be reported, how long transcripts are kept, and whether the retention window is a contract term or a settings toggle.
Do you need a BAA with the AI model provider too? Not directly, because that vendor is your chatbot vendor's subcontractor rather than yours. HIPAA handles this through flow-down: a business associate must have a BAA with any subcontractor before disclosing PHI to it, and every downstream subcontractor is a business associate in its own right. Your job is to confirm in writing that the chain is covered, including the AI providers, rather than to sign each contract yourself.
Sources
- HHS guidance on business associates for the definition, the AI chatbot example, the exceptions list, and subcontractor flow-down, read 6 August 2026
- HHS guidance on HIPAA and cloud computing for the conduit analysis, no-view services, and the consequence of using a vendor with no BAA
- HHS Breach Notification Rule for the 60-day individual notice deadline, media notice above 500 residents, and where responsibility sits
- HHS Enforcement Rule for civil money penalties, codified at 45 CFR Part 160, Subparts C, D, and E
- OHSU resolution agreement for the $2.7 million settlement and three-year corrective action plan
- SiteGPT HIPAA program page for plan gating and the onboarding sequence, verified 6 August 2026
- SiteGPT standard BAA for breach timelines, flow-down, individual rights handling, retention, and the model training commitment, verified 6 August 2026
- SiteGPT subprocessor list for the AI subprocessors and zero-data-retention endpoints
Last updated: August 2026. HHS guidance and SiteGPT program terms were read directly on 6 August 2026.