HIPAA Compliant AI Scribe: What It Takes to Build One That Is Safe to Ship

A HIPAA compliant AI scribe is one where every guarantee a clinician, a patient or an auditor depends on is enforced in code around the model, not requested in a prompt. That means consent captured before any audio exists, drafts that a licensed clinician must approve, suggested diagnosis codes checked against a real code catalog, access limited to the people treating the client, audit logs that record what happened without storing health information, and recordings deleted on a schedule. A business associate agreement with the model vendor is necessary. It is also the smallest part of the work.

That is a point of view, and it comes from building one. We designed and built an AI documentation assistant inside a behavioral health EHR that we also engineer day to day: it drafts progress notes, initial assessments and treatment plans from session recordings or typed input, and it answers portal questions for clients. Every guarantee in this guide is enforced in that system and covered by an automated test. The lessons section near the end is the part we could not have written from the outside.

For the engineering of the capture and structuring pipeline itself, see our deep dive on ambient clinical documentation engineering. This guide is for product and engineering leaders deciding whether to build an AI scribe into their own platform, and for the compliance and clinical leads who have to sign off on it.

Why "HIPAA compliant" is the question buyers ask, and the wrong place to stop

Buyers ask whether an AI scribe is HIPAA compliant because it is the question they know how to ask. It is a real requirement. It is not the one that sinks these projects.

HIPAA governs how protected health information is stored, transmitted, accessed and disclosed. An AI scribe can satisfy every one of those rules and still write a progress note that invents a symptom, suggest a diagnosis code that does not exist, record a session in a state that requires everyone's consent, or tell a distressed client something only a clinician should say. None of those is a HIPAA violation. All of them end a pilot.

The useful question is broader: what does this system guarantee, and how do we know? The rest of this guide answers it in the order the risks occur, from booking to deletion. The cost of getting it wrong is rarely a fine. It is a clinician signing a note with a symptom the client never described, a supervisor who stops trusting every draft after one bad one, and a sales cycle that stalls on a compliance officer's questions. None of that is fixed by a better model.

The business case for building an AI scribe into your product

The evidence that scribes give clinicians time back is now real, and more modest than the marketing. A JAMA study across five academic health systems, covering 8,581 clinicians, found about 16 fewer minutes of documentation per eight hours of scheduled patient time, as reported by STAT, and only about a third of adopters used the tool in most of their visits. A separate 30-day study of 263 clinicians saw burnout fall from 51.9% to 38.8%, as reported by the AMA.

For an EHR or practice management vendor, that makes an AI scribe three things at once: a retention feature, because clinicians who get their evenings back rarely switch systems; a differentiator where the rest of the feature list looks the same; and a margin question, because every standalone scribe your customers buy on the side is revenue sitting in a tab next to your product.

Buyers now expect this inside the product rather than beside it. Epic made its own AI charting generally available in February 2026, as reported by Healthcare Dive, and the Peterson Health Technology Institute described scribe adoption as on track to be one of the fastest in recent healthcare history. The same studies carry the warning: the time saved depends on clinicians trusting drafts that write into the legal record, and that trust is built by the controls below.

The principle: the code around the model is the product

Every AI scribe has a model, a prompt and a screen. The ones that survive review share one design decision: anything that must always be true is enforced outside the model.

A prompt can ask a model not to invent a diagnosis code. Code can check each suggested code against the ICD-10 catalog and drop the ones that are not there. A prompt can ask a model to respond carefully to a client in crisis. Code can detect crisis language and return a fixed, clinically approved message that the model never generates at all. The first kind of safety works most of the time. The second works every time, and it can be tested.

That table is the whole design philosophy. The rest is how each row is built. For the wider pattern this belongs to, see our piece on bounded autonomy in healthcare AI.

Before a word is recorded: consent

The first guarantee applies before the model is involved at all. Audio of a therapy session is about as sensitive as health data gets, and in several states recording a conversation requires the consent of everyone in it. The Reporters Committee for Freedom of the Press lists California, Delaware, Florida, Illinois, Maryland, Massachusetts, Montana, New Hampshire, Pennsylvania and Washington among the all-party consent states, with partial rules in several more. Illinois went further for therapy specifically: since August 2025, a provider must disclose in writing and obtain explicit, revocable, written consent before AI records or transcribes a clinical session, with penalties of up to $10,000 per violation, as summarized by Baker Botts.

We record consent per participant, per session, before any audio can be captured. The rule in code is simple: no consent row on file means recording is not permitted, and the recording controls do not start. Capturing a participant's attestation writes a consent record tied to that session and that organization. A clinician from another organization cannot capture consent for a session that is not theirs, because consent is scoped to the booking's organization, not to whoever is logged in.

Two details matter more than they look. Consent is per participant, because family sessions, couples work and supervised sessions have more than two people in them. And consent is checked at the moment recording starts, not when the appointment was booked, because people withdraw it.

While audio becomes text: bounded transcription

Transcription is usually an asynchronous call to a vendor. The failure mode that bites here is not a wrong transcript. It is an open-ended wait: a job that is never marked finished, a clinician who sees "processing" forever, and a note that quietly never gets written.

We run transcription as a polled job with three rules. It reschedules itself while the vendor reports work in progress. It stops rescheduling the moment it reaches a terminal outcome, success or failure. And polling is bounded by a maximum number of attempts, so a job that never resolves ends in a known failed state rather than an infinite loop. Processing is restricted to the owning clinician and the care team; anyone else is refused even if they can see the appointment.

Transcription models also invent text. Researchers studying a widely used speech model found roughly 1% of transcriptions contained entire hallucinated phrases or sentences, and 38% of those hallucinations included explicit harms. A randomized trial at UCLA found that AI-drafted notes occasionally contained clinically significant inaccuracies. That is why the transcript is treated as source material the clinician can check, not as a fact the note can rely on unexamined.

When the model writes: grounded drafts, never decisions

This is where most AI scribe demos stop, and where most of the clinical risk lives. Four rules govern generation.

Everything is a draft

The model's output is stored as a draft attached to the note, never written into the signed record. Only a clinician's explicit action promotes it, and any edits are recorded, so the record shows what the model wrote and what the clinician changed. Over time, that edit rate becomes the most honest quality metric you have.

Only the source material

The model is instructed to use only the transcript and the context provided for that session, and to omit or flag anything it cannot support rather than fill the gap. It must not invent history, symptoms, dates, names, medications or events.

Risk is surfaced, not judged

Behavioral health notes regularly touch self-harm, danger to others, abuse and mandated reporting. The system does not decide any of these. When risk language appears in a session, the draft lists it as items for the clinician to review. It does not conclude that risk is present or absent, and it does not make medical necessity, legal, custody or reporting determinations. The clinician decides; the system makes sure they see it.

Diagnosis codes are checked, not trusted

The model may suggest ICD-10 codes, clearly labeled as suggestions with a reason. Each suggestion is then validated against the code catalog. A code that is not in the catalog is dropped before the clinician ever sees it, and even if one reached the screen, the system refuses to accept a non-catalog code into the record. Accept, reject and edit each set the final code differently, and each is a separate tested path.

When the clinician decides: the note lifecycle

The draft only matters if the rules around the signed note are strict. We enforce three.

• A signed note is locked to the AI. Once a progress note is signed and locked, generating a new draft for it is refused, and so is accepting an existing one. A late AI suggestion must never be able to rewrite a signed legal record.
• Participants are verified before acceptance. A draft cannot be accepted into the note until the session's participants have been verified. A transcript that attributes a statement to the wrong person is a clinical error; this closes the window where it could slip into the record unchecked.
• Discard is a first-class action. A clinician can discard a draft outright, and it is marked discarded rather than silently deleted, so the audit trail shows the AI produced something that was not used.

Supervised practice follows the same rule: only the assigned supervisor can write a supervision note, finalizing it locks it, and any AI draft linked to it is finalized at the same moment, so no orphaned draft sits beside a closed record.

Governing the prompts

A prompt is code that changes behavior in production, and in most AI products it is edited in a text box with no history. That is the weakest point in the whole system. Prompt governance treats prompts like the production artifacts they are: platform templates owned by the vendor with clinic overrides scoped to one clinic, append-only publish and rollback, an audit event per change that stores a fingerprint of the prompt rather than its text, preview restricted to administrators, and a guardrail preamble pinned in code and prepended to every call so that no template edit can remove the rules that make the system safe.

Every generation also records the prompt version it used, so "which instructions produced this note" becomes a lookup rather than a guess. We cover the data model, permissions and change-control workflow in part two: prompt governance for clinical AI.

Who can see a session

Role-based access is table stakes. The detail that trips teams up is that "same organization" is not the same as "allowed". A therapist in a group practice should not be able to open another therapist's session recording just because they work at the same clinic.

Each row is a test. The two "no" rows are the ones worth writing first, because they are the ones a quick implementation gets wrong. This is the minimum necessary principle applied to a recording rather than a record. HIPAA's minimum necessary standard does not restrict a provider's own use for treatment, but it does bind everything else, including your product's operational access. Large vendors know this: Microsoft's privacy documentation for its clinical scribe leaves it to the customer to limit access to clinicians with an established therapeutic relationship. If you build the scribe into your product, that rule is yours to enforce.

What you keep, and for how long

An AI scribe creates three kinds of data that did not exist before: audio, transcripts and drafts. Each is more sensitive than the note it produces, and none of it is needed once the note is signed.

Deleting audio immediately sounds like the safest choice, and it has a cost. When reporters found a widely used scribe had deleted its original recordings, one researcher put it plainly, as reported by Fortune: you cannot catch errors if you take away the ground truth. A retention window set by each clinic resolves the tension: long enough to review a disputed note, short enough that recordings do not pile up.

We run a retention sweep on each clinic's schedule. It purges audio, transcripts and drafts older than the clinic's retention period and keeps the usage and audit records, so the practice can still prove what happened without holding onto what was said. Two edge rules are tested explicitly: a clinic with no retention period set keeps everything, which is the safe default for a record the law may require, and anything newer than the cutoff is always retained.

What you log, and what you must not

Every generation writes a usage record: which feature, which model and vendor, which prompt version, input and output token counts, duration, and whether it succeeded. That is enough to answer cost questions, spot a regression after a prompt change, and show an auditor exactly which prompt version produced a given draft. HIPAA's technical safeguards require audit controls that record and examine activity in systems holding electronic PHI, and required documentation must be kept for six years, which is why these records outlive the content they describe.

It deliberately holds no prompt text, no transcript and no generated output. The schema has no field where any of those could go, so it cannot leak them by accident. A usage log that contains PHI is a second medical record nobody is governing.

Two failure paths deserve their own tests. When the vendor call fails, the system writes a failed usage record and produces no draft, rather than a blank or partial note a clinician might sign without noticing. And error messages are a leak path people forget: some vendors echo part of the input back in an error, so an error field needs the same care as content. For more on this, see how AI audit trails make HIPAA compliance easier.

The client-facing assistant

If your AI also talks to clients through a portal, the rules tighten. A client is not a clinician, may be distressed, and may ask things only a clinician should answer.

• Portal help only. It answers questions about the client's own paperwork, appointments, telehealth access and consents, grounded only in facts about that client. It does not give therapy, diagnosis, medication advice, legal advice or billing and coverage determinations.
• Out-of-scope questions are refused with a pointer back to the clinic, rather than answered cautiously.
• Crisis language returns a fixed, approved text. It names the 988 Suicide and Crisis Lifeline and emergency services. The model never writes it and cannot alter it.
• It never reveals clinical notes, supervision records, billing operations or anyone else's information.
• It is blocked for non-patient accounts, so staff cannot use it as a side door into client data.

What building one taught us

The design above reads as tidy. Getting there did not feel tidy, and most of what we learned was not about the model at all. These are the lessons we would pass to any team starting now.

1. The prompt is the part that changes most, so it needs the most control

The model version changes a few times a year. The prompt changes every time a clinician says a note reads wrong. That makes the prompt the most frequently deployed code in the system and, by default, the least governed. Treating it as a versioned, audited artifact with rollback felt like overhead at the start. It turned out to be the only way to answer "which instructions produced this note" a month later.

2. Any rule you cannot test will eventually be edited away

If a safety rule lives only in template text, the next well-meant edit can remove it and nothing fails. That is why the core rules sit in a preamble pinned in code with its own tests. Our working test for any guarantee: if deleting it would not turn a test red, it is a hope, not a guarantee.

3. A new permission is a rollout, not a checkbox

In the same EHR, a new clinician-facing capability shipped behind a new permission. The code was correct. Clinics that had built their own roles never received the grant, so clinicians could not see the feature and reported it as broken. The fix was not in the feature; it was a migration that granted the permission to the roles already doing that work. An AI scribe adds several new permissions at once, and every one needs a plan for existing customers, not just new ones.

4. Clinics use fields differently from how the schema intends

We learned this on the billing side first. Practices retired a lapsed insurance policy by switching it off rather than editing its end date, and many coverage records carried placeholder end dates decades in the future. Any rule that trusted those dates made the wrong call. The lesson carries straight into AI: ground the model only in fields that clinicians actually keep current, and treat the rest as hints, never facts.

5. Transcription is least reliable exactly where it matters most

Speaker attribution is the weak point of transcription, and in a family or couples session it decides who said what in a legal record. We stopped the system from ever using speaker labels to decide what goes in the chart, and we made participant verification a condition of accepting a draft. Accuracy figures quoted for clean one-to-one audio say little about a room of four.

6. Error paths are where PHI leaks

Teams design the success path carefully and log the failure path freely. Vendor error messages can echo fragments of the input, and a stack trace can carry a transcript into a log aggregator that was never meant to hold health information. We treat error text with the same care as content, and a failed call produces a visible failure row, never a blank draft.

7. Reproduce before you fix, and test against realistic data

Our rule for every defect is a test that fails first for the reported reason, then the fix. Fast in-memory tests prove the logic but hide what the real database does with queries, time zones and old data, so each change is also exercised against a production-shaped database before it ships. Most of the surprises we have caught came from the data, not the code.

The regulations that actually apply

HIPAA is the start of the list, not the end of it. These are the rules an AI scribe in a US clinical product has to account for.

The practical reading: a documentation assistant that drafts, suggests and flags for a clinician to decide sits far from the regulatory lines that attach to software making clinical decisions. Every design choice above keeps it there. For the wider 2026 security picture, see our HIPAA Security Rule checklist.

Build, buy or integrate

For a software vendor, the real decision is rarely "should we have an AI scribe". It is which of three routes gets you one your customers will trust.

Scribe vendors now sell this route directly through public APIs and embeddable components, and one advertises that partners can integrate in 2 to 4 weeks. That timeline covers capture and drafting. AI scribe integration through a vendor's API gets you a working model quickly, but the vendor cannot enforce your consent rules, your access model or your note lifecycle, because those live in your product. The guarantees in this guide are yours to build whichever route you choose. That is also why the build route is less work than it looks: the model is the part you can buy.

For a look at why the gap between a working demo and a deployed system is so wide, see what it takes to move an AI clinical scribe into production, and for a worked example of structured extraction at scale, capturing 320 clinical fields from a conversation. If you are comparing products rather than building, our AI medical scribe comparison covers the market.

How to evaluate an AI scribe, yours or a vendor's

These are the questions that separate a demo from something you can put in front of a compliance officer. Each should have a yes backed by a test, not a policy document.

1. Is recording refused when there is no consent on file for every participant?
2. Does a transcription job that never resolves end in a known failed state?
3. Is every output a draft that only a clinician can promote, with edits recorded?
4. Is a diagnosis code that is not in the catalog dropped, and can it ever be accepted?
5. Does the system surface risk language without concluding anything about it?
6. Is generation refused once a note is signed and locked?
7. Can a template edit remove the core safety rules?
8. Can another clinician at the same clinic open a session they are not treating?
9. Are audio, transcripts and drafts deleted on schedule while the audit record survives?
10. Can the usage or error logs contain any part of a prompt, transcript or note?
11. Does crisis language get a fixed approved response, or a generated one?
12. Does a vendor failure produce a visible failure, or an empty note?

If an answer is "the model is instructed to", treat it as a no.