AI Chatbot for Healthcare: A Small Clinic's Data and Consent Checklist

A small clinic needs five things before launch: a signed vendor data contract (a business associate agreement for US patient data, an Article 28 processor contract under UK GDPR), a legal basis for any health data typed in, an AI disclosure in the first message, a written scope that excludes clinical advice, and a route to a human.

If any of those is missing, the safe design is a bot that answers only from an approved fact sheet and tells visitors not to type their name or symptoms. That limited bot is a legitimate first launch, not a failure, and the checks below are grouped in the order to work through them, so the contract and legal-basis items can be settled while it runs.

Follow me on Instagram@sagnikteaches

Which rules apply to you: the first gate

Work out which regime covers the patients you serve before you read any vendor page, because the paperwork differs. A clinic can be under more than one.

Connect on LinkedInSagnik Bhattacharya

• Patients covered by US health-privacy rules. The vendor that handles identifiable patient information for you is a "business associate", and you need a signed business associate agreement (BAA) before any such data goes near it. HHS publishes sample provisions, which require the associate to limit use and disclosure to what the contract permits, use safeguards, report breaches and security incidents, and pass the same restrictions to any subcontractors.
• Patients whose data falls under UK GDPR. The clinic is the controller and the vendor is a processor. Article 28 requires a written contract setting out what the processor may do, and Article 9 treats data concerning health as special category data that needs a stated condition as well as an Article 6 lawful basis.
• Visitors in the EU. The EU AI Act's Article 50 transparency rules cover AI systems that interact directly with people, and they apply from 2 August 2026. The only grace period on the Act's own timeline runs to 2 December 2026 and covers machine-readable marking of AI-generated content (Article 50(2)) in systems already on the market, which is the vendor's job rather than the clinic's. The Act's site marks Article 50 as amended, so read the current text before launch.

Write the answer on one line at the top of your checklist: "Regimes that apply to us: ___". Where you are unsure, ask your data-protection adviser or your regulator's guidance rather than guessing, and treat this tutorial as a working list, not legal advice.

Subscribe on YouTube@sagnikteaches

Checklist part A: the contract gate

This part decides whether the bot may touch personal data at all. If any item fails, the answer is "fact-sheet bot only, nothing collected".

1. A1. The vendor will sign the right contract for your plan. Ask in writing: "Will you sign a BAA / an Article 28 processor agreement for the plan we would buy?" Keep the reply. A vendor's marketing page claiming "compliant" is not a contract. Consider OpenAI's API as an illustration of the pattern: its help centre says a BAA must be accepted before using the API with protected health information, an enterprise agreement is not required, self-serve enrolment needs an established history of API usage, and once enabled it cannot be switched off in the platform settings. Eligibility conditions are normal, so ask each vendor about theirs.
2. A2. The contract covers the product you will use. A signed agreement for a vendor's enterprise product does not cover its cheap plan. OpenAI, for example, says it does not offer a BAA for ChatGPT Business; its agreements cover the API and sales-managed Enterprise or Edu accounts. Check the contract names the exact service, plus any AI model provider behind it.
3. A3. Sub-processors are listed. Article 28 requires the processor to bind any further processor to the same obligations, and you need to know who they are. Ask for the current list and how you will be told of changes.
4. A4. Deletion and return are in the contract. Article 28 expects the processor, at your choice, to delete or return the data when the service ends. Ask how long chat transcripts are kept by default and whether you can set it.
5. A5. The vendor does not train on your chats. Get this in writing for your plan, not just a help-page sentence. Business and API plans from the large providers usually exclude training by default; small builders vary.
6. A6. Breach reporting has a timescale. HHS's sample provisions note that the parties may add a stricter timeframe for reporting a potential breach. Agree one.

A realistic stop. A five-person private clinic picks a builder on its free plan because a free allowance of 100 conversations looks generous. When it asks the vendor about a BAA, the reply is that agreements are available only on a higher plan. Check A1 fails for the free plan, so the clinic either upgrades or launches a bot that collects nothing. Free allowances do exist (Botpress's free plan lists 100 conversations, Tidio gives the first 50 AI conversations free, and Chatbase has no free plan), but a free allowance says nothing about a signed contract.

Checklist part B: the legal basis for what is typed in

People type symptoms into chat boxes whether or not you invite them to. Decide what you will do with that before launch.

7. B1. A named lawful basis (Article 6). For a bot that helps a patient who has approached you, "legitimate interests" or steps taken at the individual's request are the common candidates, and a DPO or adviser should confirm yours. Write it down.
8. B2. A named condition for health data (Article 9). If the bot can receive health information, you need a condition under Article 9(2) in addition to the Article 6 basis. Explicit consent and health-care provision are the ones clinics usually weigh up. Consent under UK GDPR needs a statement or a clear affirmative action, so explicit consent here means a separate, specific opt-in for the chatbot, never a pre-ticked box in a cookie banner.
9. B3. The privacy notice mentions the chatbot. Article 13 requires you to tell people what you do with their data, so add a short section: what the chatbot is, who the processor is, how long chats are kept, who to contact.
10. B4. A data-protection impact assessment decision. Not every bot needs one, but the choice to skip it should be written down with the reasons. A bot that can receive free-text health information handles special category data, so doing one is the cautious choice.
11. B5. Data minimisation in the bot's opening. The first message tells the visitor what not to type.

Before and after. A weak opening: "Hi! Tell me what's troubling you and I'll help." It invites exactly the data you are least equipped to handle. A better one:

Hello, I'm an AI assistant for [clinic name]. I can answer questions about opening hours, fees, parking and how to book. I can't give medical advice, and please don't type your name, date of birth or symptoms here. For anything about your health, call [phone number] or choose "Speak to the team".

The second one states what it is, what it covers, what to avoid and where to go. It also gives you a defence if someone types a symptom anyway: the visitor was told not to.

Checklist part C: telling people it is AI

12. C1. The disclosure sits in the first message. Article 50(1) of the EU AI Act requires that people are informed they are interacting with an AI system unless it is obvious, and paragraph 5 says the information must come clearly and at the latest at the first interaction. Put it in the opening line, not behind a link. The duty is written for the provider, meaning the chatbot vendor, but visitors read it on your website, so check the widget does it and add your own line if it does not.
13. C2. The widget's name does not suggest a human. "Dr Ava" or a stock photo of a nurse implies a person. Use the clinic's name plus "assistant".
14. C3. The disclosure is readable. The same article asks that information conform to accessibility requirements: sufficient contrast, readable by screen readers, not a tiny grey line.
15. C4. Wording checked against the current text of the law. Because the Act's site marks Article 50 as amended, open its current text the week you launch.

More on wording options is in the tutorial on the EU AI Act and your website chatbot, and on the general principle in what to tell customers at the start of a chat.

Checklist part D: scope, no clinical advice, hand-over

16. D1. A written list of allowed topics. Opening hours, services offered, fees, directions, how to book, how to request records, how to complain. Nothing else.
17. D2. A written list of refusals. Symptoms, diagnosis, medication, test results, whether to attend emergency care, and anything about a named person.
18. D3. An emergency line that fires first. If a message contains words such as chest pain or can't breathe, the reply is "call the emergency number now" before anything else. Test it.
19. D4. A hand-over route staff actually watch. A "Speak to the team" button that sends an email to an unattended inbox is worse than no button. Name who checks it and how often. The patterns for this are in when an AI chatbot should hand over to a human.
20. D5. A weekly log review. Someone reads the transcripts (or a sample) every week for the first month. A routine for that is in the tutorial on a weekly chatbot review for clinics.

That makes twenty checks. Print the list, give each a status of Pass, Fail or Not applicable, and a name against every Fail.

A filled-in checklist for one imagined clinic

Here is how the first gate and part A might look for a five-person private physiotherapy clinic with no US patients but some visitors in the EU. The entries are illustrative.

Two fails means a limited launch: the bot answers from the fact sheet only, collects no name or email, and hands every personal query to a human through a phone number rather than a form. That is a legitimate result and a safe one. Move to a richer bot when A1 and B2 turn to Pass.

Questions to send the vendor

A short written enquiry gets you the evidence for A1 to A6 in one go. Adapt this wording:

We are a small clinic considering [product, plan] for a website chatbot. Please confirm in writing:
1. Will you sign a business associate agreement / an Article 28 processor agreement for this plan? If not, which plan?
2. Which sub-processors and model providers handle chat content, and where?
3. How long are transcripts retained, and can we set the period and delete on request?
4. Is chat content used to train any model?
5. How and when will you notify us of a security incident?
6. What happens to our data if we cancel?

Keep the replies with the signed contract. If a vendor answers "we are compliant" without saying yes to question 1, treat it as a no.

Mistakes that show up in real clinic bots

The helpful transcript. A clinic's chat log, exported for a staff meeting, contains a visitor's name, phone number and a description of a rash. Nobody told the staff the log held health data. Fix: restrict access to transcripts, name who may read them, and keep exports out of email.

The answer from the wrong document. A bot trained on the whole website quoted a price from a leaflet two years old. Fix: give the bot one approved fact sheet only, dated, and review it each quarter. The dental example in answering from an approved fact sheet shows the pattern.

The plugin that records everything. Session-recording scripts and chat widgets installed by a web agency can send page content to third parties. Ask who put what on the site, and include chat widgets in your processor list.

The disclosure that vanished on mobile. The notice worked on the desktop widget but was hidden in the collapsed mobile bubble. Test on a phone before launch.

Testing the bot before the public sees it

Run 25 questions and record the exact reply to each. Include five that should work (opening hours, fees), ten that should be refused (a rash, a dose, "should I go to the emergency department"), five that try to extract data ("what did the last patient ask?") and five odd ones (a message in another language, a long paste, abuse). Any wrong answer goes back to the fact sheet or the instructions, then rerun all 25. If you want a second pair of eyes, bring the list and a sample of the replies to a call; the setup question for a chatbot owner is what to leave out, and the tutorial on the scope, disclosure and handover for a doctor's website covers the operating side in more depth.

A sample exchange, and what to fix in it

Seeing a refusal done well makes the scope list easier to write. These two transcripts are illustrative, built for a fact-sheet bot at a small physiotherapy clinic. The visitor types: "I've had sharp pain in my knee since Sunday, should I stop running?"

A reply that fails the checklist: "Sharp knee pain after running can be a sign of runner's knee or a ligament strain. Rest for a few days, apply ice, and avoid running until the pain settles." That is clinical advice from a bot with no examination, no history and no duty of care, written in a confident register.

A reply that passes: "I can't give medical advice, so I can't say whether you should stop running. If the pain is severe, or the knee is swollen or giving way, please contact a clinician today. To book an assessment, I can show you appointment types and fees, or put you through to the team on [phone number]."

Fix the first by adding the symptom topic to the refusal list in D2, adding two or three sample refusals to the instructions, and re-running the 25 test questions. Notice what the passing reply still does: it is useful, because it offers a booking route and a person, and it makes no claim about the knee. A bot that only says "I can't help with that" sends the visitor to a competitor.

A quick sum on retention and log review

Retention sounds abstract until you count. Say the clinic's bot handles 30 chats a day. At 30-day retention, about 900 transcripts sit in the vendor's system at any moment. At 90 days, about 2,700, and the likelihood that some contain a name or a symptom the visitor ignored the warning about grows with it. Cutting the period from 90 to 30 days removes two-thirds of the stored material at no cost, so it is the first setting to look for.

Log review has a cost too. A weekly sample of 10 per cent of 210 chats is 21 transcripts. At about three minutes each, that is roughly an hour a week for the first month, falling to half an hour once the bot settles. Put that hour in the diary of a named person before launch; a review nobody owns does not happen.

Launch week in order

1. Monday. Contract signed, evidence filed, privacy notice updated.
2. Tuesday. Fact sheet dated and loaded; scope and refusal lists in the instructions.
3. Wednesday. The 25-question test run on desktop and phone; failures fixed and re-run.
4. Thursday. Staff briefing: what the bot does, where hand-overs arrive, who answers them.
5. Friday. Launch on one low-traffic page only, such as the contact page, and read every transcript that comes in over the weekend.

Widening to the whole site is a decision for the following week, taken after the transcripts have been read rather than assumed to be fine. If something goes wrong, the switch-off step should be written down: who can disable the widget, and how quickly. Test that too.

What to do if you cannot tick everything

Most small clinics will not pass every item on the first pass, and that is expected. The ones that cannot be skipped are A1 (the contract), D2 (the refusal list) and C1 (disclosure). Without those three, do not launch a bot that collects anything. With them, a fact-sheet bot is safe to start and you can add features one at a time as the other items turn green. Keep the dated checklist: if a regulator or a patient ever asks how you decided, a signed list with evidence attached is the best answer you can give.

Clinic chatbot data questions

Can a chatbot on our website avoid health data entirely?

Only if you design it that way and say so. If the bot answers opening hours, fees and directions and tells visitors not to type symptoms or names, you reduce the data you handle, but people will still type them. Treat anything typed into the box as potentially health data and choose the vendor contract on that basis.

Does a free chatbot plan come with a signed data contract?

Do not assume so. Many free tiers run on standard online terms only. Ask the vendor in writing whether it will sign a business associate agreement or a processor contract for your plan, and keep the answer. If it will not sign for the plan you can afford, the bot must not collect anything personal.

Do we need to tell patients the chatbot is AI even if it is obvious?

Say so anyway. The EU AI Act wording allows an exception where it is obvious to a reasonably well-informed, observant person, but a one-line disclosure costs nothing and removes the argument. A clear first message also sets the limits of what the bot can answer.

Who is responsible if the chatbot gives wrong information?

The clinic, as the publisher of the bot. Vendor terms usually disclaim liability for output. That is why the scope list matters: the bot should answer only from approved text, and anything outside it goes to a person.

Further reads

• Medical AI Chatbot for Providers: Clinical Search or Patient FAQ? — Whether you want a patient FAQ bot or a clinical search tool.
• AI Scribe Patient Consent: Implied or Explicit for UK Clinics? — The same consent questions for recording consultations.
• Veterinary Chatbot: Booking, Pricing and Emergency Hand-Off Rules — Emergency hand-off rules from a veterinary example.
• AI Chatbot for Physio Clinics: First-Visit Questions and Booking Hand-Offs — First-visit questions and booking hand-offs for a physio clinic.
• AI Medical Coding Software: Audit Trails and Upcoding Risk — Suggest or submit? Who signs, what the audit trail must record, how to spot upcoding drift and what to test on 100 old charts.
• Best AI for Healthcare Providers: What to Buy First by Pain Point — A buying order for a small practice: price your missed calls, late notes and denied claims, then pick the phone agent, scribe or claim check.
• Children's Home Software: Which Systems Add AI and What to Check First — Mentor, OVcare and Lindi compared on what their own pages say about AI, plus the checks a registered manager should run first.
• AI Marketing Automation for Doctors: Recall, Reminder and Review Flows — Build recall, reminder and review-request flows in the practice software you already own, with consent, opt-outs and a worked month of numbers.
• AI Tools for Nurses Who Run a Team: Rotas, Handover and Audits — A nurse manager's guide to AI for rotas, handover templates and audit write-ups, with a clear list of what must never go into a prompt.
• AI Tools for Nutritionist Practices: Client Check-Ins and Handouts — How a solo nutritionist can use AI for check-in messages, diary summaries and handouts, with review rules so no unsafe advice reaches a client.
• AI for Naturopaths: Intake Summaries and Follow-Up Emails — A naturopath's guide to AI intake summaries and follow-up emails: what to redact, what to keep out, and prompts to copy.
• AI in Healthcare Billing: Patient Statements and Payment Plan Wording — Draft statement and payment plan wording with merge fields, reconciliation checks and a privacy-safe review route.
• Best AI Tools for Clinicians in the UK: MHRA Status and Data Location — Jane, Tandem, Heidi and general assistants compared on MHRA status, data location and NHS paperwork, with a buying routine for clinics.
• Chartered Society of Physiotherapy and AI: A Clinic Checklist — Turn the CSP's AI principles into a working checklist: what each asks of a clinic, who owns it, what evidence to keep and when to review.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: HHS sample business associate agreement provisions; OpenAI Help Center BAA article; UK GDPR Articles 6, 9, 13 and 28 as published on legislation.gov.uk; EU AI Act Article 50 text and timeline; Botpress, Tidio and Chatbase pricing pages.