Almost every psychologist I speak to is using AI in some form. ChatGPT for letters and reports, a transcription tool for session notes, perhaps a formulation prompt or two when the diary is overwhelming. The clinical thinking behind these choices is usually sound: clinicians want to spend more time with clients and less time on admin, and AI is the most plausible way to get there. The compliance side, though, tends to lag behind the clinical instinct, often because there hasn't been clear guidance and the existing privacy notice was written years before any of this was on the horizon.
The good news is that the work to bring AI use into a defensible position is not difficult, but it is overdue for most of us, and the regulatory landscape has moved enough recently that it is worth a proper look. The ICO has just been formally tasked with writing a statutory code of practice on AI under SI 2026/425, the Global Psychology Alliance published guidance on AI in psychological practice in April that was welcomed by the BPS Cyberpsychology Section, the BPS is recruiting a Task and Finish Group to develop UK-specific practice guidance over the next eighteen months, and the HCPC, while it has not yet issued clinical-practice guidance on AI, will, when it does, sit the new guidance alongside existing standards on record-keeping, confidentiality, and consent that already apply to all of this work.
I've written this guide as the document I wish had existed two years ago, when I first started thinking carefully about AI use in my own practice. At that point I was already using a few tools, hadn't done much of the compliance work, and couldn't find anything written by a clinician that would help me close the gap. Most of what was available was either generic data protection content that didn't engage with the specifics of psychological practice, or technical documentation from vendors that assumed a level of regulatory literacy most of us don't have. This is the orientation I'd have wanted then. It's not legal advice, and it assumes you're a sole practitioner or small practice without a DPO on retainer. The aim is to give you a clear, workable picture of where you need to be, and to make the next steps obvious.
Lawful basis and special category data
The framework most of us learned around record-keeping still applies, but few of us have revisited it since AI tools entered the workflow. Under the UK GDPR, every act of processing personal data needs a lawful basis under Article 6, and every act of processing special category data needs an additional condition under Article 9. Both need to be identified, documented, and reflected in your privacy notice.
For most clinical work, the combination that fits is legitimate interests under Article 6(1)(f), supported by a documented Legitimate Interests Assessment, alongside the health-and-social-care provision under Article 9(2)(h). HCPC registration satisfies the professional-secrecy requirement that Article 9(2)(h) needs, so as a registered psychologist you're well-placed to rely on it. The full guide goes into when consent is and isn't the right basis, and how recent changes under the Data (Use and Access) Act 2025 affect us, which is less than you might think given clinical data sits in the special category.
Whatever combination you land on, your privacy notice needs to reflect it. Most private practice privacy notices were written before AI tools were in use and don't address any of this. Updating yours is one of the first practical steps in moving from informal use to something defensible. The full guide includes sample wording you can adapt.
Sub-processors and the data chain
This is the area where most of us have done the least work, and where the gap between current practice and defensible practice tends to be widest.
When you use an AI tool, your data doesn't just go to the vendor. It flows through a chain. You are the controller. The vendor providing the AI tool is the processor. Behind the vendor sits cloud infrastructure, usually one of the three hyperscalers. Behind that sits the model provider, often a separate company in a separate jurisdiction. There may be a transcription layer, often a separate vendor again. There may be storage or analytics services. Each of these is a sub-processor, and as the controller, you are legally responsible for the entire chain under the UK GDPR's accountability principle.
The honest truth is that most of us using AI tools couldn't currently sketch our own data chain. I couldn't have done it eighteen months ago, and bringing it into clear view has been some of the most useful compliance work I've done. The questions you want to put to every vendor, in writing, before any client data touches their system are reasonably short. Who are your sub-processors, and is the list published? Where is the data processed, geographically? Is data used for model training, by you or by any of your sub-processors? What is your incident notification commitment, and in how many hours? Will you sign a UK GDPR-compliant Data Processing Agreement?
Vendors who are ready for clinical use answer these clearly and in writing. Vendors who give vague answers, who can't produce a sub-processor list, or who can't commit to a specific incident notification timeline are telling you something useful about their maturity. The full guide includes a one-page vendor questionnaire designed to be sent before contract.
The clinical record and AI
HCPC standards on record-keeping and confidentiality apply to AI-assisted records in the same way they apply to any clinical record. The fact that an AI tool helped draft a note doesn't change what the note needs to be, and it doesn't change your responsibility for it.
The thing that actually protects you, both clinically and legally, is your review of the output. AI tools hallucinate. They fabricate dates and quotes, occasionally invent details that weren't present in the source material, and sometimes misattribute who said what. The defence against this is the same as the defence against any documentation error: read it carefully before accepting it. I've found it helps to approach AI output the way I'd approach a first draft written by a thoughtful but inexperienced colleague, useful, often substantively right, but always requiring active engagement before it becomes mine.
On Subject Access Requests, the practical position most of us land on is that the final note is the record, and intermediate AI drafts, if discarded after review, are working documents rather than part of the controller's holding. The position gets weaker if drafts are retained alongside the final note, in which case they form part of the file and would be disclosable.
Professional indemnity
This is the conversation most of us haven't had with our insurer yet, and it's the one I'd encourage you to have first.
Most PI policies were written before AI tools were in common use, and most insurers haven't published clear positions on AI use in clinical practice. That doesn't mean cover is excluded, but it does mean assumptions are unwise. Worth dropping your insurer a line in writing to ask three things: whether your current policy covers claims arising from clinical work in which AI tools were used, whether there are any AI-related exclusions, and whether they want to be notified of AI use as a material change to practice. Keep their response on file.
This is the kind of housekeeping that costs nothing and creates real protection. An insurer's position established in writing in advance is more useful than one established under pressure later.
A practical checklist
If you can answer each of these clearly, you're in a defensible position. If you can't yet, this is the work.
- You've identified your Article 6 lawful basis and Article 9 condition, and documented an LIA where you're relying on legitimate interests.
- You've reviewed each AI vendor's sub-processor list, data residency, model-training policy, and retention policy, and you hold the answers in writing.
- You've completed a DPIA for AI processing, or you've documented why one wasn't required.
- Your privacy notice reflects current AI use, names sub-processors where possible, and identifies the lawful basis.
- Your consent-to-treatment conversation includes AI use, in plain language.
- You've written to your PI insurer about AI use and have their response on file.
- Your clinical supervision arrangements include discussion of AI tools.
- You're reviewing AI output substantively rather than waving it through.
Most of us using AI today couldn't tick all of these yet. That's the honest starting point, and it's also the case for the practitioners I most respect on this. None of it is technically hard. It's just overdue.
Where to start
If you're sitting with a list like this for the first time, I'd suggest starting with two things. Write to your PI insurer this week, that conversation tends to clarify everything else, and it's the cheapest piece of protection on the list. Then sit down with your privacy notice and your current AI tools, and map your sub-processor chain for each one. Almost everything else flows from those two pieces of work.
The full guide expands each section with worked examples, a DPIA template, a vendor sub-processor questionnaire, sample privacy notice language, a glossary, and a full reference list. It's designed to be the working document you can actually use, including the templates you'll want when you sit down to do this properly.
If you find errors, omissions, or developments worth including, I'd be glad to hear from you. This is a fast-moving area, and the guide will need updating.
Download the full guide as a PDF
Dr Aisha Tariq is an HCPC Clinical Psychologist.