AI chatbots on practice websites: privacy questions to answer before you add one

A chat bubble in the corner of a practice website looks like a small change. It can answer questions about hours, insurance and parking at any hour, and it can take a request for an appointment while the office is closed. It also invites patients to type whatever is on their mind, which often includes a name, a phone number and a description of a health problem.

That last part is why a chatbot needs more thought than most website features. This guide covers the privacy questions to answer before you add one, what the agreement with the chatbot provider should say, how to describe the bot honestly, and how to handle emergencies and accessibility. It is written for independent practices weighing a tool, not for developers building one. If you are considering a quiz or symptom checker instead of a chatbot, see our guide to health quizzes, risk calculators and symptom checkers.

What a website chatbot actually does with a message

Before any legal question, find out where a typed message goes. In most products the text leaves the patient’s browser, travels to the provider’s servers, is processed there (sometimes by a separate AI model company the provider works with), and is stored as a transcript. Copies may also land in an email notification to your staff, a dashboard, an analytics report or a log used to improve the product.

Ask the provider to draw that path for you in writing. You want to know every company that touches the text, where it is stored, for how long, who on their side can read it, and whether it is ever used to train or improve their models. If they cannot answer clearly, that is your answer.

• Where is each transcript stored, and for how long by default?
• Which other companies (hosting, AI model, email, analytics) receive any part of a message?
• Can their staff read transcripts, and under what conditions?
• Are messages used to train or improve any model, and can that be turned off in writing?
• Can you export and delete transcripts yourself?

When chat messages become protected health information

HIPAA applies to covered entities, which include most practices that bill insurance electronically, and to their business associates. Under 45 CFR 160.103, a business associate is a person or company that, on behalf of a covered entity, creates, receives, maintains or transmits protected health information for a regulated function. A chatbot provider that receives patient messages for your practice can fit that definition.

HHS has said the same about cloud services in plain terms. Its cloud computing guidance states that a service provider that creates, receives, maintains or transmits electronic protected health information on a covered entity’s behalf is a business associate, even if it only stores encrypted data and does not have the key. The narrow conduit exception is limited to transmission-only services with transient access to the data, which does not describe a service that stores transcripts.

So the practical question is not whether a product calls itself compliant. It is whether patients will type health information into it, and if they will, whether you have the agreement and settings HIPAA requires for that use. A bot on a practice site should assume they will, even if the greeting asks them not to.

What the business associate agreement has to cover

Under 45 CFR 164.502(e), a covered entity may let a business associate handle protected health information only with satisfactory assurance that it will safeguard it, documented in a written contract that meets 164.504(e). That section lists what the contract must do. Among other things, it must:

1. Set permitted uses. Establish what the business associate may and may not do with the information, and not allow anything the practice itself could not do.
2. Require safeguards. Require appropriate safeguards and, for electronic information, compliance with the Security Rule where it applies.
3. Require reporting. Require the business associate to report uses or disclosures not allowed by the contract, including breaches of unsecured protected health information.
4. Flow down to subcontractors. Require any subcontractor that handles the information, such as an AI model company the provider sends messages to, to agree to the same restrictions.
5. Support patient rights. Make information available for patient access, amendment and accounting of disclosures where the contract calls for it.
6. Handle the end. At termination, return or destroy the information if feasible, keeping no copies, or extend the protections if that is not feasible.

Read the provider’s agreement against that list, and read what it covers. Some agreements cover one product tier or one feature and not others. If the chat tool, its transcripts or its AI subprocessor sit outside the agreement, patient information should not go through it. Our own approach on the AI front desk page follows the same rule: confirm in writing what an agreement covers before any patient information flows.

An agreement is necessary but not enough on its own. HHS’s cloud guidance also expects the practice to understand the service well enough to do its own risk analysis and set its own policies. That means deciding what the bot is allowed to ask for, who on your team reads transcripts, and how long you keep them.

Tracking code, the HHS guidance and the 2024 court ruling

Chat widgets often arrive with analytics or advertising code, or send events (“chat started”, “appointment requested”) to tools that also run on the rest of your site. That is where OCR’s guidance on online tracking technologies matters.

OCR says tracking technologies on user-authenticated pages, such as a patient portal, generally have access to protected health information. It also says a disclosure to a tracking vendor without patient authorization requires both a business associate agreement and a Privacy Rule permission, and that a vendor promising to strip or de-identify the data after receiving it is not sufficient. Mentioning tracking in a privacy policy does not make an otherwise impermissible disclosure permitted.

Part of that guidance was vacated. On June 20, 2024, the U.S. District Court for the Northern District of Texas, in American Hospital Association v. Becerra, vacated it to the extent it said HIPAA obligations are triggered when technology connects an individual’s IP address with a visit to an unauthenticated public page about specific health conditions or providers. HHS’s page carries that note and says HHS is evaluating its next steps. The ruling did not touch the parts about authenticated pages, and a chat conversation where someone types their name and symptoms is not the same thing as an anonymous page visit.

In practice: keep advertising pixels and analytics events out of the chat window, do not pass message text or the reason for a visit into any marketing tool, and check what the widget loads with your browser’s developer tools before launch. Our guide to tracking pixels on practice websites goes through that check step by step. Chat vendors that store transcripts can also draw claims under state wiretap laws, which our guide to chat, session replay and wiretap laws explains.

Limit what the bot collects

The simplest privacy control is collecting less. A front-desk chatbot rarely needs a diagnosis to be useful. It needs enough to route a request and call someone back.

• Answer general questions (hours, location, insurance accepted, new patient process) without asking who the person is.
• For appointment requests, ask for a name, a callback number and a preferred time, and leave the reason for the visit to the phone call or a secure intake form.
• Show a short notice above the chat box: what the chat is for, that it is not for emergencies, and to avoid sharing medical details there.
• Keep transcripts only as long as your policy says, and limit who on staff can read them.
• Send staff a short alert that a request came in, not the full transcript by ordinary email.

The same thinking applies to forms. Our guide to HIPAA and website contact forms covers what a contact form should and should not ask, and the reasoning carries over to chat.

Describe the bot honestly

Two kinds of claims need care: what you tell patients about the chatbot, and what a chatbot vendor tells you.

For patients, say plainly that they are chatting with an automated assistant, that it can answer general questions and take requests, and that a person will follow up. Do not let the bot present itself as a nurse or clinician, give medical advice, or suggest it can replace a visit. Write its answers from text your team approved, and review a sample of real conversations regularly.

For vendors, the FTC has been direct. When it announced Operation AI Comply in September 2024, the agency said there is no AI exemption from the laws on the books, and one of the cases involved a service that claimed its AI could substitute for a human professional without testing whether it could. Treat a vendor’s claims about accuracy, savings or “compliance” as claims to verify, and do not repeat them in your own marketing unless you can back them up.

Emergencies and crisis messages

Some people will type an emergency into a chat window, especially late at night. Decide in advance what the bot says, with your clinicians, and test it.

• If someone describes a medical emergency, the bot tells them to call 911 and does not try to assess symptoms.
• If someone mentions thoughts of suicide or a mental health or substance use crisis, the bot gives them 988, which SAMHSA describes as offering 24/7 support by call, text or chat.
• The notice above the chat box says it is not monitored for emergencies.
• Staff know how to find and follow up on any transcript that was flagged this way.

These rules match what we recommend for phone answering in our new patient phone script guide.

Make sure everyone can use it

A chat widget is part of your website, so it should meet the same accessibility standard as the rest of it. Two WCAG 2.2 success criteria come up often with chat tools. Success Criterion 2.1.1 (Keyboard, Level A) requires that all functionality work through a keyboard interface, so a patient who cannot use a mouse can open, type into and close the chat. Success Criterion 2.2.1 (Timing Adjustable, Level A) is about time limits: if the chat times out, users should be able to turn off, adjust or extend the limit.

Also check that the widget does not cover your phone number or booking button on a phone screen, and that it can be closed easily. A phone number should always be visible as an alternative. Our guide to website accessibility for medical practices covers the wider standard.

A short decision checklist

1. Purpose. Write down the three to five jobs the bot will do and what it will never do.
2. Data map. Get the provider’s written description of where messages go and who touches them.
3. Agreement. If patients may type health information, have a business associate agreement that covers the chat feature, transcripts and subprocessors, reviewed by your counsel.
4. Settings. Turn off model training on your data, set retention, limit staff access, keep marketing code out of the chat.
5. Script. Approve the greeting, the answers, the emergency rules and the hand-off to staff.
6. Test. Try it on a phone and with a keyboard only, and check what it loads before launch.
7. Review. Read a sample of conversations each month and update the answers.

If you are comparing a chat tool with a phone-based assistant, our guide to choosing an AI receptionist for a medical office covers the phone side, and our AI front desk page explains how we set ours up.

Which state laws require telling patients they are talking with AI, and wording for chat, voice and letters, are in our guide to state AI disclosure laws for patient messages.

For the notices around the chat window and the rest of the site, see our guide to medical website disclaimers, terms of use and emergency notices.

Sources

• 45 CFR 160.103: Definitions (business associate)
• 45 CFR 164.502: Uses and disclosures of protected health information, general rules (paragraph e, disclosures to business associates)
• 45 CFR 164.504: Uses and disclosures, organizational requirements (paragraph e, business associate contracts)
• HHS OCR: Use of Online Tracking Technologies by HIPAA Covered Entities and Business Associates (with note on the June 20, 2024 court order)
• HHS: Guidance on HIPAA and Cloud Computing
• FTC (September 2024): FTC Announces Crackdown on Deceptive AI Claims and Schemes
• SAMHSA: 988 Suicide and Crisis Lifeline
• W3C: Understanding Success Criterion 2.1.1 Keyboard
• W3C: Understanding Success Criterion 2.2.1 Timing Adjustable

More in Practice websites, privacy and tracking