Is an AI receptionist safe for a clinic? GDPR, security and the questions to ask

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:

You can delegate the answering. You cannot delegate the accountability for what happens to the data.

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 hosted primarily in the EU. Generating replies, transcribing voice notes and reading images involve leading AI providers, under the safeguards set out in our data processing agreement.
• Who owns it. The clinic, entirely. You’re the controller; we act as your processor, and our platform providers as sub-processors, under a written data processing agreement provided before go-live. On exit, your data is returned to you or deleted, at your choice, within 30 days, and cleared from backups within 90 days.
• How long it’s kept. As agreed with you in the data processing agreement. And it’s never used to train AI models, ours or anyone else’s: 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, and breach process.

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.

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.
7. 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.
8. 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.
• 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.

Safety isn’t a feature of the software. It’s a property of the setup: the contract, the hosting, the guardrails, and the humans behind them.

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, a 30-minute call with Rafal covers it: 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.

Common questions