An optical practice can use AI tools with patient records under UK GDPR only if each tool has a lawful basis and a health-data condition behind it, a written processor contract with the vendor, and a data-protection impact assessment where the use is high-risk. Tools that never see patient data, such as ones that reword newsletters, need none of that.
Optical practices have an odd mix of data: eye-test records, prescriptions, retinal and corneal images, contact lens histories, dispensing orders, recall dates and the family details that come with a child's first test. General GDPR guidance from professional bodies covers the principles well. What it rarely gives you is a way to say yes or no to a specific tool someone has just found. The checklist below supplies that: twelve points, scored, then applied to four typical tools. It is practical guidance and not legal advice, so have your data-protection adviser check how it fits your practice.
What the General Optical Council has said so far
I could not find standalone AI guidance for registrants from the General Optical Council (GOC). Four things it has published are worth knowing. Its plan for 2026-27, dated April 2026, commits it to keeping up with developments in the use of AI and using that understanding to produce guidance for registrants. In February 2026 it joined five other health and care regulators in a joint statement of principles on AI in professional education and training. In its early-2026 response to a call for evidence on regulating AI in healthcare, it pointed to Standard 7.8 of its Standards of Practice for optometrists and dispensing opticians, which asks registrants to keep up to date with digital technologies and apply professional judgement to the data they generate, and said it was due to begin a substantive review of its business standards in 2026, where it expects AI, including businesses' responsibilities when procuring safe and effective AI, to come up. And its 2026 registrant survey profile of optometrists found 76% concerned about AI making errors, 76% about their legal responsibility if something goes wrong, 68% about AI decision-making not being transparent, and 61% about data security and patient confidentiality.
Read that as a direction, not a rulebook. Existing standards on confidentiality, candour and keeping accurate records already apply when AI helps with them, and the registrant who signs a record answers for it. For a business registrant, the practical point is that the practice can show it thought about each tool before using it, which is exactly the procurement question the council expects to examine. A checklist is that evidence.
The 12-point vetting checklist
Score each point 0 (fails or unknown), 1 (partly), 2 (clearly yes), based on documents you have actually seen. A tool that gets patient records needs a high score and no zeros in the first six. A tool with no patient data can skip to the last section.
| # | Question | Where to find the answer |
|---|---|---|
| 1 | Is there a written processor agreement we can sign before use? | Vendor legal or trust page; ask sales in writing |
| 2 | Does the vendor act only on our instructions? | The agreement itself |
| 3 | Is our content used to train models, and is that off by default? | Data-use page; account settings |
| 4 | Where is data processed and stored? Is there a lawful route for any transfer outside the UK? | Sub-processor list; transfer terms |
| 5 | How long are inputs, transcripts, images and logs kept, and can we set deletion? | Retention terms; admin console |
| 6 | Can it enforce access control: named users, roles, an admin who can remove a leaver? | Admin documentation |
| 7 | Does it log who did what, so we can answer a patient or regulator? | Audit log in the admin console |
| 8 | Can we find, export and delete a single patient's data in it? | Support documentation; test with a dummy record |
| 9 | Does the vendor hold recognised security assurance, and will it tell us about incidents promptly? | Security page; contract notification clause |
| 10 | Do we know what the tool does with the output? Is a person checking every clinical item? | Our own workflow design |
| 11 | Can patients be told in plain words, and can they object? | Our privacy notice and reception script |
| 12 | If the vendor closes or we leave, can we take our data with us? | Exit terms; export feature |
How to read the score: 20 to 24 with no zeros in questions 1 to 6 is a candidate for a DPIA and pilot. 12 to 19 means go back to the vendor with questions. Below 12, or any zero in the first six, means the tool stays away from records until the vendor fixes the gap. A vendor that will not answer questions in writing has answered question 1.
The Complete Excel Course with AI Integration
From formulas and pivot tables to Power Query, DAX, VBA and AI with Copilot, ChatGPT and Claude — hands-on from the first lesson.
By Sagnik Bhattacharya and Virginia Thorn, Primetime Emmy Award winner
Buy nowApplying the checklist to four tools
These examples are invented tools with illustrative scores, to show how the reasoning runs.
A website chatbot for opening hours and booking
The chatbot answers general questions and books appointments through the booking system. If it never asks about symptoms and never stores free-text health detail, patient records stay in the booking system, and the chatbot itself holds little more than a name and slot. Score: the contract is clear (2), training is off (2), retention is short (2), but audit logs are thin (1) and exit is unclear (1). The decision is to approve for booking only, add a line telling people not to type symptoms, and give the chatbot a hand-off to a human for anything clinical. The tutorial on an AI chatbot for opticians covers the setup.
An AI scribe for eye examinations
This one records consultations and drafts the record. It processes health data, uses new technology and may process audio, so a DPIA is the right call. Score: it offers a processor agreement (2) and publishes sub-processors (2), but retention of audio is a vendor default the practice can change only on a paid plan (1), and it cannot yet delete a single patient's transcript on request (0). With a zero in question 8, the decision is to hold the pilot until the vendor shows that deletion works. The tutorial on testing an AI scribe for exam notes gives the pilot method once the paperwork is in place.
A retinal image analysis tool
Software that analyses fundus or OCT images is clinical software, not an administrative helper. Beyond the checklist, check its regulatory status as a product and how the clinician stays in control of the finding. On the data side: images are health data, they may contain identifying details in file metadata, and results may feed back into the patient record. Run the checklist as above, and add questions about how the vendor treats images for its own research or product improvement. If the answer is that images help improve the product by default, the practice needs to see that stated and decide whether it is acceptable, and whether patients are told.
A recall and reminder messaging add-on
This tool drafts reminder texts from appointment data. The risk is in what the message reveals and whether the content is marketing. A text that says "your contact lens check is due" is a service message. One that pushes a sale on a discount frame is marketing, and separate rules on electronic marketing consent apply. Check what data the add-on reads (name, number, last test date), whether it stores message history, and whether it sends from a verified number. The wording matters as much as the contract: see recall letters with ChatGPT for safe phrasing.
Four pieces of paper, in optical terms
- Lawful basis and health condition. Article 6 sets a lawful basis for each purpose, and Article 9 sets a condition for health data. For eye care delivered by or under a professional bound by confidentiality, the health or social care condition in Article 9(2)(h) is commonly relied on. A marketing text is a separate purpose and needs its own analysis.
- Processor contract. Article 28 requires a written contract with any vendor handling data on your behalf. It should cover instructions, security, sub-processors, deletion or return of data and help with patient requests.
- DPIA. Article 35 requires an impact assessment for high-risk processing. Health data with new technology is a standard trigger. The tutorial on DPIAs before using AI tools sets out when you need one.
- Approved-tools list. A one-page table of tool, approved use, whether records are allowed, contract and DPIA dates, and an owner.
Which record types can feed which tools
| Data | Free chatbot | Approved tool with contract |
|---|---|---|
| Practice opening hours, frame range descriptions, repair policy | Yes | Yes |
| Anonymous reworded patient FAQ | Yes | Yes |
| Appointment slots with a name and number | No | Yes, if needed for the task |
| Prescription, test results, notes | No | Yes, with DPIA where high-risk |
| Retinal images and scans | No | Only clinical software with its own checks |
| Children's records and safeguarding concerns | No | Only after specific review |
A short example: the staff request that reveals the gap
A dispensing optician asks if she can paste a patient's prescription and lens history into a chatbot to get help drafting a note about a tricky progressive lens problem. Apply the paste test. Is there patient-identifying data? Yes. Is the tool approved with a contract? No. The answer is no, and the better route is to describe the problem generically: "a first-time progressive wearer reports blur on downward gaze at near; list five causes to check in order". The model gives a general list, and she applies it to the real record in the practice system. The same help arrives with no patient data in the tool.
The scribe scorecard, filled in
To show the scoring in use, here is the scribe example from above with all twelve points entered. The scores are illustrative.
| # | Score | Evidence or gap |
|---|---|---|
| 1 Processor agreement | 2 | Standard agreement downloaded and read |
| 2 Instructions only | 2 | Clause confirms processing only for the practice |
| 3 Training off by default | 2 | Stated in data-use page; checked in settings |
| 4 Location and transfers | 1 | Sub-processor list shows one region; transfer terms unclear |
| 5 Retention control | 1 | Audio kept 30 days by default; shorter setting on paid tier only |
| 6 Access control | 2 | Named users, roles, leaver removal |
| 7 Audit log | 1 | Login log only, no per-note history |
| 8 Find, export, delete one patient | 0 | Vendor says "contact support"; no dummy test passed |
| 9 Security assurance and incident notice | 2 | Certificate shown; 48-hour notification clause |
| 10 Human check on output | 2 | Workflow requires clinician approval before filing |
| 11 Patient notice and objection | 1 | Draft wording written; reception script not yet trained |
| 12 Exit and data export | 1 | Export in one format; no deletion certificate |
| Total | 17 | Zero in question 8: hold the pilot, send the vendor a written question |
The total of 17 looks decent, and the zero on a single question is what stops the pilot. That is why the rule about zeros in the first six questions exists, and why question 8 deserves to be in the first group for any tool that stores patient content.
An email to the vendor that gets a useful answer
Vendors reply faster to specific questions. A message like this one works, and it leaves a written record.
Subject: Data protection questions before we pilot [product]
We are an independent optical practice considering a pilot with two clinicians. Before we proceed, please confirm in writing:
1. Do you offer a data-processing agreement under UK GDPR for our plan? Please attach it.
2. Is our content used to train or improve any model? Is this off by default?
3. Where is data processed, and which sub-processors can access it?
4. How long do you keep audio, transcripts and logs, and who can change that?
5. Can you delete or export one patient's data on request? How long does it take?
6. How and when do you notify customers of a security incident?
We will not enter patient data until we have your answers.Save the reply with the date. If the answer is vague, treat it as a no on that point, and if it never arrives, treat the whole tool that way.
Children, families and sensitive records
Children's eye tests are routine in most practices, and their records deserve extra thought. A child's record often includes the parent's contact details, school information, notes about learning or behaviour and sometimes referral letters. Do not let this material go into any tool that has not been through the whole checklist and a DPIA that names children as a group. Be cautious about AI tools that "personalise" messages using data about children, and avoid any tool that profiles patients for marketing. Where a safeguarding concern is recorded, keep it out of AI tools entirely unless the practice has specific advice. When a parent asks how their child's data is used, you should be able to answer in a sentence.
An AI receptionist conversation, and where the limit sits
Here is an illustrative exchange showing where an AI receptionist stays within safe limits and where it must hand over.
Caller: "My glasses snapped at the hinge. Can I get them fixed?" The assistant can answer using general practice information: repairs are looked at in the dispensing area, typical turnaround and opening hours, and it can offer a drop-in or booking. No patient record is needed.
Caller: "I've had a sudden flash of lights and a curtain across my eye." This is a possible urgent clinical problem. The assistant must not reassure, diagnose or book routine slots. It should give the practice's urgent-care script and put the caller through to a person immediately. Design this escalation first, and test it with callers' typical phrasing. A receptionist tool that cannot do this is not ready, whatever its data terms say.
Both situations show why data protection and safety share one process: the checklist covers the contract, and the script design covers what the tool does with the words it hears. The cost side is in AI receptionist costs and call volumes for opticians.
A patient notice sentence for an optical practice
Keep it plain: "We use approved software, including some AI features, to help with booking, reminders and writing up notes. Your optometrist checks anything that goes into your record. Providers handle your information only on our instructions. If you'd prefer us not to use these tools for you, tell us and we'll do things by hand." Have your adviser align the text with your lawful basis, and put it on the website, on the reception sign and in the new-patient form.
Mistakes that show up in optical practices
A practice owner pastes a whole recall list into a chatbot to write personalised messages, so a list of names, numbers and last test dates is now in a consumer service. The fix is to write the message with placeholders and merge from the practice system. An optometrist uses a personal phone to dictate notes, and the app uploads audio to an unknown service. The fix is an approved scribe and a rule that personal apps do not process records. A practice turns on an AI feature in its management software after an update, and the patient notice still says nothing about it. The fix is to ask the vendor to notify you of new features and to review the notice each quarter. None of these involves bad intent, which is why a simple list and a quick vetting beat a long policy no one reads.
What a good staff rule looks like in an optical practice
AI USE AT [PRACTICE]
1. Approved tools are on the list in the staff room folder. Nothing else may receive patient information.
2. Patient information includes names, contact details, prescriptions, test results, images, recall dates and anything that could identify someone.
3. For unapproved tools, describe the situation generically and fill in specifics in the practice system.
4. A registrant checks any AI-drafted clinical text before it enters a record, and signs only what they are satisfied with.
5. Tell [role] before turning on an AI feature in existing software.
6. Report a mistaken disclosure the same day.Rule 5 is the one that gets forgotten: practice-management systems add AI features with a software update, and the practice has not necessarily agreed new terms. See eight practical AI uses for an independent optician for the tasks that fit this rule.
A 90-day plan for a small group
- Days 1 to 15: ask every team member what AI they use, including personal phones. Build the first approved list from the answers.
- Days 15 to 45: score each tool on the checklist. Retire the ones that score zero in the first six questions and request agreements from the rest.
- Days 45 to 75: write DPIAs for tools touching health data, update the privacy notice and brief staff in a 20-minute session.
- Days 75 to 90: pilot one approved tool with one clinician, audit three outputs a week, and decide whether to roll out.
If you would rather work through your shortlist with someone, that is part of what my AI implementation consultation covers.
Optical practice AI and records: follow-up questions
Has the General Optical Council issued AI guidance?
I couldn't find standalone AI guidance for registrants. The council's 2026-27 plan commits it to producing guidance, and it expects AI, including how businesses procure safe and effective AI, to feature in its review of business standards. Check its standards pages for the current position before you finalise your policy.
Are eye-test records special category data?
Yes. Records of a patient's eye health are health data, so you need a lawful basis and an additional condition for handling them. Contact details held alone are ordinary personal data, but linked to appointments and tests they usually become health-related.
Can an AI chatbot answer patients on our website?
Yes, if it only answers general questions and books appointments through a system you control. A chatbot that asks about symptoms or collects health details needs a processor contract, a DPIA and clear disclosure that it is an AI.
Do I need a DPIA for every AI tool?
No. Tools that touch no personal data need none. A tool that processes health records or recordings, especially with new technology, is the usual trigger. If you are unsure, write a short one and keep it with your records.
Further reads
- AI Receptionist for Optometrists: Eye Test Bookings and Recalls — Eye test bookings and recalls by AI receptionist.
- Optician Website: AI-Drafted Eye-Test Pages, Frame Ranges and FAQs — Website pages that need no patient data.
- Optometry Referral Letter Template: Draft With AI, Then Check — Referral letters drafted with AI, then checked.
- AI for Optometrists: Contact Lens Aftercare and Reorder Messages — Aftercare reminders with sensible wording.
- How Independent Opticians Can Use AI for Recalls and Bookings — Recalls and bookings, the usual first project.
- AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.
Sources: UK GDPR Articles 6, 9, 28 and 35 (legislation.gov.uk text); General Optical Council plan for 2026-27, its February 2026 joint statement on AI in education, its 2026 response to a call for evidence on AI regulation and its 2026 registrant survey profile of optometrists; vendor data-handling pages (checked November 2026). Practical guidance, not legal advice; confirm details with a data-protection adviser.