Smileprooflog inBook a demo

Smile Simulation & AI

Cloud Smile Simulation and Patient Privacy: The Questions to Ask Any Vendor

Cloud smile simulation sends a patient's photo to a server, so privacy is a fair first question. Here are the exact questions to ask any vendor — and the answers to expect.

Abdullah Talab — founder of Smileproof. A year of dental school in Turkey, then medical school in Jordan; he built Smileproof after watching cosmetic consults fail for want of a believable before-and-after.

Simulated preview — a visualization aid, not a guaranteed outcome.

Cloud smile simulation sends a patient's photo to a server to generate the preview, so the fair first questions are simple: what is stored, for how long, is it used to train models, and where is it processed? A vendor that cannot answer those clearly is telling you something. This is a plain-language guide to the privacy questions worth asking before you put any patient photo into any cloud tool — and what a straight answer should sound like.

What happens to a photo in cloud smile simulation?

In a cloud tool, the photo leaves the operatory, a model generates the preview, and the image comes back — usually in seconds. The privacy question is what happens in between and afterwards. Our own position is specific and written down, and it is a reasonable benchmark to hold any vendor to: Your photo is processed transiently to create the preview and is never stored by Smileproof. Our AI provider may retain inputs for a limited period (up to 55 days) solely for abuse monitoring under its data-processing terms. It is never used to train models. Notice what that sentence does: it separates what we store (nothing) from what the AI provider may briefly hold for abuse monitoring, and it rules out model training outright. Vague reassurance — “we take privacy seriously” — is not the same thing. The same honesty we apply to the image itself, where every preview is labelled a visualization aid, not a guarantee, we extend to the data behind it: say plainly what happens, and put it in writing. A vendor's willingness to be specific about storage is a good proxy for how it will behave with everything else.

What questions should you ask any vendor?

Six questions separate a serious privacy posture from a marketing one. Ask them in writing.

  1. What do you store, and for how long? “Nothing” should be backed by specifics.
  2. Does your AI provider retain inputs? If so, for how long and why?
  3. Are photos ever used to train models? The right answer is no.
  4. Where is the data processed? Region matters in regulated markets.
  5. Who is the controller and who is the processor? (You are almost always the controller.)
  6. How does a patient's data get deleted? And can you prove it?

If the answers arrive as a shrug or a sales deflection, that is your answer.

What does “processed transiently” actually mean?

Transient processing means the image is used to compute the preview and then released, rather than filed away in a database tied to the patient. It is the difference between a tool that uses a photo and one that keeps a photo. This matters because a stored library of identifiable patient faces is a liability that grows quietly over time — a breach waiting to happen — whereas a transient flow leaves far less to lose. Ask vendors to describe their flow in exactly these terms; the ones who cannot are usually storing more than they would like to say.

Does the AI provider train on the photos?

This is the question most vendors hope you will not ask. Many consumer AI services reserve the right to use inputs to improve their models unless you are on specific terms that forbid it. For patient photos, that is not acceptable, and the answer you want is unambiguous: inputs are never used to train models. A brief retention window purely for abuse monitoring — a fixed number of days, then gone — is a normal, disclosable part of a provider's data-processing terms; open-ended training use is not. Insist on the distinction.

Who is the controller and who is the processor?

In data-protection language, the clinic is almost always the controller — you decide why and how the patient's data is used — and the software vendor is a processor acting on your instructions. That framing has practical consequences: the duty to obtain the patient's consent, and to be able to explain the data flow, sits with you. A good vendor makes that easy by giving you clear, quotable answers you can pass to a patient; a poor one leaves you exposed by being vague. Understanding the roles is how you avoid signing up for a liability you did not realise was yours.

What about patients in regulated markets?

Clinics serving patients in markets with data-protection regimes should go one step further: confirm that consent is captured before a photo is processed, and that any cross-border processing is covered by the vendor's terms. This is not a reason to avoid cloud tools — it is a reason to choose ones that are transparent about storage, training, and region. Our security page lays out our position in the same plain language we would want from anyone else, and the broader ethics discussion lives in AI in the dental chair.

What should honest vendor answers look like?

Green flags are specific and boring: named retention windows, an explicit no-training commitment, a clear controller/processor split, and a deletion path. Red flags are the opposite: “we don't really store anything” without detail, silence on training, or a refusal to put answers in writing. The tell is confidence with specifics. A vendor that has thought seriously about patient privacy will sound almost dull about it — and that is exactly what you want handling your patients' faces. A useful final test: ask for the answers as a short written statement you could hand a patient who asks. A vendor that can produce that in a sentence or two has done the work; one that promises to “get back to you” has not. Pair this with good capture habits from photo requirements for a good simulation.

Want our privacy answers in writing before you trial anything? book a demo — qualified clinics get a trial set up personally after a short demo.

AT

Abdullah Talab

Abdullah Talab — founder of Smileproof. A year of dental school in Turkey, then medical school in Jordan; he built Smileproof after watching cosmetic consults fail for want of a believable before-and-after.

See it on your own patients.

Book a 20-minute demo and leave with a 30-day pilot — 100 previews and 5 lab reports, no card.

Book a demo →