AI Integration · 2026-09-09 · 8 min read
AI Consent for Patients: What We Built Into a Dental Notes Tool
AI consent for patients is an architecture decision, not a form. Shipping AI clinical notes: what gets recorded, who hears it, what the model may not say.

What AI consent for patients requires depends almost entirely on what the software records and where the practice operates. If a tool records the patient, states that require all parties to a confidential conversation to consent put the recording itself in scope, not just the data handling. And everywhere, a clinician still has to read and sign what the AI produced.
The form is the last step. What the product records, what it keeps, and what it is allowed to generate decide what the form has to say. Those are five decisions someone made months before a practice ever printed a page.
We just shipped AI clinical notes inside Smile PreVue, the dental consult platform we build and operate, and we made those decisions first. This is a builder's account of what we chose and why. It is not legal advice, and the consent language a practice uses belongs to that practice and its counsel.
Why the Sutter Health lawsuit changed the question
On April 7, 2026, a putative class action was filed in the U.S. District Court for the Northern District of California against Sutter Health, Memorial Health Services, and MemorialCare Medical Foundation. The complaint alleges that ambient AI documentation tools recorded patient visits without clear notice that the conversation would be captured, transmitted outside the clinical setting, and processed by a third party. It brings claims under the California Invasion of Privacy Act, the federal Wiretap Act, and the California Confidentiality of Medical Information Act.
The legal theory is worth sitting with, because it is not the usual one. It targets the recording itself rather than a downstream breach or misuse. Nothing has to leak for the claim to exist.
Read that as an operator and three things stand out, and all three are product decisions a vendor made before any clinic signed anything: an open microphone capturing the full visit, processing by a third party outside the practice, and retention terms nobody could explain in a sentence. The general privacy notice and the clinician's verbal aside were, per the complaint, doing work they were never designed to do.
This matters beyond health systems. The ADA Health Policy Institute's Q2 2026 poll of 552 private-practice dentists found charting and note taking has the largest planned-adoption share of any AI task, 34.8 percent, against only 7.4 percent using it today. A lot of small practices are about to make this purchase, and they are going to make it on a demo.
Decision one: what we record, and what we refused to record
The tool records the provider dictating or typing the visit. It does not listen to the room.
That single choice moves nearly everything downstream. The recording surface is one person, speaking deliberately, on their own initiative. It captures what the clinician chose to say rather than everything that happened to be said in a room with a patient in it. There is less to disclose, less to store, and a much shorter answer to "what is being recorded" than "the visit."
It is a real trade, and it costs something. An ambient tool captures things the clinician forgets to mention. We decided a smaller, explainable recording was worth losing that.
Being precise about what this does not do: a narrower recording is still a recording. It does not exempt a practice from its state's consent or recording law, and the consent language still has to cover audio that exists. Some states require every party to a confidential conversation to consent. That is a question for the practice's own counsel, and the honest thing a vendor can do is make the answer short enough to give.
The companion decision, made in the same conversation: the raw transcript is always viewable. Nobody has to trust a summary of what was said when the source is one tap away.
Decision two: what the model may say, and what it may never say
The draft uses only what was dictated or typed. When a note would normally contain something that was not said, the tool writes a [confirm: ...] placeholder instead of a plausible finding.
This is the decision we would defend hardest, because plausible is exactly the failure mode. A model asked to produce a complete clinical note will produce a complete clinical note, and the gaps will be filled with whatever a complete note usually contains. That output is not a documentation error. It is a fabricated clinical record with a clinician's name on it.
So the tool never diagnoses and never plans treatment. It documents the diagnosis and the plan the dentist already made, and the dentist reviews, edits, and signs every note.
The same ADA poll makes the market case for that restraint: 82.6 percent of dentists say they do not use and do not plan to use AI for treatment recommendations, the highest rejection rate of any task in the survey. A documentation tool that drifts into judgment is not just unsafe, it is unsellable to the people who would have to sign it. We have written before about why the review gate is the product, not a safety feature bolted onto it.
The review step also matters legally in at least one place. California's AB 3030, effective January 1, 2025, requires disclaimers on AI-generated patient communications about clinical information, and it exempts communications that a licensed human provider has read and reviewed. Note the scope carefully: AB 3030 governs communications to patients, and a chart note is a different artifact than a message sent to a patient. But it is a clear signal about where regulators think the line sits, and human review is on the right side of it.
There is a consent angle to how the writing style works, too. Style setup is a one-time upload of a few of the provider's own past notes, one style per provider, improving from that provider's edits. The model learns a clinician's voice from that clinician's prior work, not from listening to patients.
Decision three: where the audio lives and who can play it
The recording is saved with the patient's note. It plays back only for the clinic's signed-in staff, every playback is logged, and it is deleted when the note, the patient, or the clinic is deleted. Notes stay in the patient record. The finished note is copied and pasted into whatever practice management software the office already runs, with no integration into any of them.
"Deleted with the record" is a smaller sentence than it looks. It means there is no separate audio archive with its own lifecycle that somebody has to remember to purge. Delete the patient and the audio is gone, because it never lived anywhere else.
The model runs on Google Vertex AI under the Google Cloud Business Associate Agreement. We picked that per constraint, not per benchmark. Protected health information on the model path with a signed BAA was the decisive requirement, the same reason the smile simulation runs there. A different job with no PHI in it could reasonably run somewhere else, and we would not argue with that. We have written up the infrastructure half of this separately, in the plumbing problem, so this post can stay on consent.
Five questions to ask any AI vendor before the first recording
This is the checklist we would want a practice to run on us. Each question maps to a decision above, and each has a short correct answer that a vendor either has or does not.
- What exactly gets recorded, the room or the clinician? "The visit" and "the provider's dictation" are different products with different consent obligations. Make them say which.
- What does the model do with something that was not said? If the answer is anything other than "flags it," the tool will invent findings under a clinician's signature. Ask to see it happen on a deliberately incomplete note.
- Who can play the audio back, and is playback logged? "Our support team can access it for troubleshooting" is a real answer some vendors have to give. Better to hear it before signing.
- When is the audio deleted, and does deleting the patient delete it? Retention that runs on its own schedule is retention somebody will forget about.
- Is there a BAA covering the model path, and is our data used to train anything? These are two questions, and vendors sometimes answer only the first. A BAA on the storage layer is not a BAA on the model.
A practice that asks all five learns more in ten minutes than a demo will teach in an hour. The answers are also a decent proxy for whether the vendor thought about any of this before shipping, or worked it out afterward when a customer asked.
The pattern underneath
None of the above is really about dentistry. It is what happens when you take a regulated workflow seriously enough to let the constraints shape the product instead of decorating it afterward.
That is how we work: figure it out, build it, ship it. The figuring-out on this feature was not model selection or prompt design. It was three weeks of deciding what the software was allowed to hear, allowed to say, and allowed to keep. The build followed from those answers, and it was the easy part.
The bolt-on version of this feature makes those choices for the clinic by default. Open microphone, whole visit, vendor-side retention, and a form at the front desk doing the reconciling. That is a legitimate product. It is just one where nobody in the building can explain the recording to a patient in one sentence, and in 2026 that turns out to matter.
If your team is putting AI into a workflow where the rules are real, the questions above are the shape of the conversation worth having. That is the kind of work we do, and you can start a project with us. If you would rather run these tools yourself, we teach that too, over at Learn.
Liked this?
Want this built for your team, or want to learn it yourself? Either way, start here.
Next read →
GPT-6 Astra for Business: What Changed and What Did Not