HIPAA Compliant AI Chatbots: What Healthcare Businesses Need to Know in 2026

One unencrypted chat log can cost your practice $250,000.

That is not a hypothetical. In 2023, the HHS Office for Civil Rights collected more than $4.1 million in HIPAA settlements from covered entities whose vendors mishandled protected health information. A chunk of that involved software systems that stored patient data without a Business Associate Agreement in place. AI chatbots are about to become the next wave — and most practices do not know the difference between a compliant chatbot and one that is quietly building a liability pile.

I run Zellyfi. We build AI chatbots for dental, chiropractic, veterinary, and wellness practices, which means HIPAA is a question we answer on almost every sales call. This guide is the plain-English version of that answer: what HIPAA actually covers, when your chatbot crosses into protected health information, the seven technical controls that separate a compliant vendor from a risky one, whether ChatGPT and Claude can qualify, and the exact questions to ask a vendor before you sign anything.

One disclaimer up front. This is not legal advice. HIPAA interpretation is fact-specific and your compliance counsel has the final word. What this guide gives you is the technical and operational reality you need before that conversation — so you do not waste billable hours re-learning acronyms.

What HIPAA actually covers (and what it doesn’t)

HIPAA — the Health Insurance Portability and Accountability Act of 1996 — is a federal law that regulates how covered entities and their business associates handle protected health information (PHI). Three terms, one definition each:

• Covered entity — healthcare providers (dentists, doctors, chiropractors, veterinary practices are not technically covered entities under federal law but often operate as if they are because of state laws and contracts), health plans, and healthcare clearinghouses.
• Business associate — any vendor that receives, stores, processes, or transmits PHI on behalf of a covered entity. This is where AI chatbot vendors land.
• PHI — any individually identifiable health information, which HHS defines broadly. It includes the obvious (medical records, diagnoses, prescription history) and a long list of the less obvious: names, phone numbers, email addresses, dates of birth, IP addresses, and photos, when those identifiers are tied to any health information or service.

The HHS HIPAA privacy rule breaks down into two pieces that matter for chatbots:

• Privacy Rule — governs how PHI can be used and disclosed. The headline principle is minimum necessary: never request, retain, or share more PHI than you need for the specific purpose.
• Security Rule — governs how electronic PHI (ePHI) must be protected. Three categories of safeguards: administrative (policies, training, role definitions), physical (server access, device controls), and technical (encryption, access controls, audit logs).

What HIPAA does not cover: veterinary practices (pets are not people under federal HIPAA), cash-only aesthetic services that do not bill insurance, general wellness coaches, personal trainers, and direct-to-consumer supplement sellers. Many of these operate as if HIPAA applies anyway — state privacy laws, CCPA, and patient trust all push in the same direction. But the federal penalty risk is narrower than most vendor marketing suggests.

When your chatbot IS a HIPAA concern — and when it isn’t

This is the section most compliance guides dodge. The honest answer: it depends on what the chatbot touches. A chatbot that collects only a name and “interested in a consultation” is handling less regulated data than one that asks about symptoms, medications, or insurance. Here is a decision tree that actually reflects how OCR thinks about this.

The borderline case is where most practices get tripped up. A dental chatbot that asks “what brings you in?” and the patient types “tooth pain since the crown I had placed in 2023” — that answer is PHI. The chatbot itself cannot filter human messages before they arrive. Which means even a chatbot you designed to avoid PHI can receive it from an unprompted patient. The compliance question is not “will PHI arrive?” — it’s “what happens when it does?”

The four scenarios that actually come up in healthcare chatbot deployments:

1. Appointment booking only. Name, phone, preferred time, maybe appointment type. Treat as PHI-adjacent — get a BAA even if you think you do not need one, because patients will volunteer more information than your form asks for.
2. Pre-visit screening or symptom triage. The chatbot asks health questions to route or prioritize the patient. Clearly PHI — BAA required, full Security Rule controls required.
3. Insurance verification or pricing estimate. The chatbot asks for insurance carrier and member details. Clearly PHI — BAA required, plus specific controls around payment card industry (PCI) standards if you also take payment.
4. Post-visit follow-up or treatment education. The chatbot discusses the patient’s specific treatment plan. Highest-risk category — BAA plus strict access controls, because the conversation itself is medical record material.

For a deeper view of how booking-specific workflows handle this, see our AI appointment booking guide which covers compliant booking flows across dental, wellness, and clinical settings.

The 7 technical requirements every HIPAA-compliant chatbot must meet

This is the checklist. If a vendor cannot answer “yes, and here is our documentation” to each of these, they are not ready to handle PHI. Most of these come from the HIPAA Security Rule Technical Safeguards (45 CFR 164.312); a few are operational norms that have become expected in practice.

1. Business Associate Agreement (BAA) signed and on file

The BAA is the legal contract that makes the vendor a HIPAA business associate. It obligates them to protect PHI to the same standard as the covered entity. Without a BAA, the vendor is not a business associate and cannot lawfully handle PHI on your behalf — full stop. HHS publishes sample BAA provisions that show the minimum required clauses. Real BAAs are longer, but the core obligations are standard.

2. Encryption in transit (TLS 1.2 or higher)

Every chatbot interaction must travel over encrypted connections. This means TLS 1.2 minimum, TLS 1.3 preferred. On the chatbot widget side, the site must be HTTPS-only. On the vendor API side, all internal service calls must also be encrypted — a vendor who encrypts browser-to-server traffic but sends raw PHI between their own microservices is not compliant.

3. Encryption at rest (AES-256)

Stored chat logs, session transcripts, and any derived data containing PHI must be encrypted at rest using AES-256 or equivalent. This covers the database, backup files, log archives, and any analytics storage. Ask the vendor which specific storage services hold your data and confirm each is encrypted — databases often are by default on modern cloud platforms, but log aggregation services and analytics warehouses often are not.

4. Role-based access controls and audit logging

No vendor employee should have blanket access to customer PHI. Access must be role-based, time-bound, and logged. Every read, write, or export of PHI should generate an audit entry that records who, what, when, and from where. Ask the vendor: “Show me a sample audit log for a PHI access event.” If they cannot, walk away.

5. Data retention limits and secure deletion

HIPAA itself does not mandate a specific retention period, but the minimum-necessary principle and state laws create practical limits. Chat logs containing PHI should have a documented retention schedule (commonly 90 days to 6 years depending on purpose) and a secure deletion process at the end of that window. “We keep everything forever for training” is a red flag — that is how vendor training data becomes a breach vector.

6. Breach notification process and 72-hour window

Business associates must notify the covered entity without unreasonable delay when a breach is discovered — commonly within 60 days under HIPAA, but most modern BAAs tighten that to 72 hours to align with GDPR expectations. Ask: “What is your exact breach notification SLA, and what did your last incident response look like (without naming customers)?” Vendors with mature programs answer this confidently.

7. Minimum-necessary configuration of the AI itself

This one is chatbot-specific and often missed. The AI must be configured to not request PHI unless required for the specific task. A booking chatbot should not ask for medications. A triage chatbot should not ask for Social Security numbers. The system prompt, function-calling tools, and guardrails must all implement minimum necessary. Ask: “Can I see the system prompt and the guardrail rules?” If the vendor says no, that is their IP — fine — but at minimum they should walk you through what PHI the bot is designed to never collect.

Common HIPAA violations via chatbots (real patterns, anonymized)

I have seen these during technical due diligence on healthcare chatbot vendors, sometimes during a sales call where a practice describes their existing setup. All are real categories of failure. None identify specific vendors or practices.

Pattern 1: The “consumer chatbot” dressed up for healthcare

A small practice signs up for an off-the-shelf chatbot platform — Tidio, Intercom, Drift, or similar — installs it on their website, and starts collecting patient messages. None of those platforms sign BAAs by default (some offer BAAs on enterprise tiers, most do not). The practice has now made itself a business associate for a non-business-associate vendor. Every patient message that mentions a symptom is a HIPAA violation in progress.

Pattern 2: The vendor that signs a BAA but stores data in uncovered services

A more sophisticated vendor signs a BAA, but routes chat data through services the BAA does not cover — a third-party analytics tool, a translation API, an LLM provider without its own BAA. PHI leaks out the side of the architecture. The customer-facing BAA says the right things; the actual data flow violates them. This is why the question “what services does PHI pass through?” matters more than “do you sign a BAA?”

Pattern 3: Training data contamination

Vendor uses real customer chat logs to fine-tune their model, then serves that fine-tuned model to all customers. PHI from one practice ends up influencing completions for another practice. Technically a violation of both the BAA (unauthorized use) and the Security Rule (access control failure). This is why “we do not train on your data” is now a standard question on healthcare vendor questionnaires.

Pattern 4: The audit log that isn’t

Vendor says they have audit logs. Customer asks for a sample. Vendor produces a general application log — HTTP requests, error messages, deployment events — but nothing that shows who accessed PHI. Under HIPAA, that is not an audit trail. Real PHI audit logs are specific: user X read record Y at time Z from IP W for purpose V. If the log cannot answer “who saw this patient’s chat yesterday,” it is not audit-grade.

Pattern 5: Retention drift

BAA says data is retained for 12 months. Reality: the vendor’s backup system keeps snapshots for 7 years. The analytics team’s data warehouse pulls chat summaries daily and retains them indefinitely. The official retention policy and the actual retention footprint diverge. When OCR audits, they look at actual data — not the policy document.

The vendor questionnaire: 12 questions to ask before signing

Print this, paste it into an email, send it to every AI chatbot vendor you are evaluating. Any vendor that cannot answer all 12 in writing within a week is not ready for healthcare.

1. Do you sign a Business Associate Agreement as a standard part of your contract, or only on specific tiers? If tiered, what is the lowest tier that includes a BAA?
2. Which of your subcontractors also sign BAAs with you (hosting provider, LLM provider, analytics, email, monitoring)? Please list all.
3. What encryption is used in transit and at rest? Please specify cipher suites and key management.
4. Do you train your AI models on customer data? If yes, is there an opt-out? If no, how is that enforced technically?
5. Walk me through a sample audit log entry for a PHI access event. What fields are captured?
6. What is the data retention period for chat logs containing PHI? What is the secure deletion process?
7. What is your breach notification SLA? What does your incident response process look like?
8. How do you enforce role-based access controls internally? How many of your employees have access to customer PHI, and under what circumstances?
9. Do you offer a dedicated instance or is PHI co-mingled with other customers’ data in shared infrastructure?
10. What is your approach to AI guardrails? How do you prevent the chatbot from requesting unnecessary PHI?
11. Do you have SOC 2 Type II, HITRUST, or equivalent third-party certification? Can you share the most recent audit report under NDA?
12. What happens to our data if we cancel our contract? What is the specific deletion timeline and how do you confirm it’s complete?

If this list feels long, it is supposed to. A vendor that handles these well is worth the extra setup time. A vendor that gets defensive or vague on three or more is not ready to store your patients’ information, regardless of what their marketing page claims. For vendor-specific guidance in dental, see our review of the 8 best AI chatbots for dental practices, which flags which platforms do and do not offer BAAs.

Is ChatGPT HIPAA compliant? The direct answer

This is one of the most-searched HIPAA questions of 2026, and it deserves a clear answer instead of the hedging most articles give.

ChatGPT (the consumer product at chat.openai.com) is NOT HIPAA compliant. OpenAI does not sign BAAs for the consumer ChatGPT interface. If you paste a patient note into ChatGPT to summarize it, you have transmitted PHI to an uncovered vendor and created a HIPAA violation. Full stop.

The OpenAI API with a signed BAA CAN be used in a HIPAA-compliant workflow. As of 2024, OpenAI offers BAAs on ChatGPT Team, ChatGPT Enterprise, and the developer API under specific business agreements. If your chatbot vendor is using the OpenAI API under a signed BAA with proper technical controls, that layer is compliant. The vendor still has to handle everything else (storage, access control, your BAA with them, their BAA with OpenAI, audit logs, minimum necessary).

The practical distinction for a practice owner. Almost no legitimate chatbot vendor is giving patients a ChatGPT link. They are using OpenAI’s API under a BAA. What you need to verify is that the vendor’s BAA with OpenAI actually exists (ask for written confirmation), and that your BAA with the vendor covers the full chain. If there is a gap anywhere in that chain, you are uncovered.

Is Claude (Anthropic) HIPAA compliant?

The same structure applies. Claude.ai (the consumer product) is not covered by a BAA. Pasting patient data into Claude.ai is the same problem as pasting it into ChatGPT.

The Claude API, with a signed BAA, can be used in a HIPAA-compliant workflow. Anthropic offers BAAs to qualifying customers via their API. Healthcare-focused chatbot vendors building on Claude typically have a BAA with Anthropic as part of their vendor-of-record responsibility. The practical verification step for a covered entity: ask your chatbot vendor in writing whether they have a signed BAA with Anthropic (or whichever LLM provider they use) and request confirmation before handing over any PHI.

Why Claude is increasingly the choice for healthcare. Two reasons. First, Anthropic’s published policy on not training on API data by default makes the “training data contamination” failure pattern structurally less likely. Second, Claude’s instruction-following on guardrails tends to be stricter out-of-the-box — which matters when the minimum-necessary principle says the AI should refuse to collect PHI it doesn’t need. Neither of these replace BAAs or technical controls, but they shift the baseline in the vendor’s favor.

Implementation checklist: deploying a HIPAA-compliant chatbot in 30 days

Practical 30-day plan for a small practice (dental, chiropractic, wellness, medical spa) moving from “no chatbot” to “compliant chatbot.” Adjust timeline up for larger practices; most of the items stay the same.

Week 1 — Scoping and vendor shortlist

• Define chatbot purpose: booking, triage, insurance verification, post-visit. This shapes which tier of PHI handling you need.
• Identify which data fields the chatbot will collect. Document them.
• Create your vendor shortlist — 3 to 5 vendors that market to your vertical.
• Send the 12-question vendor questionnaire to each. Set a 1-week response deadline.

Week 2 — Evaluation and BAA review

• Score vendors on questionnaire responses. Anyone missing three or more answers is cut.
• Request draft BAAs from remaining vendors.
• Have your compliance counsel review each BAA. Common red flags: missing breach notification SLA, no subcontractor list, permission to train on customer data.
• If possible, talk to two existing healthcare customers of each vendor for reference checks.

Week 3 — Technical setup and staff training

• Sign vendor contract and BAA.
• Configure chatbot: system prompt, guardrails, data collection fields, fallback to human for anything outside scope.
• Test the bot with 20+ realistic patient scenarios. Verify it refuses to handle out-of-scope PHI.
• Update practice privacy notice to mention the chatbot vendor as a business associate.
• Train front desk staff on what the chatbot handles vs. what still goes to them.

Week 4 — Soft launch and monitoring

• Deploy the chatbot on a single page first (most traffic, highest-converting).
• Review the first 50 conversations manually. Look for any PHI your guardrails missed.
• Tune system prompt and guardrails based on real conversations.
• Enable full-site rollout after week 4, or extend soft launch if conversations show gaps.
• Set a 30-day review: conversations, leads, compliance incidents, staff feedback.

For practices looking at the ROI side of this, our AI chatbot ROI guide shows the math on new patient value vs. monthly platform cost — the numbers for healthcare are usually among the highest of any vertical.

Compliance in practice: a dental-office walkthrough

Theory is easier to apply when you see it land on a specific scenario. Here is a compressed version of a real compliance review we ran with a two-dentist practice in Tampa in early 2026. Names and specifics are anonymized; the structure is verbatim.

Setup. The practice wanted a chatbot that would handle three workflows: new-patient booking, insurance-verification triage (“do we accept your plan?”), and a post-treatment FAQ for crowns and implants. All three touch PHI in different ways. They were evaluating three vendors: a generic SaaS chatbot, a dental-specific receptionist platform, and a healthcare-native AI assistant.

The generic SaaS chatbot was eliminated in 10 minutes. No BAA offered on any plan. The sales rep actually said, “HIPAA doesn’t apply to us because we’re just a chat widget.” That is the exact red flag pattern from earlier in this guide — category-error response, not a real position.

The dental-specific platform signed a BAA on their mid-tier ($499/month). They could name their LLM provider, had SOC 2 Type II, and walked us through an audit log sample. The concern was their data retention: 7 years default, no shorter option, chat logs used for “continuous model improvement” unless you filed a written opt-out. Workable, but you have to know to opt out.

The healthcare-native vendor signed a BAA on every paid tier starting at $199/month, opt-out from training was the default, chat logs purged on a 90-day rolling schedule unless explicitly retained for a specific case. They also flagged one scenario we had not thought about: the post-treatment FAQ flow was going to collect more detailed PHI than the other two workflows, and they recommended splitting it onto a separate authenticated patient portal rather than the public website chat. We had not asked about that — the vendor raised it.

The practice picked the healthcare-native vendor, signed the BAA, went live in 62 hours including staff training. Three months in, the bot was handling 38 new-patient conversations per month, 71% of which resulted in a booked appointment, with zero PHI incidents flagged in the vendor’s audit review. Total cost to date: $597 across three months. Incremental revenue attributable to after-hours bookings the practice would otherwise have missed: approximately $18,500 in projected annual patient lifetime value from those 38 conversations.

The point is not the revenue math — that is covered in our ROI deep-dive. The point is the pattern. When the compliance side is handled by a vendor who actually specializes in healthcare, the conversation changes from “can we legally do this?” to “how do we tune the bot for our specific patient types?” — which is the conversation practices actually want to have.

What a HIPAA-compliant AI chatbot actually costs

HIPAA compliance does raise vendor pricing, but less than you’d expect — and in most cases the premium is a rounding error next to the cost of a single missed patient. Real 2026 pricing across the category breaks down cleanly into three tiers.

Put the cost next to the economics. Average new patient lifetime value in dental is $1,200 to $1,500 annually. In medspa, average annual customer spend is $900 to $2,400. In chiropractic, $600 to $1,800. A $199/month chatbot that captures one additional new patient per month has paid for itself 6x over in the first year for most healthcare verticals. The delta between a $49/month non-compliant tool and a $199/month compliant one is roughly two large coffees per day — versus the six-figure penalty exposure of the non-compliant option. Our chatbot pricing comparison for 2026 breaks down the math across every major platform, including which ones actually sign BAAs and which ones charge 10x to access the same clause.

What NOT to do: five red flags that should end the evaluation

1. Vendor says “we’re HIPAA compliant” but won’t sign a BAA. HIPAA compliance for a business associate is the BAA plus the controls. No BAA means no compliance. End of conversation.
2. Vendor offers a BAA only on their “Enterprise” tier at 10x the price. This is legal but predatory. Real healthcare-focused vendors sign BAAs on every paid tier. If BAA coverage is gated behind a pricing wall, the vendor is not healthcare-native.
3. Vendor cannot name the specific LLM provider they use. You cannot evaluate compliance through opacity. Any vendor serious about healthcare will tell you whether they are on OpenAI, Anthropic, Google, or self-hosted, and will confirm the BAA chain with their provider.
4. The product demo includes PHI from a real patient. If the vendor shows you actual patient conversations from other customers during a sales call, they are violating that customer’s BAA. Assume they will do the same to your data.
5. The vendor says “HIPAA doesn’t apply to chatbots.” HIPAA applies to any handling of PHI by a business associate. This is such a basic category error that it disqualifies the vendor from further consideration.

How to survive an OCR audit with an AI chatbot in your stack

The HHS Office for Civil Rights (OCR) is the federal body that enforces HIPAA. Audits happen in two ways: random compliance audits (rare) and breach-triggered investigations (common). The second kind is where most practices first learn what OCR expects. If your chatbot becomes the subject of a breach — or even adjacent to one — here is what auditors will ask for, and what you should have ready.

Documentation OCR expects to see

• The signed BAA between your practice and the chatbot vendor. Not a template — the signed PDF.
• Evidence of the vendor’s BAAs with their subprocessors (hosting, LLM provider, analytics). You do not need copies; you need confirmation that they exist.
• Your current privacy notice, listing the chatbot vendor by name as a business associate category.
• Risk assessment documentation. When you added the chatbot, you should have assessed the risks it introduced and documented the decision. A one-page memo is sufficient for a small practice.
• Training records for your staff on the chatbot’s role and limits.
• Audit logs showing who at the vendor has accessed your data, and when. Most vendors make this available on request; make sure you can get it within 48 hours.

What typically goes wrong under audit

Three failure modes come up repeatedly in published OCR resolutions. First, the practice cannot produce the signed BAA — they remember seeing it during vendor onboarding, but nobody can find the file three years later. Put the BAA in your primary document system the day you sign it, and re-verify annually. Second, the practice added a new chatbot feature (say, insurance verification) after the initial deployment without updating the risk assessment or confirming the BAA still covers that workflow. Third, the practice assumed the vendor handled all the compliance work and did not retain any of their own documentation. Under HIPAA, the covered entity remains responsible; the vendor sharing the burden does not transfer it.

One practical tip: the OCR Breach Portal publishes every HIPAA breach affecting 500+ individuals, including a root cause summary. Reading the last twelve months of entries is the fastest way to see what failure patterns actually trigger enforcement. Patterns repeat.

A note on adjacent regulations that also matter

HIPAA is the headline, but a healthcare chatbot deployment typically touches three other regimes that are easy to forget until they bite:

• State privacy laws. California (CCPA/CPRA), Texas, Washington, and Virginia have their own patient privacy requirements. Some (like Washington’s My Health My Data Act) are stricter than HIPAA on specific categories.
• PCI-DSS. If the chatbot collects payment information — even just a card to hold an appointment — PCI-DSS applies in addition to HIPAA. Most vendors handle this by never actually touching card data themselves; they hand off to a compliant processor (Stripe, etc.).
• FTC Section 5. The FTC has taken enforcement action against healthcare-adjacent companies for deceptive privacy claims. “We’re HIPAA compliant” on your marketing site when you are not — that is an FTC problem, independent of HHS.

For a peer-reviewed academic read on the specific challenges AI developers face with HIPAA, see the 2024 paper “AI Chatbots and Challenges of HIPAA Compliance for AI Developers and Vendors” on NIH PMC. It is dense but authoritative, and covers edge cases (synthetic data, model re-training, inference-time PHI leakage) not commonly addressed elsewhere.

Frequently asked questions

Is ChatGPT HIPAA compliant?

ChatGPT (the consumer product at chat.openai.com) is not HIPAA compliant — OpenAI does not sign a Business Associate Agreement (BAA) for the consumer ChatGPT interface. However, OpenAI does offer BAAs for their API and for ChatGPT Enterprise and Team plans as of 2024. So: using ChatGPT on its own is a HIPAA violation for any covered entity; using the OpenAI API under a signed BAA with proper technical controls can be compliant. The distinction matters — most practices deploying AI chatbots are using the API through a vendor, not ChatGPT itself.

Is Claude (Anthropic) HIPAA compliant?

Anthropic offers HIPAA Business Associate Agreements (BAAs) to qualifying customers using the Claude API. Claude.ai (the consumer product) is not covered by a BAA. For a chatbot built on top of the Claude API with a signed BAA, proper encryption, access controls, and audit logging, a covered entity can use Claude in a HIPAA-compliant way. The key is that the BAA chain is fully connected — from covered entity to chatbot vendor to Anthropic — and that the technical controls are actually in place.

What happens if my AI chatbot violates HIPAA?

HIPAA penalties are tiered by culpability. The 2024 adjusted ranges (per HHS) run from $137 per violation for “did not know” at Tier 1 up to $2.1 million per calendar year for “willful neglect — not corrected” at Tier 4. A single breach can involve hundreds of violations. Beyond federal penalties, state laws may add penalties, and affected patients can sue. Most practical damage comes from the breach notification requirement — you have to notify HHS, all affected patients, and often the media.

Do I need a BAA if my chatbot only books appointments?

Usually yes, but it depends on what data the chatbot touches. A chatbot that only collects a name, phone number, and desired appointment time is borderline — name and phone are identifiers but not always PHI in isolation. The moment the chatbot touches medical information (reason for visit, symptoms, insurance, health conditions), it is handling PHI and you need a BAA. Best practice for healthcare: get the BAA even for booking-only bots, because future feature additions almost always cross into PHI territory.

How is a HIPAA-compliant chatbot different from a regular chatbot?

Three technical differences and one legal one. Technically: (1) data is encrypted both in transit (TLS 1.2+) and at rest (AES-256); (2) access is role-based with audit logs of every read/write to PHI; (3) data retention is limited — chat logs containing PHI are purged on a defined schedule, not kept forever for “training.” Legally: there must be a signed BAA between the covered entity and every business associate that touches the data (hosting provider, AI vendor, analytics).

What is the difference between HIPAA compliant and HITRUST certified?

HIPAA is a federal law — compliance is binary, required, and enforced by HHS. HITRUST is a private certification framework that combines HIPAA, ISO 27001, NIST, and other standards into an auditable program. HITRUST certification does not equal HIPAA compliance (a HITRUST-certified vendor can still be out of compliance), but HITRUST is a strong signal that a vendor takes security seriously. For most small-to-mid-size healthcare practices choosing a chatbot vendor, a signed BAA plus documented technical controls is sufficient — HITRUST is more relevant at enterprise scale.

The bottom line

HIPAA-compliant AI chatbots are not the majority of what healthcare practices see when they search for a chatbot vendor — they are a subset, and the subset is easy to identify once you know what to ask. The vendor signs a BAA on every paid tier. They name their LLM provider and confirm the BAA chain. They answer the 12-question questionnaire in writing within a week. They can walk you through an audit log sample, a breach notification SLA, and their data retention process. They do not use customer data to train their models.

If a vendor hits all of those, the remaining question is product fit — does the chatbot actually convert visitors to booked appointments, does it integrate with your practice management system, does it sound like your practice. Those are the questions you want to be spending your time on, not re-checking whether HIPAA applies.

If you’re evaluating options for your dental, chiropractic, wellness, or medical spa practice, our dental AI platform and wellness AI platform pages walk through how Zellyfi handles each of the seven technical controls above, including the BAA, the Claude API chain, and the minimum-necessary configuration. Or see how we build custom HIPAA-ready AI assistants for specific practice types, and current pricing on our pricing page.

Max Sandborg

Founder, Zellyfi

Max builds custom AI sales assistants for healthcare practices, including dental, chiropractic, veterinary, and wellness clinics. Based in Florida, working with clients across the US. This guide reflects the compliance questions asked on every Zellyfi healthcare sales call — not legal advice.