The Five Checks Before You Sign With Any Dental AI Vendor

Most practices are evaluating AI the way they evaluate a new chair. Look at the demo, compare the monthly fee, check the contract length, sign.

That works for a chair. It does not work for software that touches patient records, because the obligations that come with patient data do not transfer to the company that sold you the tool. If an AI vendor builds something that cannot comply, the practice using it is the one in breach.

Sean Perera has spent the last two years watching this happen from an unusual vantage point. He is Chief Technology Officer at Centaur Software, which makes Dental4Windows and Dental4Web, and his team fields three to four AI integration requests a month from companies wanting to plug into that install base. He sees the contracts. He runs the security assessments. He knows which questions the good vendors answer straight away and which ones make them go quiet.

At the end of a conversation on the AI Your Practice podcast, he set out five checks he would run before signing with any AI vendor. They are worth having written down, because most practices are currently doing about one and a half of them.

Write the problem down before you look at the tool

Sean’s first test is not about the vendor at all.

If you cannot write down on a piece of paper, traditional way, conventional way, what problem you are trying to solve, then you should not be looking at AI to solve that problem.

This sounds obvious and it is not. 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.

What a real problem statement sounds like is specific enough to be wrong. A full time working mother wants to book her family in, it is half past five, and the practice is shut. That is a defined problem with a defined cost. Wanting to do something with AI is not.

The related test is capacity. If you or a staff member cannot give the tool two hours a week to check whether it is doing what it promised, Sean’s position is that you should not sign. Two hours a week is the real price of any AI tool, and almost nobody budgets for it.

Note what a software vendor is doing here. He is telling practices when not to buy software.

Research the provider before the demo, not after

The second check is the vendor’s own security posture.

Ask what security certifications they hold. Ask whether they are working towards any. Centaur’s own position is that they plan to pursue ISO 42001 certification, the standard for AI management systems, and Sean is clear that they are not there yet.

That standard is worth understanding even if you never audit anyone against it. As Sean describes it, ISO 42001 is the AI equivalent of an information security management standard. It carries guidelines about the risks involved in AI, particularly around consent, bias in models, and obtaining consent properly. His directive to his own teams has been to build to those principles now, so that at any point in the future they can say the best practice guidelines were followed.

For a practice, the useful version of this check is simpler. A vendor that can name a standard, describe 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, and read the retention clause

This is the check that most practices skip and the one that carries the most risk.

Three questions, and they are not difficult to ask:

Where does my data go, and where is it stored?
Do you use my data to train your models?
How long do you retain my data after I leave you, and can I require deletion at any point?

The third one is where Sean has seen genuine problems.

There are some clauses that I have seen along the way where there is a clause that says, we retain the data indefinitely unless requested otherwise.

Indefinitely. Unless requested otherwise. In a contract a practice signed without reading, covering patient records.

Underneath these questions 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.

That distinction is why saying the vendor handles compliance is not an answer. It is also why the third question matters more than the first two: retention is where a decision made once quietly persists for years.

Understand your own obligations before you switch anything on

The fourth check is inward facing.

The example Sean uses is scribing, because it is the AI application spreading fastest through Australian practices. If you are using scribing in a consultation, you need to let the patient know. If the patient says no, you need to turn it off. And you need to do that consistently, not when it occurs to someone.

Consistency is the part that fails in practice. A consent process that depends on the clinician remembering is not a consent process, it is an intention.

This is also where the compliance risk sits for anyone using generic AI tools in their marketing. AHPRA’s advertising requirements are unambiguous that before and after images must be true and patient consented. An AI generated image cannot satisfy either.

We raised this at ADX with a room that happened to include AI software developers. They asked whether that really meant AI generated images could not be used for before and afters. It does. They were building exactly that tool.

The practice using it would have been the one in breach, not the company that sold it. That asymmetry is the reason all five of these checks exist.

Give it ninety days, with checkpoints

The last check is about what happens after the signature.

Sean’s framing is that you need a plan for making the tool work, with checkpoints. A month in, has it started solving the problem you wrote down? Then his line, which is the most useful sentence in the whole framework:

I call it the practice’s 90 day grace period. If it has not done what it promised to do in 90 days, it ain’t gonna do it.

Ninety days is generous. It is long enough for a real implementation, a training gap and a bad first fortnight. It is short enough that a tool quietly failing does not sit on the ledger for a year because nobody wants to admit the decision.

Write down what the tool promised on the day you sign, not from memory in month four.

The check that is not on the list

There is a sixth thing worth adding, and it comes from the disagreement in the middle of that episode rather than the framework at the end.

Sean’s belief is that AI cannot fix a broken workflow. If your workflows are broken, he says, AI can only amplify them. It runs the wrong process faster.

He is right, and there is a story from his own team that proves it better than the argument does. Centaur was building a predictive model for whether a patient will turn up. His machine learning engineer came back with a practice that had recorded no cancellations in three years. Sean did not believe it, checked, 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 that nobody thought of as a data decision.

Where we would extend his argument is that AI can at least show you where the workflow is broken. If a tool tracks which questions your team keeps asking, and reports back that the same information is missing from your knowledge base every week, it is diagnosing the practice rather than just serving it. That does not fix anything on its own. It does tell you what to fix, which most practices have never had.

But the underlying point holds, and it applies before any of the five checks. If the practice is not working well, the cause is almost always human rather than technical. Give the best AI in the world to someone who was not doing the job, and they still will not do the job.

What to do this week

Take the tool you are closest to signing for, and write its problem down on one page.

Not the feature list. The problem, in the terms the practice actually experiences it, with a number attached. How many calls, how many hours, how much revenue, how often.

If that page is hard to write, you have your answer, and it cost you twenty minutes instead of a twelve month contract.

If it is easy to write, keep the page. It becomes the thing you check the tool against in ninety days.