At a couple of doctor's offices recently, I was handed a waiver to sign before my appointment. It was consent for AI: the visit would be recorded through an app on a phone, and software would turn the conversation into notes. I asked the questions anyone should ask. Where does the audio go? Who stores it, and for how long? Nobody at the desk could tell me, so I asked them to find out while I was being seen.
The answer, when it came back, was that the audio leaves the building. The app records the visit, sends the audio to an outside firm for transcription, and the text comes back to the office. Even then, nobody could tell me how it was stored or how long it was kept.
I declined to sign, and I explained which answers were missing. The response surprised me: the doctor, who is a part owner of the practice, asked whether I could build them a transcription tool that runs on their own equipment and is designed to meet HIPAA requirements. That project is in development now, and it is the reason for this post.
The gaps I found
I have spent more than twenty years in quality work, much of it as an auditor, so I look at a process like this the way an auditor would: what does the record show, and who can prove it? Here is what was missing.
- Nobody owned the answer. The staff asking for my signature could not explain what I was signing. Consent that nobody can explain is not much of a consent.
- The audio left the building by default. A recording of a medical visit is about as sensitive as data gets, and it was going to a third party as a matter of routine.
- No retention answer. Nobody could say how long the recording or the transcript is kept, or when either one is deleted.
- The phone is part of the chain. If the app holds audio on the device before uploading it, that phone is now a store of patient recordings too.
- The paperwork question went unasked. Under HIPAA, an outside company that handles patient information for a provider is a business associate, and the provider needs a written agreement with it. I could not get anyone to tell me whether one existed.
None of this proves the vendor is doing anything wrong. It means the office could not show that anyone is doing it right, and from the patient's chair those two look exactly the same.
Where the audio actually goes
The useful way to think about any voice system, medical or not, is as a chain of separate jobs. Each job can run in a different place.
- Wake word or push to talk: something decides when to start listening.
- Speech to text: the audio is turned into written words.
- Understanding: the text is matched to an intent, by simple rules or by a language model.
- Action: something happens, such as a note being saved or a timer starting.
- Speaking back: a text-to-speech engine reads out the reply.
In the doctor's office, the second link was the one sent out. Once audio leaves the machine, the whole chain is only as private as the company on the other end, and the patient has no way to check.
Local speech to text is realistic now
Transcription used to need a data center. It no longer does. OpenAI released its Whisper speech recognition models with open weights, and projects such as faster-whisper and whisper.cpp run them on an ordinary computer. A smaller model answers faster, and a larger one handles accents and background noise better, so it becomes a tuning decision rather than a reason to send audio away.
My own stack, gaps included
Since I am asking an office to account for its data, it is only fair to account for mine. Here is what my assistant, Jarvis, runs on today:
- Listening: a push-to-talk key rather than an always-on wake word.
- Speech to text: faster-whisper, on my laptop's graphics card.
- Understanding: simple requests go to a small model running locally through Ollama. Harder ones send the text of the request, not the audio, to a hosted model.
- Speaking back: Kokoro, a text-to-speech engine that runs locally.
That third line is my gap, and I chose it knowingly. My voice never leaves the laptop, but some text does. For an assistant on my own desk, I accept that trade. For a patient's medical visit I would not, which is why the tool I am building for the office keeps the recording and the transcription on their own hardware.
How to check any voice system
Whether it is your own build or a clinic's app, the same checks apply.
- Pull the network: disconnect from the internet and see what still works. In a hybrid setup like mine, the replies that need a remote model will stop, and that is exactly what the test should show.
- Watch outbound traffic: a tool such as Wireshark, or your firewall log, shows whether the app opens connections and to where.
- Read the settings and the policy: look for telemetry, crash reporting and anything about using recordings to improve the service.
- Ask for it in writing: where the audio goes, who processes it, how long it is kept, and whether it trains anything. If the answers do not exist, that is your answer.
Write down what private means first
Before choosing tools or signing a form, write one plain sentence about what has to stay private. "Audio never leaves the machine" and "nothing leaves the machine" are different projects with different parts lists. The offices I visited had never written that sentence, and it showed.
If you want to build your own assistant, Hey Jarvis: Your Machine. Your AI. Your Rules. walks through the local audio pieces, wake word, transcription and speech, along with the rest of the build.
To write that one sentence for your own situation, start with the free worksheet at https://solved360.com/pages/free. It is built for stating a problem clearly before you buy, install or sign anything.