Signing the Business Associate Agreement settles who is liable. It does not answer the question the person building the bot actually has, which is what they are allowed to feed it on Monday morning.
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, enforced by the Department of Health and Human Services (HHS). PHI, or protected health information, is any health detail that can be traced back to a person: a symptom, an appointment, a prescription, a test result, or a name attached to any of those.
A business associate, sometimes shortened to BA, is an outside vendor that handles PHI on behalf of a healthcare organization, and a chatbot vendor that stores transcripts is one. A BAA, or Business Associate Agreement, is the contract that lets that vendor handle PHI at all.
On a HIPAA covered workspace the answer is narrow. PHI belongs in end-user conversations and nowhere else, which means the knowledge base behind the bot has to be clean before it goes live. That is a content operations problem rather than a legal one, and it lands on whoever owns the content.
iShort answer
A chatbot holds two kinds of data: the content you train it on, and the conversations visitors have with it. Under a BAA, patient data is covered in conversations and has to stay out of everything else, because training content is what the bot retrieves from when it answers. Nothing detects it for you, so the work is a deliberate audit: inventory every source the bot reads, remove the 18 Safe Harbor identifiers wherever they appear including free text, then set the retention window and the lead fields before launch rather than after. On SiteGPT this applies to Enterprise accounts, the only plan where a BAA is available.
Two lanes into the same chatbot. Only one of them is covered.
Training content: keep it clean
- Crawled website pages and sitemaps
- Uploaded files: PDFs, DOCX, CSV, slides
- Text snippets, Q&A entries, custom responses
- The chatbot instructions and persona prompt
- Lead form fields, especially free-text ones
- Cloud drive syncs are off by default here, and that is the reason why
Conversations: covered by the BAA
- Whatever a patient types into the widget
- Symptoms, conditions, appointments, prescriptions
- The bot's replies restating what they said
- Reviewable in the dashboard, with human takeover
- Message text redacted 7 days after last activity by default
- Never used to train AI models, on zero-data-retention endpoints
The whole job, in the order that finds problems fastest.
Inventory every source the bot reads
Not just files. Crawled pages, snippets, Q&A entries, custom responses, and the instructions count as training content too. You cannot audit a list you have not written down.
Search the free text, not only the fields
HHS says the standard makes no distinction between structured fields and free text. The identifiers that get missed live in case studies, testimonials, help center macros, and screenshots pasted into a PDF.
De-identify properly or rewrite
Safe Harbor removes 18 categories of identifier, and parts do not count: initials and the last four of an SSN both fail. Often the faster fix is to rewrite the example in its general form.
Settle retention and lead fields before you sign
The conversation retention window lives in the order form, which makes it a contract term rather than a toggle. Lead fields are a design decision you make once and live with.
Key takeaways
| The question | The short answer |
|---|---|
| Can patient data go in the knowledge base? | No. It belongs in conversations, because training content is what the bot retrieves from to answer any visitor. |
| Is that a HIPAA rule? | No, it is a term in the BAA, as with almost every chat vendor. The practical reason to follow it is stronger than the contractual one. |
| Does anything scan the content for PHI? | Nothing. No automatic detection exists, so this is a human review step your team owns. |
| What counts as training content? | Crawled pages, uploaded files, snippets, Q&A entries, custom responses, and the chatbot instructions. |
| How do you de-identify? | Expert determination or Safe Harbor, at 45 CFR 164.514(b). Safe Harbor strips 18 identifier categories, including in free text. |
| How long are conversations kept? | Message text redacted 7 days after last activity by default, configurable in the Enterprise order form. |
| Which SiteGPT plan? | The Enterprise plan only. Starter, Growth, and Scale do not include a BAA. |
Two places PHI can live, and only one of them is covered
A chatbot holds two separate bodies of data, and teams conflate them constantly.
Training content is everything you feed the bot: crawled website pages, uploaded files, text snippets, Q&A entries, custom responses, and the instructions that shape its persona. Conversations are what visitors type and what the bot replies.
Patient data belongs in conversations. It stays out of training content, and it is worth being precise about where that rule comes from, because getting the source wrong leads people to argue with it.
It is a contract term, not the statute. Nothing in HIPAA forbids patient information in a knowledge base. You assure your vendor of it in the BAA, as almost every chat vendor asks, and SiteGPT is no different.
The reason to follow it anyway is simpler than the contract. Training content is the material the bot retrieves from when it composes an answer, so anyone who can chat with the bot can reach that content indirectly. A widget on a clinic homepage is open to every visitor on the internet, which makes the knowledge base the wrong place for one person's medical details whatever any agreement permits.
The legal side of this, including when a BAA is triggered at all, is covered in the guide to chatbot BAAs. This page assumes that question is settled and the workspace is being built.
Why a covered workspace changes how content gets in
On a covered SiteGPT workspace, content arrives by upload, by paste, or by a crawl of your own website. Cloud drive sources such as Google Drive, Notion, Dropbox, OneDrive, Box, and GitHub are off by default, as are helpdesk and messaging tools like Zendesk, Slack, and Crisp.
That default is not an arbitrary restriction, and understanding the reasoning tells you how to work with it.
A sync copies whatever is in the folder. Nobody re-reads every file in a shared drive before connecting it, and shared drives at healthcare organizations accumulate discharge summaries, intake scans, and exported ticket queues in subfolders nobody opens. One of them is enough to publish patient data to every visitor on your site.
An upload is one file at a time, chosen on purpose. That is the moment a reminder can appear, and the moment a human being looks at what they are adding. The friction is the feature.
Chats stay in one covered channel rather than flowing into a third-party helpdesk, so the transcript stays where the BAA covers it. Human takeover, chat history, and chat modes all work normally inside the dashboard.
| What you would do without HIPAA | What a covered workspace does instead |
|---|---|
| Connect Google Drive or Notion and let it sync on a schedule | Upload the specific files you have reviewed, or crawl your own website |
| Point the bot at a shared team folder | Paste text snippets and write Q&A entries deliberately |
| Route conversations into Zendesk, Slack, or Crisp | Answer and take over inside the SiteGPT dashboard |
| Use a ready-made industry lead form template | Build the form field by field, with a warning on free-text fields |
| Let email notifications include the conversation | Get a content-free notification that links to the dashboard |
One migration detail catches teams out. If you sign a BAA on an account that already has sources connected, those syncs are switched off as part of enablement. Decide beforehand whether the content behind them gets uploaded directly or whether you will produce your own BAA with that vendor, because otherwise a bot that was answering well on Friday has gaps on Monday.
Auditing a knowledge base before you migrate it
This is the step teams underestimate, usually because they picture the knowledge base as the twelve pages they wrote on purpose rather than everything the crawler picked up.
Start with an inventory. Not a mental one.
| Scenario | Best pick | Why |
|---|---|---|
| Website pages the crawler reaches | Audit by URL list, not by memory | Patient stories, obituaries, staff blog posts, and testimonials sit on the same domain as your service pages. A sitemap crawl takes all of them. Pull the URL list first and read it as a list. |
| Uploaded documents and exports | Highest risk, audit file by file | PDFs of completed intake forms, spreadsheets exported from a ticketing system, and slide decks with a real case study are the usual culprits. A file that was fine in a private drive is not fine as retrieval material. |
| Help center articles and saved replies | Search the text, do not skim it | Macros and canned responses accumulate real examples over years. 'Similar to the request from J. Rivera in March' is an identifier plus a date attached to a health service. |
Then search the content rather than skimming it. HHS is direct on this point: the de-identification standard makes no distinction between data entered into standardized fields and information entered as free text, and an identifier must be removed regardless of its location in a record if it is recognizable as an identifier.
That single sentence is why a field-by-field review misses things. The identifiers that survive an audit are the ones written into prose, and HHS notes the harder version of the problem too, that clinical narratives documenting a patient's history or lifestyle are information rich and may readily allow identification even after the obvious fields are gone.
A practical pass, in the order that finds the most in the least time:
- Names and initials. Include staff notes that reference a patient by first name, and remember that initials are not a fix.
- Dates. Any date more specific than a year that attaches to a person: appointment, admission, discharge, birth, death.
- Contact details and numbers. Phone, fax, email, medical record numbers, account numbers, member IDs, license numbers.
- Geography below state level. Street addresses and ZIP codes in case studies and testimonials.
- Images. Full-face photographs and comparable images, including screenshots of a records screen pasted into a document.
- Distinguishing narrative. A rare condition plus an occupation plus a town identifies someone even with every listed field removed.
De-identification, what Safe Harbor actually requires
Sometimes the content genuinely needs to stay, and the question becomes whether it can be de-identified rather than deleted. HIPAA recognizes two methods at 45 CFR 164.514(b), and de-identified information falls outside the definition of PHI entirely, so the Privacy Rule no longer restricts how it is used.
Expert determination is a qualified person applying statistical and scientific methods to conclude that the risk of identification is very small, and documenting the analysis. HHS notes there is no specific degree or certification that makes someone an expert, and no fixed numerical threshold for "very small".
Safe Harbor is the checklist version: remove 18 categories of identifier belonging to the individual or to their relatives, employers, or household members, and have no actual knowledge that what remains could identify the person.
| The Safe Harbor categories | What this looks like in chatbot content |
|---|---|
| Names | A patient named in a case study, a testimonial byline, a saved reply |
| Geographic subdivisions smaller than a state | The town in a patient story, a street address, a ZIP code (only the first three digits survive, and only where that area holds more than 20,000 people) |
| All date elements except year, and all ages over 89 | Appointment, admission, discharge, birth, and death dates. Ages over 89 aggregate into "90 or older" |
| Telephone and fax numbers | Direct lines pasted into an internal FAQ |
| Email addresses | A patient's address in a forwarded thread turned into a help article |
| Social Security numbers | Any digits at all, including the last four |
| Medical record numbers | Case references carried into training examples |
| Health plan beneficiary numbers, account numbers | Billing examples in a payments FAQ |
| Certificate and license numbers | Anything tying back to a specific person |
| Vehicle and device identifiers and serial numbers | Implant or equipment serials in a device FAQ |
| Web URLs and IP addresses | Links to a personalized portal page |
| Biometric identifiers | Voice or fingerprint data in any attached file |
| Full-face photographs and comparable images | A screenshot with a records panel visible |
| Any other unique identifying number, characteristic, or code | The catch-all. HHS gives occupation as an example when it distinguishes someone |
Three details in that list cause most of the mistakes.
Parts and derivatives do not count as removed. HHS states plainly that a data set containing patient initials, or the last four digits of a Social Security number, does not meet the Safe Harbor requirement.
Dates lose everything below the year. January 1, 2009 becomes 2009. Where a date implies an age above 89, the year has to move too: HHS gives the example of a patient born in 1910 seen in 2010, whose year of birth should be reported as on or before 1920 so a reader cannot infer an age near 100.
Provider names are a separate question. Only names of the patient and of their relatives, employers, and household members must be suppressed, so there is no requirement to strip your own clinicians from the content. There is no requirement to keep them either, and the actual knowledge condition still applies if naming a specialist would narrow the field to one patient.
The same instinct applies to what goes into the bot in the first place. HIPAA's minimum necessary standard asks covered entities to limit uses and disclosures to what is needed to accomplish the purpose, and while it applies to PHI rather than to your marketing content, it is a good question to carry into a knowledge base review. If the specifics do not change the answer the bot gives, the specifics do not need to be in there.
Retention, the 7-day default and the number in your order form
Once conversations start, the question moves from what you put in to how long what patients say stays around.
On a covered SiteGPT workspace, conversation content is redacted 7 days after that conversation's last activity by default. Redaction replaces the message text while conversation counts and analytics aggregates remain, so reporting keeps working after the content is gone.
That window is configurable, and where it is configured matters more than the number itself. It lives in your Enterprise order form, which makes it a contract term rather than a setting an administrator can change on a Tuesday.
Two related behaviors are worth knowing while you plan. Email notifications on a covered workspace never include conversation content or visitor contact details, linking to the dashboard instead. Topic analytics classify only against labels your team defines, and conversation text never feeds retained analytics.
Leads persist until you delete them
Leads are the exception to everything above, and the exception is deliberate.
A lead record does not expire on SiteGPT's schedule. The reasoning is that a lead is a contact someone submitted so your team would follow up, closer to a referral than to a transcript, and deleting those automatically could destroy records you are required to retain. Export to CSV and deletion are both available in the dashboard at any time.
That makes lead form design the one place where a bad decision persists. Two guardrails exist on a covered workspace: ready-made industry form templates are hidden so every field is a deliberate choice, and the form builder warns you when you add a free-text field.
A field labeled "How can we help?" on a clinic site is an invitation to type a diagnosis. Rename it, constrain it to a set of options, or drop it.
If patient information does land in a lead, it is a problem to fix rather than an emergency. Nothing was deleted out from under you, so the work is noticing, exporting what you need, deleting the record, and fixing the field that invited it.
The pre-launch checklist
Run this before the widget goes live, in this order.
Has written enablement confirmation arrived?
- If not yet→No patient data through anything, including test conversations, uploads, and lead capture
- If yes, in writing→The workspace is covered, continue
Is there a written inventory of every source the bot reads?
- If yes, including snippets, Q&A, and instructions→Audit each one against the Safe Harbor categories
- If only the files→Add crawled URLs, custom responses, and the persona prompt, then audit
Did any content need real patient specifics to work?
- If no→Rewrite it in general form, which is faster and safer than de-identifying
- If yes→De-identify by Safe Harbor or expert determination, and document what you did
Are the retention window and the lead fields settled?
- If retention agreed with counsel and in the order form→Review the lead form field by field, then launch
- If not yet→Settle both before launch; retention is a contract change afterwards
Best forUS healthcare teams who have the BAA handled and now have to build the bot without putting patient data where every visitor can reach it.
For the requirements end to end, see the guide to what makes a chatbot HIPAA compliant. The authoritative sources on SiteGPT's side are the HIPAA program page, the published BAA, the HIPAA workspace documentation, and the security page for SOC 2 Type II and encryption posture.
Frequently asked questions
Can you train a chatbot on patient data? On a HIPAA covered workspace, no. Patient data belongs in end-user conversations and the training content has to stay free of it. That rule comes from the BAA rather than from the statute, and the practical reason is stronger than the contractual one: training content is what the bot retrieves from when it answers, so anyone who can chat with the bot can reach that content indirectly. A chatbot is usually open to every visitor on your website.
What counts as PHI in chatbot training content? Health information that identifies someone, in any of the places the bot reads from: crawled website pages, uploaded files, text snippets, Q&A entries, custom responses, and the chatbot instructions themselves. HHS is explicit that the de-identification standard makes no distinction between structured fields and free text, so an identifier has to be removed regardless of where it sits if it is recognizable as an identifier. A saved reply quoting a real patient case counts even though it never came out of a medical record.
Does SiteGPT detect or redact PHI in the content you upload? No. No scan checks customer-supplied content, and nothing flags a file that turns out to contain patient details. Keeping training content, chatbot instructions, and lead fields clean is a review step your team owns. A covered workspace is built to give that step somewhere to happen: content arrives one deliberate upload at a time rather than syncing in from a folder nobody re-reads.
How do you de-identify content before adding it to a chatbot knowledge base? HIPAA recognizes two methods at 45 CFR 164.514(b): expert determination, where a qualified person documents that the re-identification risk is very small, and Safe Harbor, where you remove 18 enumerated categories of identifier and have no actual knowledge that what remains could identify someone. Parts and derivatives do not survive the cut: HHS states that a data set containing patient initials or the last four digits of a Social Security number does not meet Safe Harbor. Dates are reduced to the year, and any age over 89 is aggregated into 90 or older.
How long does SiteGPT keep chatbot conversations under HIPAA? Conversation content is redacted 7 days after that conversation's last activity by default. Redaction replaces the message text while conversation counts and analytics aggregates remain, so reporting keeps working. The window is configurable in your Enterprise order form, which makes it a contract term rather than a setting an admin can change later, so the number is worth agreeing with counsel before signing.
Why can't you sync Google Drive or Notion into a HIPAA chatbot workspace? Cloud drive sources are off by default rather than banned. A sync copies whatever sits in the folder, and nobody re-reads every file in a shared drive before connecting it, so one old discharge summary in a subfolder is enough to put patient data where every visitor can reach it. Any specific source can be switched on during scoping if you hold your own BAA with that vendor. The test is your agreement with them, not whether the vendor advertises HIPAA compliance, because almost every large vendor does.
What happens if PHI ends up in a lead record? It is a problem to fix rather than a crisis. Leads persist until you delete them, on the reasoning that deleting contact records on a vendor's schedule could destroy records you are required to keep, so nothing disappears before you notice it. Export the lead, delete it from the dashboard, then fix the field that invited it. On a covered workspace, industry form templates are hidden so every field is a deliberate choice, and the form builder warns you when you add a free-text field.
Can you use real patient questions as example Q&A entries? Only after de-identification, and it is worth asking whether the example needs the specifics at all. A question rewritten into its general form, with no identifiers and no distinguishing narrative, teaches the bot the same thing as the transcript it came from. HHS notes that clinical narratives documenting a patient's history or lifestyle are information rich and may provide enough context to identify someone, which is the failure mode a lightly edited real conversation walks into.
Sources
- HHS guidance on de-identification methods for the two methods, the enumerated Safe Harbor identifiers at 45 CFR 164.514(b)(2), the free-text rule, the initials and last-four example, the date and age-90 examples, and the treatment of provider names, read 7 August 2026
- HHS guidance on the minimum necessary requirement at 45 CFR 164.502(b) and 164.514(d), read 7 August 2026
- SiteGPT HIPAA workspace documentation for the covered workspace behavior, the 7-day redaction default, lead handling, notification behavior, and the enablement sequence, verified 7 August 2026
- SiteGPT HIPAA program page for BAA availability and plan gating
- SiteGPT standard BAA for the model training commitment and safeguards
- SiteGPT subprocessor list for the AI subprocessors and zero-data-retention endpoints
Last updated: August 2026. HHS guidance and the SiteGPT HIPAA documentation were read directly on 7 August 2026.