What patient data AI should never touch

What AI actually needs to help with enquiries

Many private clinics are now looking at AI to help answer enquiries, draft follow ups and offer appointment times. It is a sensible place to start, because most of that work is repetitive and time sensitive. Before choosing a tool, though, it is worth being precise about what information the job requires. The answer is usually much less than suppliers ask for.

To help a front desk respond to enquiries well, an AI tool typically needs:

• The enquiry itself: the message, form or call note that came in through your enquiry channels, with the contact details needed to reply.
• Free diary times: which consultation slots are available, not who is booked into the others or why.
• Your price list: consultation fees, typical treatment prices and any finance options you offer.
• Practical clinic information: opening hours, location, parking, cancellation policy and who the clinicians are.

That is enough to draft a helpful, accurate reply and offer a time. Anything beyond it should have a clear reason.

What it should never connect to

A tool that drafts enquiry replies has no need to see clinical records, treatment notes, medical histories, test results or clinical images. Connecting it to your clinical system “just in case” adds risk without adding value.

Health information is special category data under Article 9 of UK GDPR, which means it needs extra justification and protection. Keeping it out of the communication workflow is the simplest way to reduce what could go wrong. It also keeps a clean line between the people who make clinical decisions and the tools that help with administration.

There is one nuance worth noting. Patients sometimes include health details in an enquiry, for example describing symptoms in a web form. That content still deserves care. Limit who can see enquiry messages, avoid copying them into other systems, and agree with your supplier how long they are kept.

Who is responsible: controller and processor

Under UK GDPR, the clinic is the data controller. It decides why and how patient data is used. A supplier that handles enquiries on the clinic’s behalf is a processor, and it should act only on the clinic’s written instructions under a data processing agreement.

That agreement matters. It should set out what data is processed, for what purpose, how long it is kept, how it is secured, and which other providers the supplier relies on. If a supplier uses an AI model from another company, that company is part of the chain, and you should know who it is and what terms apply.

As one example, Anthropic makes the Claude models. Its commercial terms prohibit it from training its models on customer content sent through its commercial services, and it deletes API inputs and outputs within 30 days by default, except content flagged for misuse or required by law. These are the kinds of commitments to look for and confirm in writing for any provider in the chain.

A person approves every message

AI can draft a reply in seconds, but a member of staff should read and approve it before it reaches a patient. Approval catches tone that feels wrong, prices that are out of date and the occasional reply that strays into clinical territory it should not touch. It also keeps responsibility where it belongs: with the clinic, not the software.

Approval does not need to be slow. A good workflow presents the draft next to the original enquiry and the suggested times, so the person approving it can check and send in one step.

Where the data is processed

Ask where your supplier and each of its providers process data. Processing may take place outside the UK, in which case it should be covered by the transfer safeguards UK GDPR requires. Do not assume a service is hosted in the UK because the supplier is based here. Ask, and ask for the answer in writing.

Questions to ask any supplier

Use this checklist before signing, and take the answers to your own data protection adviser. Nothing here is legal advice, and your adviser can tell you whether anything else, such as a data protection impact assessment, is needed.

• Will you sign a data processing agreement that names us as controller and you as processor?
• Exactly which data will you access, and can you work without any connection to clinical records?
• Which other providers, including AI model providers, will process our data?
• Do those providers use our content to train their models?
• How long are enquiry messages and AI inputs and outputs kept, and how are they deleted?
• Where is data processed, and what transfer safeguards apply if it leaves the UK?
• Does a person at our clinic approve every message before it is sent?
• Who on your side can see our data, and how is access controlled and logged?

Peak Clarity Point was built around these limits: it works from enquiry channels, free diary times and the price list, uses Claude by Anthropic to draft follow ups that staff approve, and never connects to clinical notes. Whichever supplier you choose, the test is the same. If the tool does not need it, it should not touch it.