Informed consent for AI documentation: what to actually tell clients
Before you press record, there’s a short conversation that matters more than the software you use: telling the client what’s about to happen to their words. Informed consent for AI documentation isn’t a checkbox or a buried clause in your intake packet. It’s a plain-language explanation of what gets captured, where it’s processed, how long it’s kept, and who actually writes the note that ends up in the chart. Get that conversation right and the technology stops being the thing the client has to worry about. Get it vague and you’ve introduced a quiet trust problem into the room.
This post is about the substance of that disclosure: what clients actually need to hear, in words they’ll understand, and why processing that happens entirely on your own device makes the whole explanation shorter.
What clients actually need to be told
Most consent language fails by being either too thin (“we may use software to assist with notes”) or too technical to mean anything. The useful middle is to answer the questions a thoughtful client would ask if they thought to ask them. There are four.
- What is captured. Be specific. If you are recording, say so: audio of the session, a written transcript made from it, and a draft of your clinical note. A client who pictures a recorder is imagining something different from a client who pictures a typed transcript sitting in a file. Name all three.
- Where it is processed. This is the part clients increasingly care about, because “AI” often means a recording sent to someone else’s servers. Tell them plainly whether their session data leaves the room. If you use a cloud transcription service, that is a disclosure you owe them. If processing happens entirely on your own machine, that is a materially different and much shorter sentence.
- How long things are kept, and what is deleted. Audio and transcripts are not the same as the note. Tell the client which artifacts are temporary and which become part of the record. “The recording is deleted after I finish the note; the note stays in your chart” is a sentence anyone can follow.
- Who writes the note. This is the one clinicians most often skip, and it is the most important. The software produces a draft. You read it, correct it, and sign it. You remain the author of record, and the note reflects your clinical judgment, not a transcript run through a model. Say that out loud.
A good rule of thumb: if a client later asked “where did my words go and who saw them,” your disclosure should already contain the answer.
A sample plain-language consent paragraph
Here is language you can adapt. It is written to be read aloud or dropped into an intake form, not to impress a compliance reviewer. As always, the rules that bind you vary by state, licensing board, and payer, and none of this is legal advice, so confirm the specifics with yours.
To help me write accurate notes, I use a tool on my own computer that records our session, creates a written transcript, and drafts a clinical note. Your session is processed only on my device. It is not uploaded to the internet, and there is no outside company or account involved. The recording and transcript are deleted after I finish the note; the note itself becomes part of your confidential record. I review and edit every note before signing it. You can decline recording, or ask me to stop or delete it at any time, and that will not affect your care.
Notice what that paragraph does not need: a section explaining a vendor’s data-handling policy, a list of subprocessors, or reassurance about a server location. When nothing leaves the device, there is simply less to disclose, and less for the client to take on faith. For a starting point you can tailor, see our AI consent form templates, and for the spoken side of this, how to talk to clients about recording goes deeper on tone and timing.
Why on-device processing makes informed consent for AI documentation simpler
Consent is informed in proportion to how much the client can actually understand and verify. Cloud-based documentation tools ask the client to trust a chain they cannot see: your practice, a vendor, that vendor’s infrastructure, and whatever agreements sit between them. Each link is a place where the honest answer is “I’m relying on their assurances.”
On-device processing collapses that chain. The data is on one machine, the one in the room, under your control. You are not promising that a third party will behave; you are describing a setup the client can picture. A signed business associate agreement with a cloud vendor can satisfy a legal obligation on paper, but a signed agreement is a floor, not the goal. The more useful question is whether the client’s words ever needed to travel at all. On-device tools like CouchNotes are built around that answer: the session stays on your Mac, with no cloud, no account, and no telemetry, so the consent conversation can be about clinical care rather than data logistics.
Documenting the consent itself
Whatever the client decides, write it down. A brief line in the record, consent obtained for AI-assisted documentation, or client declined recording and manual notes were used instead, closes the loop and protects both of you. If a client declines, that has to be a real option with no friction and no penalty, or the consent was never meaningful to begin with.
None of this is about the tool being clever. It is about a clinician being straight with a client about how their words are handled, in language a reasonable person can follow, before anything is recorded. The technology that makes that explanation shortest is the technology worth using, and the conversation, not the software, is what earns the trust.