New: BookedSolid is now ISO 27001 Certified! Learn about our certification
Blog
aiSeptember 20, 2026·11 min read

Is AI Safe to Use with Patient Data? A Data Protection Guide for Clinics

Is AI safe to use with patient data? What UK GDPR actually requires, where the risk sits with an AI receptionist, and the questions to ask any vendor.

By Oliver Crockett
patient datadata protectiongdpr

What the law requires, where the risk really sits, and the questions that turn a vendor's security claims into things a clinic can verify.

Every clinic considering an AI receptionist reaches the same question: is it safe to let AI anywhere near patient data? The caution is well placed. Health information is among the most sensitive data any organisation holds, and the legal responsibility for protecting it sits with the clinic, not with the software company processing it.

The law's answer is more useful than a yes or a no. None of the privacy frameworks that govern clinics in the UK, Australia or New Zealand prohibits AI from processing patient data, and every one of them holds the clinic responsible for what its chosen vendor does with it. Safety is a property of a specific vendor's design and contract, and of the clinic's own process, not of AI as a category.

That reframes the question into one a practice manager can act on: not whether AI is safe, but what would make a particular AI safe. This guide answers it with the law in plain terms, the six places risk sits, a comparison of the three reception models, a vendor checklist, and the clinic-side steps from the DPIA to the privacy notice. It is general information rather than legal advice, so a clinic should confirm its own position with its data protection officer or adviser.

In short AI is safe to use with patient data when the clinic can answer, in writing, where the data is processed, what is collected and kept, who can access it, and what the contract says. No UK, Australian or New Zealand privacy framework prohibits AI from handling health information; each one holds the clinic responsible for the vendor it chooses and the process around it. The risk sits in that choice, not in the technology as a category, and the checklist below is how a clinic runs it down.

What Does the Law Actually Say About AI and Patient Data?

In the UK, patient data is special category data. Article 9 of UK GDPR places data concerning health among the special categories, so processing it needs both a lawful basis under Article 6 and a separate Article 9 condition. For booking, reminders and the day-to-day work of running care, clinics typically rely on the health and social care condition, recorded with their data protection lead. The Data Protection Act 2018 sets the accompanying conditions and safeguards, and the common law duty of confidentiality applies on top of both, as the Caldicott Principles set out.

Two further requirements matter for AI specifically. A data protection impact assessment is required wherever processing is likely to result in high risk, and the ICO's trigger examples include innovative technology and special category data. An AI system handling patient calls sits squarely in that territory, so a clinic should treat a DPIA as required rather than optional. The reference text for the rest is the ICO's guidance on AI and data protection.

The rules did change recently. The Data (Use and Access) Act 2025 amended UK GDPR and the DPA 2018, with the data protection provisions in force from June 2026. The fundamentals for clinics are unchanged: health data remains special category data, the dual lawful-basis requirement stands, and DPIAs are still required for high-risk processing. The ICO is updating its AI guidance to reflect the Act, so its current published position is the one to follow. Separately, clinics with access to NHS patient data or systems complete the Data Security and Protection Toolkit each year, and any supplier touching that data belongs in the same assessment. Australia and New Zealand have their own frameworks, covered below.

"The law does not prohibit AI with patient data. It makes the clinic responsible for knowing exactly what the vendor does with it."

Where the Risk Actually Sits with an AI Receptionist

With an AI receptionist there are six places where patient data is actually protected or exposed, and they are the spine of everything else in this guide.

  • Where the data is processed and stored. The honest unit of analysis is the vendor's sub-processor list, not its marketing page. Many AI receptionists are assembled from third-party speech recognition and language model services, so the real data residency answer is the full set of named regions across every sub-processor, written into the contract.
  • Whether patient data is used to train models. Data absorbed into model training can outlast the contract that supplied it. The safe position is training on patient data switched off by default and excluded in the agreement, not in a support article.
  • What is collected and how long it is kept. A system built on data minimisation collects only what the interaction needs, and states a retention period for each type it keeps: recordings, transcripts, messages and booking details.
  • Who can access it, and whether access is logged. Role-based access limits who can see patient data; an audit trail proves who actually did. Without the log, the clinic cannot answer the most basic incident question: who saw what, and when.
  • What the contract says. The clinic is the controller and the vendor its processor, and UK GDPR requires that relationship to be set out in a written contract, normally a data processing agreement covering security measures, sub-processors, breach notification, and deletion or return of data at exit.
  • The operational failure modes. A reminder sent to the wrong patient, or a booking made against the wrong record, is a data protection incident as well as an admin error, and both risks exist whichever way reception is run. What varies is visibility: escalation rules, human handoff and a log of what was said decide how quickly an error is caught.

Is an AI Receptionist Riskier Than the Alternatives?

Every way of running reception is a data processing arrangement with people, systems and failure modes, so the fair comparison runs the same six risks across the three models a clinic actually chooses between.

RiskEmployed receptionistOutsourced call answeringAI receptionist
Where data sitsIn the practice management system and at the deskThe service's own telephony, systems and staffThe vendor's platform plus its sub-processors, regions per the DPA
Training useNot applicableNot applicableVendor-specific; needs a contractual answer
RetentionNotes and messages, per clinic policyCall recordings and notes, per the service's policyRecordings, transcripts and messages, per the vendor's schedule
Access and loggingAnyone at the desk; spoken calls leave no recordThe service's staff; logging varies by serviceRole-based access with an audit trail, on a well-built system
ContractEmployment contract and confidentiality clauseA processor relationship needing its own DPAA processor relationship needing its own DPA
Error handlingDepends on the person noticing; nothing to replayEscalation per script; recordings where keptEscalation rules, plus logs and transcripts to trace what was said

A human desk carries no sub-processors and no training question, but a mishandled call leaves nothing to audit. An outsourced answering service is a processor with its own staff and systems, and deserves exactly the same contractual scrutiny as an AI vendor. An AI receptionist adds the sub-processor and retention questions, and on a well-chosen system answers them with minimisation, access controls and logging. None of the three is unsafe by nature; each concentrates the security work in a different place.

The Questions to Ask Any AI Vendor Before Signing

The checklist below turns the six risk areas into a due diligence conversation, with the good answer stated for each question. A shorter version appears in the guide to AI for clinics; this is the full set for the file the DPO sees. A vendor that answers all eleven in writing is showing its working; a vendor that cannot is asking the clinic to carry unquantified risk.

  1. Where is patient data processed and stored, and who are the sub-processors? A good answer names the regions and lists every sub-processor, including any speech recognition and language model services behind the product, in the contract or a published list.
  2. Is patient data used to train AI models? A good answer is no by default, stated in the agreement rather than in a settings toggle the clinic has to discover.
  3. What is collected on each call or message, and how long is each type kept? A good answer is a retention schedule per data type, covering recordings, transcripts, messages and booking details, each with a period and a deletion mechanism.
  4. What does the system avoid collecting in the first place? A good answer describes data minimisation by design: the system works from the details the interaction needs, rather than capturing everything and filtering afterwards.
  5. Who at the vendor can access patient data, and is every access logged? A good answer is role-based access with an audit trail the clinic can request, so who saw what, and when, is a lookup rather than an investigation.
  6. Is there a data processing agreement, and what does it cover? A good answer is a DPA offered without being chased, naming the clinic as controller and the vendor as processor, and covering security measures, sub-processor changes, international transfers and liability.
  7. What happens when something goes wrong? A good answer commits to notifying the clinic of a personal data breach without undue delay, in time for the clinic to meet its own 72-hour reporting duty to the regulator.
  8. What happens to patient data when the clinic leaves? A good answer is deletion or return within a stated period after exit, confirmed in writing, with sub-processors covered by the same commitment.
  9. How would the vendor support a subject access request? A good answer is an export of a named patient's calls, transcripts and messages, produced quickly enough to fit the clinic's one-month deadline.
  10. Which security standards has the vendor been audited against, and by whom? A good answer names the standard, the accredited body and the certificate number, so the clinic can verify rather than trust a badge. ISO 27001 is the one most worth asking about: it is voluntary, so holding it means the vendor chose to be examined.
  11. What happens when the AI is unsure or wrong? A good answer is defined escalation to a person, safeguards against wrong-patient messages and wrong-record bookings, and logs that let the clinic trace any conversation afterwards.

What Does the Clinic Itself Have to Do?

Choosing a sound vendor is half the job. Data protection law puts the other half inside the clinic, and most of it is paperwork a practice manager can complete in a week.

A DPIA in five steps

The ICO's DPIA guidance provides templates; the working steps are five:

  1. Describe the processing. What data the AI receptionist touches, where it flows, which sub-processors sit behind it, and what the retention schedule says; the vendor's checklist answers supply most of this.
  2. Assess necessity and proportionality. What the clinic is trying to fix, why this route is proportionate, and what less intrusive options were considered.
  3. Identify the risks. Work through the six risk areas plus anything specific to the clinic, and rate each for likelihood and severity.
  4. Identify the measures. The contract terms, settings, escalation rules and training that bring each risk down, and the residual risk that remains.
  5. Sign off, record and review. The data protection lead signs, the document is filed, and it is revisited whenever the vendor, the sub-processors or the use changes.

The rest of the clinic-side list

  • Record the lawful basis and the Article 9 condition for the processing, confirmed with the clinic's data protection officer or adviser.
  • Update the privacy notice so it names the AI receptionist, what it processes, the vendor behind it and the retention periods.
  • Tell patients that calls are recorded or transcribed, in the greeting and on the website, before the first call is handled; where the clinic's chosen basis relies on consent, collect it properly.
  • Be ready for subject access requests. The right of access covers what the AI holds, transcripts and recordings included, so the export route should be tested before it is needed.
  • Train the team on what the AI does, when it escalates, and who owns the data protection questions patients ask.
  • Have a complaints route. Since June 2026, organisations must make it easy to raise a data protection complaint and acknowledge it within 30 days, and reception is where such complaints arrive first.

How BookedSolid Approaches Patient Data

BookedSolid, the AI receptionist for healthcare clinics, was built for this audience from the start, and the fair way to judge it is the checklist above, the same as for any vendor. Rather than asking clinics to take its security claims on trust, BookedSolid chose to be audited against ISO 27001, a voluntary standard rather than a healthcare-specific one; the certification announcement covers the certificate and scope in detail.

How BookedSolid protects patient data

BookedSolid applies data minimisation throughout, accessing only the details a call, message or booking needs. Patient interactions are encrypted in transit and at rest, and access is role-based and fully auditable. Certification against ISO/IEC 27001:2022 followed an independent audit by the British Assessment Bureau (certificate 272627, issued 4 August 2026), maintained through annual surveillance audits with recertification on a three-year cycle. BookedSolid operates under UK GDPR and EU GDPR, the Australian Privacy Principles and the New Zealand Privacy Act 2020, and the full detail, certificate included, is on the security page.

What Should Patients Be Told?

Transparency is a legal duty, and it is also what patients respond to. The privacy notice should name the AI receptionist and what it processes, and the greeting should say briefly that an assistant answers and that calls are recorded or transcribed. Patients told plainly what is happening judge the interaction on whether it works: the acceptance evidence, reviewed in do patients like AI phone systems, consistently finds that speed and accuracy matter to patients more than who, or what, answers.

Example greeting a clinic can adapt: "Thanks for calling [clinic name]. Calls are answered by our AI assistant and recorded, so the team can check every booking. Ask for a person at any time."

A patient keeps every right the clinic already answers for: to be told how their information is used, to receive a copy of it on request, transcripts included, to have mistakes corrected, and to reach a person on any call. Patient confidentiality does not weaken because software answered the phone.

What Changes in Australia and New Zealand?

The checklist works unchanged in all three markets; what changes is the framework the answers are filed under.

Australia: the Privacy Act 1988 and the APPs

Australian clinics work under the Privacy Act 1988 and the Australian Privacy Principles, which class health information as sensitive information with stronger protections, set out in the OAIC's guide to health privacy. The OAIC's guidance on commercially available AI products sets the expectations: due diligence on the vendor before adoption, clarity on what the product does with the information put into it, and a plain recommendation against entering personal information into publicly available AI chatbots. That last point is the line separating a contracted healthcare product from a general-purpose tool. A clinic remains accountable under APP 8 when patient data is disclosed overseas, so the residency and sub-processor questions carry the same weight, and a privacy impact assessment fills the DPIA's role.

New Zealand: the Privacy Act 2020 and the Health Information Privacy Code

New Zealand clinics sit under the Privacy Act 2020 and, for health information specifically, the Health Information Privacy Code 2020, which applies health-sector rules to health agencies, private clinics included. The Privacy Commissioner's guidance on artificial intelligence expects senior sign-off, a privacy impact assessment before adoption and human oversight where AI handles personal information. Disclosure outside New Zealand and notifiable privacy breaches carry their own rules under the Act, so the residency, breach and exit questions on the checklist map straight across.

The question this guide opened with has a working answer. AI is safe to use with patient data when a named vendor can evidence where data goes, what is kept, who sees it and what the contract commits to, and when the clinic has done its own DPIA, notice and training.

The security answers, ready for due diligence

The BookedSolid security overview sets out how patient data is handled, with the ISO 27001 certificate available to download, and the 7-day free trial runs on the clinic's own phone line with no setup fees and no contract. The compliance questions and the practical ones can be answered in the same week.

Frequently Asked Questions

Is AI GDPR compliant?

GDPR compliance belongs to a specific deployment rather than to AI as a technology; no certification makes a product compliant on its own. An AI system is used compliantly when the clinic has a lawful basis and an Article 9 condition, a data processing agreement with the vendor, a completed DPIA and honest transparency with patients. The same product can be compliant in one clinic and not in another, which is why the vendor checklist and the clinic-side steps both matter.

Can a clinic use an AI receptionist with patient records?

A clinic can lawfully use an AI receptionist that reads and writes its practice management system, and direct integration is usually the safer design, because bookings and details flow between two contracted systems instead of through retyped notes. The clinic should scope what the AI can see to what its job needs, cover both systems in the DPIA, and confirm the AI writes into the record rather than keeping a parallel copy of it.

Is patient data used to train AI?

Whether patient data trains models is a vendor-by-vendor fact rather than a property of AI receptionists as a group. The safe position is training on patient data switched off by default and excluded in the contract, with sub-processors covered by the same terms. A clinic should ask the question directly and treat a vague answer as a reason not to sign.

Does an AI receptionist need a DPIA?

A DPIA should be treated as required before an AI receptionist goes live. UK GDPR requires one wherever processing is likely to result in high risk, and the ICO's trigger examples include innovative technology and special category data, which describes an AI system handling patient calls in almost any clinic. The assessment also forces the vendor questions above before the contract is signed.

Where should a clinic's patient data be stored?

The rule in all three markets is accountability rather than a single mandated location. UK GDPR permits patient data to leave the UK only under an adequacy decision or appropriate safeguards, and Australian and New Zealand law hold the clinic accountable for overseas disclosure. In practice, the vendor should name every processing region and sub-processor in the data processing agreement, and the clinic should record in its DPIA why those arrangements are lawful.

Is an AI receptionist more secure than a human receptionist?

Each reception model is secure when run properly and exposed when not, and they fail differently. A human desk has no sub-processors, but also no audit trail of what was said on a call. An AI receptionist introduces sub-processor and retention questions, and a well-built one answers them with data minimisation, role-based access and a log of every interaction. The deciding factor is not the model but whether the clinic can verify how patient data is handled.

What happens to call recordings and transcripts?

Recordings and transcripts are patient data, so their lifecycle should be written down before the first call: what is captured, the retention period for each type, and how deletion happens at the end of it and at contract exit. They fall within a subject access request, so a patient can ask for them, and the privacy notice should say they exist.

Is BookedSolid ISO 27001 certified?

BookedSolid is certified against ISO/IEC 27001:2022, following an independent audit by the British Assessment Bureau, and the certification announcement covers the certificate, its scope and what the standard involves.

Summarise with AI

Open this article pre-loaded into an AI assistant for a quick summary.