Most compliance officers I talk to have already worked out their AI transcription policy in their head, even if it's never been written down. The logic goes something like this: patient conversations are PHI, PHI must be retained under HIPAA, therefore the recording stays. It's a reasonable assumption. It's also wrong and getting the answer wrong in either direction creates a problem. It's the same instinct that makes people assume a store keeps its security footage forever just because the store itself isn't going anywhere. The recording and the building live under completely different rules and conflating them is where the trouble starts.
HHS has said directly, in its own published guidance, that the Privacy Rule does not require covered entities to record oral communications, nor to retain those recordings once they've been transcribed. That's a clear statement, and it hands organizations more flexibility than most policies currently use. Some organizations respond by over-retaining anyway, out of caution, and end up holding a growing archive of sensitive audio with no clinical purpose and no retention rationale behind it. That archive is pure breach surface. Others respond by deleting everything automatically, without checking whether the deletion is legally sound, which creates a different kind of exposure. Neither is a policy. Both are guesses.
The real question isn't whether you can delete the audio. It's whether the audio ever became something you weren't allowed to delete in the first place.
Where the flexibility disappears
Consider a health system piloting an ambient AI scribe in outpatient visits. The tool listens to the encounter, generates a draft clinical note, and the physician reviews and finalizes that note in the EHR. The raw audio was an input. Nobody goes back and listens to it. The note is what gets acted on, amended, and relied upon for care decisions. That's a defensible case for deletion.
Now change one fact. A dispute arises about what was said during the visit, and a manager pulls the original recording to review it before deciding how to proceed. Think of the audio the same way you'd think of that security footage. Nobody worries about the tape while the meeting is happening. The trouble starts the moment someone pulls it later to settle an argument about what was said. At that point it stops being background footage and becomes evidence, whether anyone meant it to or not. Legally, the same thing happens to the recording. The moment that audio is used to make a decision about the patient, it starts to look like a designated record set under 45 CFR § 164.501, the set of records an organization actually uses to make decisions. Once that happens, the audio inherits the same obligations as any other medical record: access, amendment, and retention. Deletion is no longer a configuration setting. It's a compliance violation waiting to be discovered.
The distinction sounds narrow, but it's the whole ballgame. A transcription input and a designated record can look identical in a vendor's dashboard and carry entirely different legal obligations depending on how, and whether, a human used the audio to decide something. This is a fact pattern, not a checkbox, and it deserves a documented rationale rather than an assumption.
Deletion is a claim, not an event
Even when deletion is the right call, "deleted" needs to mean something specific. The Security Rule's requirements for disposing of electronic PHI don't care what your dashboard says happened. It cares whether the audio stopped existing, everywhere.
That's where most organizations get exposed. Deleting a file only where you can see it is a bit like shredding your copy of a contract while the other party keeps theirs in a filing cabinet. The document didn't go away. You just lost track of where the copies are. The primary system deletes the file, but a backup snapshot retains it for another ninety days. The vendor's logs keep a cached copy for debugging. The Business Associate Agreement never specified a retention window for the vendor at all, so there's no contractual obligation on the other side even if your own house is in order. None of this shows up until someone asks, and by then it's an audit finding rather than a design decision.
OCR expanded its risk management scrutiny in 2026, and the 2025 enforcement wave, twenty one settlements, the second highest annual total on record, included failures tied specifically to retention and risk analysis controls. That's not a coincidence. Regulators are starting to look past the primary system and ask about backups, caches, and vendor obligations, which is exactly where most AI transcription deployments have never been tested.
If your BAA doesn't specify how long the vendor retains audio, whether that includes backups and logs, and how deletion is verified, you don't have a deletion policy. You have a hope.
HIPAA is a floor, not the whole building
There's a second trap that has nothing to do with AI at all. Many states impose their own medical record retention requirements, ranging from as few as five years to twenty or more, on top of the federal floor, the way a city can post a stricter speed limit than the interstate running through it. HIPAA doesn't override the stricter local rule. It just sets the minimum everyone must clear. Those state requirements can attach to the transcription output even when the underlying audio was correctly and legally deleted. An organization can get the HIPAA analysis exactly right and still be out of compliance with a state floor it never checked. Retention policy must account for both layers, not just the federal one everyone remembers to look at.
What a defensible posture looks like
None of this argues against AI transcription. It argues for treating the audio as its own governed artifact rather than an afterthought to the note it produces. That means documenting, in writing, why the audio is being treated as transient input rather than part of the record, before a regulator asks. It means BAA language built for how ambient scribes actually work, binding the vendor to a specific, verifiable deletion window that covers backups and logs, not just the primary database, and prohibiting use of patient data to train or fine-tune the vendor's models. Signing a BAA without nailing down those specifics is a bit like hiring a moving company and never asking whether they keep a spare key after the job is done. You assume the work is finished. They may still have access. It means automated lifecycle rules with deletion confirmation logs, because a manual policy nobody can point to after the fact isn't a control. And it means a risk analysis that names AI-assisted documentation tools explicitly, rather than assuming they're covered by whatever assessment was done on the EHR five years ago.
The organizations that get this right aren't the ones deleting the most aggressively or retaining the most cautiously. They're the ones who can explain, with a straight face and a paper trail, exactly why they made the choice they made. That's the bar. Everything else is a guess dressed up as a policy.
Sources: