How to Choose AI Tools for Your Dental Practice That Actually Work

Wondering which of the AI tools arriving in dentistry are actually worth paying for? Curious how to tell a product that will survive a Monday morning at your practice from one that only performs in the demo?

In this article you will find where the real AI opportunity sits inside a practice, how to vet a vendor before you sign anything, what you carry legally that the vendor does not, and how to know within ninety days whether the tool is working.

This article was created together by Sean Perera and Carolyn S Dean. For more about Sean, scroll to the end of this article.

Why the AI conversation in dentistry is pointed at the wrong end of the practice

More than twenty AI stands appeared at ADX this year. Most of them were selling something clinical.

That is where the attention has gone since the category opened. Diagnostic imaging, radiograph analysis, treatment simulation. It is the visible end of a practice and it demonstrates well on a trade show floor.

Sean Perera thinks the attention is in the wrong place. He is Chief Technology Officer at Centaur Software, which makes Dental4Windows and Dental4Web and holds the largest practice management install base in Australia. His team fields three to four AI integration requests a month from companies wanting to connect to it, which gives him an unusual view of what is actually being built.

His position is that the burden sits in the admin area. Recalls, reactivation, debt collection, referrals, patient communication, attendance. The work that never gets demonstrated at a trade show because it is not interesting to look at.

His rule of thumb is that around 20 per cent of the administrative work in a practice can be automated or done with the help of AI. That figure is his own estimate rather than a published industry statistic, and he is careful to say so.

Centaur waited about two years before building its own AI, while the generative wave settled. Sean frames that as a product decision rather than caution: two years of watching produced a map of what practices need, and what they do not.

Two tests before you look at any tool

Before looking at any tool, Sean applies two tests. Both are refusals dressed up as questions, and both are unusually direct coming from someone who sells software for a living.

The paper test: Can the problem be written down on a piece of paper, the conventional way, before anyone opens a laptop? If it cannot, Sean’s position is that AI is not the answer, because there is no defined problem for it to solve. Most practices arrive at an AI decision from the wrong end. Something is demonstrated at a conference, or the practice down the road has one, and the search begins for a problem the tool might fit.

The two hours test: Can the owner or a team member give the tool two hours every week, checking whether it is doing what it promised? If nobody can, the tool should not be bought. Two hours a week is the real price of any AI product and almost nobody puts it in the business case. It then lands on the practice manager, on top of everything else, and quietly stops happening by week five.

What a defined problem sounds like is specific enough to be wrong. Carolyn S Dean uses online booking as the model. A full time working mother wants to book her family in, it is half past five, and the practice is shut. That is a problem with a shape and a cost attached. Wanting to do something with AI is not.

The counter example is one she saw in her early agency days. A Queensland practice knew precisely that its patient base was empty nesters aged 55 and over, then ran a mouth guard campaign. Asked why, the owner said the practice down the road was running one.

Sean expects AI to split the market the same way online booking did fifteen years ago. Some practices bought it because a competitor had it. Others should have bought it and never saw the point.

Vet the provider before the demo, not after

Sean’s second contribution is a framework he set out at the close of the conversation. It is the most reusable thing in the episode.

Understand the problem: The first check is the paper test above. Everything else is wasted effort without it.

Research the provider: The second is the vendor’s own security posture. Ask what certifications they hold and which they are working towards. Centaur’s own position is that it plans to pursue ISO 42001, the standard covering AI management systems, and Sean is clear that they are not there yet. The standard carries guidelines on AI risk, on bias in models and on obtaining consent, and his directive to his teams has been to build to those principles now. For a practice, the useful version is simpler: a vendor who can name a standard, say what it covers and say plainly where they sit against it is a different proposition from one that says the word secure a lot.

Ask where the data goes: The third is three questions. Where is my data stored, do you use it to train your models, and how long do you retain it after I leave. Sean has read contracts that retain practice data indefinitely unless the practice requests otherwise.

Understand your own obligations: The fourth is inward facing and is covered in section three below.

Have a plan with checkpoints: The fifth is what happens after the signature, covered in section four.

Underneath the third check sits a distinction almost nobody is explaining to practice owners. The practice remains the data controller. When an integrator extracts data, the processor role transfers to them for that data only. The responsibility for the patient relationship does not move, which is why saying the vendor handles compliance is not an answer.

What Centaur will not do for you

One thing worth knowing about how AI reaches Australian practices. Centaur has made a deliberate decision not to select an AI partner on the practice’s behalf.

Sean describes it as building an integration layer instead of an exclusive relationship, so a practice can do its own homework and choose. For a practice owner that means the choice stays theirs, and the due diligence does too.

What you carry, not what the vendor carries

This is the section most practices skip, and it is where the exposure is.

AI generated before and after images are not allowed

Carolyn was speaking at ADX, running through the advertising guidelines the way she usually does. Before and after images have to be true, they have to be the patient’s own, and consent is required to use them.

Some AI software developers in the audience asked whether that really meant AI generated images could not be used for before and afters. It did. They were building exactly that tool.

The consequence is the part practice owners keep missing. If an AI tool produces marketing that breaches the advertising guidelines, the person in breach is the registered practitioner and the practice, not the company that built it and not the agency that ran the campaign. Buying from a vendor does not transfer a professional obligation.

Consent for scribing happens every time, not once

Scribing is the AI application spreading fastest through Australian practices, and it looks clinical while functioning as admin, because the clinician stays in charge of the note.

Sean’s position is that if scribing is used in a consultation, the patient needs to be told, and if the patient declines it needs to be turned off. Consistently, every time. A consent process that depends on the clinician remembering is not a process, it is an intention.

The landmark cases have not happened yet

Sean compares where dental AI sits to the early years of driverless cars, when the technology arrived before the case law did and the pattern resolved through a small number of very public incidents.

He expects the same here: a few significant breaches, some landmark rulings, and practices facing serious claims over patient privacy. His view on the twenty AI stands at ADX is that a similar number will appear next year, and the interesting question is how many of this year’s are still trading.

Pro Tip: Write the problem statement down before the first demo, never after. A demo is designed to define the problem for you, and once it has, the practice is no longer evaluating whether it has a problem. It is evaluating that vendor’s answer to a question the vendor asked.

Test it against your own workflow, then give it ninety days

Sean holds a strong view that AI cannot repair a broken workflow. It runs the wrong process faster.

The proof came from his own team. Centaur was training a model to predict whether a patient will turn up. His machine learning engineer reported one practice with no cancellations recorded in three years. Sean did not believe it, went and looked, and found the practice had created a separate appointment column called Cancellations and was dragging appointments into it so the front desk could follow up and rebook them.

Sensible for the team. Invisible to the model. Three years of cancellation data destroyed by a workaround nobody thought of as a data decision.

Carolyn accepts the premise and extends it. AI will not repair a broken workflow, because the cause is almost always human rather than technical, and giving a better tool to someone who was not doing the job does not make them do it. What a tool can do is surface where the workflow is broken. One that tracks the questions a team keeps asking, and reports back which information is missing from the knowledge base, is diagnosing the practice rather than only serving it.

Then the last check. Sean’s framing is that any new tool needs a plan with checkpoints, and a limit.

He calls it the practice’s ninety day grace period. If the tool has not done what it promised within ninety days, it is not going to.

Ninety days allows for a rough first fortnight, a training gap and a slow start. It is short enough that a tool quietly failing does not sit on the ledger for a year because nobody wants to be the one who admits the decision.

What both of them return to is that the technology is only ever as good as the people running it. Asked what will not change in five years, Sean names the clinician holding the ultimate decision, and the fact that he would still choose a practice where a person greets him at the door rather than a bot carrying a tray of coffee cups.

Sean Perera is Chief Technology Officer at Centaur Software, the company behind Dental4Windows and Dental4Web. He has worked in the Australian dental industry since 2004, joined Centaur five years ago as a product manager, and has held the CTO role for the last two years. Connect with him on LinkedIn.

Other notes from this episode

This episode was recorded with students from Macquarie University, following on from filming at ADX earlier this year.
Read the full framework in The Five Checks Before You Sign With Any Dental AI Vendor.
The AHPRA advertising guidelines referenced throughout are on the AHPRA advertising hub.
Connect with Carolyn S Dean on LinkedIn.
Trilbii AI is in pre launch. The waitlist and Lighthouse Program are open.