In short
An AI receptionist can be safe for a UK clinic, but the safety lives in the setup, not the software: a written Article 28 data processing agreement, the clinic as data controller, minimum collection, UK or EU storage with safeguards for any transfers, no medical advice by design, and instant human handover. Any provider who can't evidence those in writing hasn't earned patient enquiries.
Every conversation I have with a practice manager reaches the same moment. They like the idea of every enquiry answered in seconds, and then they pause: but what about patient data? I want to say this before anything else in the post: that pause is correct. Clinics should be harder to convince than any other business I work with, and a provider who gets impatient with your questions has already answered the most important one.
So here's the buyer's guide I'd want you to have: what actually happens to data when an AI receptionist answers an enquiry, the questions to put to any provider (including us), and the red flags that should end a conversation early. One caveat up front. I'm a founder, not a solicitor. Treat this as practical guidance for asking better questions, not legal advice; for anything contractual, involve whoever advises your practice on data protection.
Why clinics are right to be careful
Under UK GDPR, health data is special category data: the class of information the law singles out for extra protection because misuse can cause real harm. Most people picture clinical records when they hear that. The sensitivity starts much earlier than the record does.
When someone messages your clinic “do you do ingrown toenail surgery, and how soon could I be seen?”, they've told you something about their health. The message arrived over WhatsApp rather than across the front desk, but the care it deserves is the same. Patient enquiries are sensitive by nature, before a single clinical note exists.
And the accountability sits with you. The clinic is the data controller: you decide why and how patient data is used, and that responsibility stays yours even when a supplier does the processing on your behalf. Which is the sentence I'd put on the wall of every practice manager's office:
What happens to patient data when an AI receptionist answers?
Strip away the jargon and the flow is short. A message arrives on WhatsApp, web chat, SMS, email or a social DM. The system reads it and drafts a reply from an approved knowledge base: your services, your FAQs, your booking rules, nothing it found on the open internet. It asks for what it needs to book, then writes the conversation, the contact details and the appointment into one system your team can see.
Four questions decide whether that flow is safe: what is collected, where it lives, who owns it, and how long it is kept. I'll use our own setup as the worked example, because those are the answers I can put my name to. The same four questions apply, word for word, to anyone else you talk to.
- What's collected. The minimum needed to book: name, contact details, enquiry topic. No probing for symptoms, no clinical questionnaires in the chat, and transcripts handled as enquiry data, not clinical records. Anything sensitive or uncertain goes straight to your team.
- Where it lives. Conversation, contact and appointment data is stored in the EU. Generating replies involves leading AI model providers whose processing may take place in the US, protected by Standard Contractual Clauses and the UK International Data Transfer Addendum. The messages themselves travel through each channel's own infrastructure (a WhatsApp message always passes through WhatsApp), under the same safeguards.
- Who owns it. The clinic, entirely. You're the controller; we and our platform providers act strictly as processors under a written data processing agreement provided before go-live. On exit, your data is exported to you and then deleted within 30 days.
- How long it's kept. To your retention policy, not ours. And it's never used to train public AI models: the assistant answers only from the knowledge base you approve.
The full version, written for IT and compliance reviewers, is on our security page: sub-processors, access controls, breach process, and what is and isn't certified, stated plainly.
What should you ask a provider before signing?
Take this list into every demo, ours included. Good providers enjoy these questions, and the reaction you get is itself part of the answer.
- Who owns the data, and what happens when we leave? The right answer: you own it, you're the controller, and on exit everything is exported to you and deleted within a stated period. Anything woollier than that is a no.
- Will you sign a data processing agreement? Article 28 of UK GDPR requires a written contract whenever a supplier processes personal data on your behalf. It should be offered before go-live, not negotiated out of them afterwards.
- Where is data stored and processed? You want named locations: UK or EU storage for the conversation data, and named safeguards for anything processed elsewhere, such as Standard Contractual Clauses plus the UK addendum.
- Who are your sub-processors? Every provider builds on other companies; that's normal. What matters is a written list with purposes and locations, usually an annex to the DPA, available before you sign.
- How long is data kept? The only good answer: to your retention policy. A provider with one fixed retention period for every client hasn't thought hard about clinics.
- Is our data used to train AI models? The answer should be a flat no. Replies should come from a knowledge base you approve, which is also where the guardrails get set; I've written about what “trained on your business” actually means because the phrase hides a lot.
- What happens with sensitive or clinical messages? By design: no medical advice, no discussing conditions or symptoms, and an instant handover to your team. Ask to watch the handover happen live in a demo.
- What happens if there's a breach? You need to be told fast, with enough detail to meet your own duties (as controller you may have 72 hours to notify the ICO). Ask for the notification commitment in writing, and while you're at it, ask how day-to-day access is controlled: named individuals, multi-factor authentication, least privilege.
If the system will also send reminders or follow-ups, add a ninth question about PECR, the UK's electronic messaging rules. Service messages such as confirmations and reminders are fine; anything promotional needs consent or a soft opt-in.
Red flags that should end the conversation
- Vague answers. “It's all encrypted and fully GDPR compliant” is a sentence, not an answer. Every question above has a specific, checkable answer. A provider who can't give one either doesn't know or doesn't want you to.
- No DPA, or paperwork promised “after go-live”. The agreement is the protection. If it arrives after your patients' data does, it protected nothing.
- Certification claims that can't be shown. If a provider says ISO 27001 or SOC 2, ask to see the certificate and its scope. Honesty runs the other way too: our own security page states plainly what is and isn't certified at platform level, because you finding out in an audit would be far worse. A missing certificate, plainly declared, is a conversation. A claimed certificate that can't be produced is the end of one.
- A bot that gives medical advice. Test this in the demo. Ask something clinical and watch what happens. The only right behaviour is to decline politely and hand over to a human. A bot that plays doctor in a demo will play doctor with your patients.
- Silence on the basics. No straight answer on where data lives, who the sub-processors are, or what happens on exit. One check you can run yourself in thirty seconds: a UK company processing personal data should normally appear on the ICO's public register.
Is an AI receptionist safer than what you do now?
Here's the framing I believe is honest. The comparison is not an AI receptionist versus a perfect system, because no clinic runs a perfect system. It's an AI receptionist versus what actually happens to enquiries today: voicemails sitting on a machine in reception, patient details on sticky notes, a shared inbox with one password the whole team knows, Instagram DMs answered from someone's personal phone on the bus home.
A well-run AI receptionist can be more consistent than that. Not because AI is inherently safe, but because a system applies the same rules to every enquiry at 2am as at 2pm: collect the minimum, log everything in one place behind access controls, escalate sensitive cases the same way every single time. Humans bring judgement, which matters enormously. Systems bring consistency, which a tired human at 6pm on a Friday can't. I've compared those trade-offs properly in AI receptionist vs human receptionist vs answering service.
But notice the phrase “can be”. It's doing real work. A badly chosen bot is worse than the sticky notes, because it fails at scale and sounds confident while doing it. The technology doesn't make a deployment safe. The contract, the hosting, the guardrails and the humans behind it do.
What to do next
If you're evaluating providers, ours included, the process that protects you is short. Ask the eight questions above in writing and keep the answers. Ask for the security documentation and pass it to whoever reviews IT for your practice. Read the DPA before go-live, not after. Run the awkward-demo test with a clinical question and watch for the handover. And message the demo yourself, because whatever you experience is what your patients will.
If you want to see how this fits a clinic specifically, our clinics page shows the setup end to end. And if you'd rather start with a conversation about your own enquiry handling, the free Strategy Call takes about 20 minutes: we review how enquiries are handled today, estimate what's slipping away, and show what to fix first. No obligation, no pressure.
The same data discipline runs through everything else we build for clinics, because the rules do not stop at the chat window. Review requests have their own compliance shape, which I have unpacked in what the GDC actually allows on Google reviews, and recall messaging sits under PECR just like any other text. If you would rather hold the controls yourself, the self-serve platform opening this autumn bakes in the same guardrails: your AI answers only from what you approve, and it never guesses.
Ask us the hard questions
Get a free Strategy Call: about 20 minutes on how your enquiries are handled today, what's slipping away, and what to fix first. No obligation, no pressure. Or experience the live demo as your own customer via the number on our homepage.
Common questions
Is an AI receptionist safe for a clinic under UK GDPR?
It can be, but the safety comes from the setup rather than the technology. A safe deployment has a written Article 28 data processing agreement, the clinic as data controller, minimum data collection, UK or EU storage with safeguards for any transfers, no medical advice by design, and instant human handover for anything sensitive. A provider who cannot evidence those in writing is not safe, however clever the product.
Is a patient enquiry special category data under UK GDPR?
Health data is special category data under UK GDPR, which means it needs extra protection. A simple enquiry can reveal health information by implication: asking about a treatment says something about the sender's health. The cautious approach is to treat every patient enquiry as sensitive, collect only the minimum needed to book, and keep clinical detail out of the conversation entirely.
What is a data processing agreement and do I need one?
A data processing agreement, or DPA, is the written contract Article 28 of UK GDPR requires whenever another company processes personal data on your behalf. It sets out what the processor may do, its security obligations, its sub-processors and what happens on exit. If an AI receptionist provider does not offer one before go-live, that alone is reason to walk away.
Who owns the data an AI receptionist collects?
The clinic should own it completely. You act as the data controller and the provider acts strictly as a processor, working only on your instructions under a written agreement. On exit, the data should be exported back to you and then deleted within a stated period. Vagueness about ownership, export or deletion is a red flag, not a detail to sort out later.
Can an AI receptionist give medical advice?
It should be configured never to. A well-set-up AI receptionist handles administration only: bookings, reminders, opening hours and general questions. It does not discuss conditions or symptoms, and anything clinical or sensitive is handed straight to the clinic's own team. If a demo bot happily chats about symptoms, treat that as a serious warning about the provider's judgement.
What security questions should I ask an AI receptionist provider?
Ask eight things: who owns the data, whether they will sign an Article 28 data processing agreement, where data is stored and processed, who the sub-processors are, how long data is kept, whether your data trains AI models, how sensitive conversations reach a human, and how breaches are notified. A good provider answers all eight in writing without hesitation.
