On a Friday in September I finished the plan for a small piece of automation I called the Review Desk. It was meant to help dental practices with their Google reviews.
The idea was simple. When a new review arrived, the system would read it, choose a suitable reply from a set of approved templates, and put a draft in front of a person. The person would check it and post it. Nothing would go out on its own.
I had written safety rules into the plan. Drafts only. Templates only. Never confirm that the reviewer is a patient. Send anything serious straight to a human. No procedures, no dates, no clinicians' names, no arguing with the reviewer.
It looked responsible. Before building anything, I ran it through the same compliance screen I use for clients and asked one question: is this safe to launch?
The answer was no. There were four separate problems, and any one of them would have stopped it. None of them were where I expected.
The plan
There were four moving parts.
- An email agent, software with its own inbox that can read incoming mail and reply, would receive Google's "you have a new review" emails.
- A drafting agent would read each review, pick template one, two or three, or flag it as serious, and write a draft reply.
- A workspace database would hold the templates and a queue of drafts.
- As a backup, an automation box, a computer in the cloud running a web browser, would log in to the practice's Google profile every weekday morning to catch anything the emails had missed.
A person would then approve the reply and post it.
I intended to offer this to practices. That detail mattered more than anything else.
Mine 1: the friendly reply that gave away a patient
This one hurt, because it was hiding in the part I thought was finished.
My template for good reviews said:
Thank you for taking the time to share this. We're glad you had a good experience with our team.
My template for mild complaints said:
Thank you for your feedback. We're sorry this didn't meet your expectations.
Both sound warm. Both quietly confirm that the reviewer was seen at the practice. "A good experience with our team" says they came in. "Didn't meet your expectations" says there was an experience to judge.
The first rule on my own list was never to confirm that someone is a patient. I had broken it in the first line of the first template.
There is a second problem. The reviewer may not be a patient at all. It could be a relative, a competitor, or someone who never came through the door. A reply that treats them as a patient either gives away something true or states something false. Neither is safe.
The rule was right. The wording broke it. I had written both, so I never noticed.
The fix is to reply to the review, not to the person's care. These are the rewritten templates.
For a good review:
Thank you for taking the time to leave a review. Feedback like this means a great deal to the team.
For a mild concern:
Thank you for this feedback. We are sorry to read it. Please contact the practice directly so we can understand what has happened and put it right where we can.
For a serious complaint, or anything clinical:
Thank you for raising this. We take all feedback seriously and we have a formal complaints procedure. Please contact the practice directly and we will respond through it. We are not able to discuss anyone's care publicly.
For anything involving harm, legal threats or safeguarding: post nothing until the practice's named lead has decided. If a holding reply is needed, use the serious complaint template word for word.
If I could keep only one line, it would be the last sentence of the serious complaint template. It explains the silence without confirming anything, and it reads as professional rather than evasive.
Mine 2: I had already said no to this
The moment a practice's reviews pass through software I run, I am handling that practice's data on its behalf. In data protection terms, that makes me a processor. It requires a written contract with every practice, and I cannot bring in any other company to handle that data without the practice's permission.
My plan brought in three: the email agent, the workspace database and the automation box. Each would receive review content. There were no contracts and no permissions.
What made this worse is that I had already reached this conclusion. Three weeks earlier I had looked at a commercial review-reply tool and decided not to build one, for exactly this reason. I wrote it down at the time.
Then I designed one anyway, because this time it was framed as a helpful workflow rather than a product.
The framing changed. The data did not.
Mine 3: the password on the box
The automation box needed to log in to each practice's Google profile. In plain terms, that means a practice's Google password stored on a computer run by someone else.
That breaks Google's terms. It takes control of the profile away from the practice. If anything went wrong, nobody could say who did it.
The proper routes already exist. Google provides an official way for software to connect to a business profile with the practice's permission and no password shared. A practice can also add a named person as a manager of its profile. Both can be granted, limited and taken back. A shared password allows none of that.
Mine 4: a review is health data
A review of a dental practice, with the reviewer's name and a mention of treatment, tells you something about that person's health. Data protection law treats health information as the most sensitive category there is.
Using new technology to process that kind of information routinely, across several practices, is exactly the situation that calls for a formal risk assessment before you start. My plan had none.
The regulators are moving in this direction too. The ICO has said it is preparing guidance to help small organisations check the AI tools they buy. Practices should expect to be asked what checks they made. A supplier who cannot hand over a risk assessment is making that harder, not easier.
The smaller hazards
Beyond the four main problems were several that would not stop a launch but would cause trouble later.
- The complaints clock. A review that is really a complaint may start the practice's complaints procedure and its deadlines. My backup check only ran on weekday mornings. A serious review posted on a Friday evening would sit untouched until Monday.
- The machine deciding what is serious. The system was told never to use a standard template for serious cases. But the system was still deciding which cases were serious, and missing one is the failure that matters most. The fix is to lean hard towards caution: anything under three stars, or anything mentioning harm, legal action, refunds or distress, goes to a person first.
- Where the data lives. Two of the services were based in the United States. That can be lawful, but only with the right certifications or agreements in place. My plan also kept copies in two places with no rule for when they would be deleted.
- The privacy notice. Each practice should tell patients that review replies are drafted with AI help and checked by a person. It costs nothing and it is honest.
The mine I nearly laid myself
Compliance mistakes run in both directions, and the screen caught one of mine going the wrong way.
My instinct was to add an AI disclosure to every reply. I use strict disclosure rules for all AI-generated patient content, and it felt consistent.
It would have been wrong. The European rules on disclosing AI-written text are aimed at text that informs the public on matters of public interest. A reply to a Google review is not that. Even where the rules might apply, there is an exemption when a person checks the text and takes responsibility for it, which is exactly what happens here. For UK-only practices those rules may not apply at all.
The same goes for medical device rules. The Review Desk does not diagnose, monitor or recommend treatment. It is not a medical device and should not be labelled as one.
Overcompliance is not caution. It teaches people the rules are arbitrary, and it wastes their attention on warnings that don't apply.
The question that got me out
After the verdict, I asked a question that felt almost too simple. What if the system did not write anything? What if it only told the practice that a new review had arrived?
That changed everything.
If the alert says "the practice has one new review, two stars, follow this link", nothing about any patient ever enters my systems. No review text. No reviewer name. No mention of treatment.
That means no sensitive health data. No processor role. No formal risk assessment triggered. No question about data going overseas. The template problem, the missing contracts and the risk assessment all fall away at once.
Two conditions keep it that way.
First, the alert must not be a forwarded Google email. Google's own "new review" email includes the reviewer's name and the full review. Forwarding it to an email agent is full processing dressed up as an alert. The system has to write its own message: practice, number of reviews, star rating, time, link. The moment it says "two stars, mentions implants", you are back in the minefield.
Second, the password problem does not go away. Something still has to connect to Google to know that a review exists. A shared password is the same failure whether the software then drafts a reply or just counts. The official connection, or a named manager, is still required.
The alert is not the reply
This is the point I most want other practices and other builders to take away.
In AI workflows, the risk is not spread evenly. It gathers at one moment: when the machine reads something about a person and writes words about them. Watching is cheap. Speaking is expensive.
The useful part of the Review Desk, the part that saves a practice time, is knowing quickly that a review has arrived. That part carries almost no regulatory weight. All four problems lived in the drafting: reading the review, choosing the words, and keeping copies.
Many AI tools now being offered to dental practices bundle the watching and the speaking together, because the speaking looks impressive in a demonstration. Separate them, and you often find that most of the value sits in the part that is easy to make safe.
Watching is cheap. Speaking is expensive.
Where it stands now
The Review Desk is designed, not built. The design is now in two stages.
Stage one is a watcher. It connects to Google the proper way, sends an alert containing no review content, and keeps a record of what it sent.
Stage two is the drafting, using the rewritten templates. It would only go ahead once there are contracts with each practice, a completed risk assessment, checked suppliers, and a named person responsible for serious reviews with a set response time.
Stage two may never happen. If it does, it will be because that work is done, not because the demonstration looked good.
If you are about to buy or build one
Whether it is a review tool, an AI receptionist or a note-taker, the questions are the same. What does it read? What does it write? Where does it keep things? Who can get in?
This is the screen I run first, on my own builds and on the tools practices ask me about: dentalcompliance.app
For the detail-minded
- Mine 1: GDC Standards for the Dental Team, Standard 4.2.3: "You must not post any information or comments about patients on social networking or blogging sites."
- Mine 2: UK GDPR Article 28, processor contracts and sub-processor authorisation.
- Mine 3: Google's account terms and its terms on automated access. The proper routes are the Google Business Profile API with OAuth, or a Manager role on the profile.
- Mine 4: UK GDPR Article 9 (special category data, including health) and Article 35 (Data Protection Impact Assessments).
- Where the data lives: UK GDPR Chapter V. The UK-US data bridge is in force, and the ICO confirmed in July 2026 that it stands independently of the EU arrangement. European regulators have since asked for the underlying framework to be reviewed, so it should not be treated as permanently settled.
- Overcompliance: EU AI Act Article 50(4), which covers AI-generated text published to inform the public on matters of public interest, with an exemption where a person reviews it and holds editorial responsibility. Because a person approves every reply, UK GDPR Article 22 on fully automated decisions is not engaged either.
- How long this stays true: The GDC's consultation on a new Framework for Professionalism, which will replace the Standards for the Dental Team, closed on 31 August 2026. The current Standards remain in force until the outcome is published. Dental Protection has asked the GDC to include explicit expectations on the use of AI. I will update this piece when that lands.
This essay was developed with an AI screening assistant. I reviewed it, and I own every judgement in it.
Screening tool, not legal advice. Regulatory positions reflect the law as understood at the date above, and legislation changes. Obtain independent legal advice before deploying any AI system.