← Field notes
Privacy

Why your meeting audio should never leave your machine

A specific uncomfortable moment with a competing meeting AI, and the architectural stance I built in response.

Jeff · June 20, 2026

I was two minutes into a call with a prospective investor when I glanced at my laptop's outbound connections. One of the meeting AI tools I was testing had opened a long-lived WebSocket to a domain I did not recognize. I looked it up mid-call. It was a third-party transcription vendor, headquartered somewhere I had never been, with a terms of service I had never read, hired by the tool I had installed to turn my private conversation into text on their servers.

I kept smiling through the rest of the meeting. I closed the laptop afterward and sat with it for a while.

The person on the other end of that call had not consented to any of that. I had not meaningfully consented either, if we are being honest about what a 40-page click-through actually is. Somewhere on a server I could not point to on a map, a company I could not name an executive of had a recording of me pitching, and a transcript of an investor asking me about my runway.

That is the moment IntelliPrompter's architecture got decided.

The default is bad

Most meeting AI tools ship your audio off your machine

The default pattern for meeting AI goes like this. The tool captures your microphone and the system audio of the call. It streams the raw audio, or near-raw audio, to a server. The server runs transcription (often via a third-party API like Deepgram, AssemblyAI, or OpenAI's Whisper API). Another service runs summarization. The output comes back to your app. The audio and transcript live on their infrastructure, under their retention policy, subject to their subpoenas, their breaches, and in some cases their training data pipelines.

I understand why vendors build it this way. Cloud transcription is cheap per-minute, scales linearly, and lets you ship a laptop app, a web app, and a phone app from the same backend. It is the fast path. It is also the path where your renewal negotiation, your performance review of a direct report, your therapy session, and your custody conversation all end up on someone else's hard drive.

I think that trade is wrong. Not just risky, wrong. The audio of a private conversation is one of the most sensitive data classes a person generates. Treating it as a routine payload to a vendor pipeline is a category error.

How ours works

On-device Whisper, in a worker thread

IntelliPrompter runs transcription on your machine. Not in a container we rent, not in a region we picked for latency. Your laptop. We ship Whisper (OpenAI's open-weights speech model) inside the Electron app and run it in a worker thread with voice activity detection so we only transcribe actual speech. The audio buffer lives in RAM for the few seconds it takes to process, then gets dropped. No disk write of the raw audio by default. No network call for the transcription step.

The default model is Whisper base, about 145 MB. It fits in memory on any machine shipped in the last five years. It handles accents better than people assume and runs comfortably on a laptop CPU without touching the GPU. If you want more accuracy, there is a picker for small or medium. If you want more speed on an old machine, tiny. The trade-off is yours to make, not ours.

I will be honest about the cost. On-device is harder to build. Model files take disk space the user has to download. The first meeting after an update is slower while the model warms up. Supporting Windows and Linux is more work than hitting a REST endpoint. And we gave up the easy telemetry story where every transcript flows past our servers and we get to see what's happening at the aggregate. We decided not having that visibility is a feature, not a bug.

Three modes

The control surface users actually see

Transcription is one piece. The other piece is what the coaching engine does with the transcript. Here, honestly, you have to make a trade. The best reasoning models today are cloud models. Running everything through local Llama via Ollama is possible and we support it, but the suggestions you get from a 7B parameter model running on your laptop are not the suggestions you get from Claude or GPT. If you need the quality, you have to send text somewhere.

So we surfaced the trade as three modes. One toggle, three honest options.

Full. Transcription on-device. Coaching calls go to the AI provider whose key you plugged in (your Anthropic key, your OpenAI key, your Gemini key). Fast, high-quality suggestions. The audio never leaves. The transcript text leaves, under your own API agreement with your own provider. We are not in the middle.

Ephemeral. Same as Full, but with no transcript or coaching event persisted to the local SQLite database after the meeting ends. The meeting happens, you get the help in the moment, and the record vanishes. For the conversation you would rather not have on your hard drive next week.

Self-only. We only transcribe your own microphone. The other side of the call is not captured, not stored, not analyzed. For jurisdictions with all-party consent laws, for calls where you have not asked the other person, for calls where you want the coaching on your side without ever representing their words. This is the mode I use with my therapist.

None of the three sends your audio to our servers. None of the three sends your audio to a vendor we picked. The audio is gone before any of this starts. The three modes are about what happens to the text after transcription, and about what we keep.

The moral part

Why I think this matters more than the feature table

The usual way to argue about privacy is to list the regulations you comply with and the certifications you have in flight. We will do that too (SOC 2 work is underway) because buyers reasonably ask. But the regulations are a floor, and the floor is low. The Otter class action turned on exactly the thing I described in the opening paragraph: a meeting AI vendor repurposing audio and transcripts in ways users did not expect and the other party on the call could not have consented to. Compliance did not prevent it. Architecture would have.

The people on the other end of your calls are not your customers. They did not download our app. They did not read our terms. They walked into a conversation with you, and if their words end up transcribed, summarized, and stored on a vendor server somewhere, that is a decision you made for them. The least we can do is make sure the raw audio of their voice is never a thing we hold.

We built the product so we could not be the company that leaked your renewal negotiation, because we never built the path. That is not a marketing claim. It is a shape of the codebase. Open the repo and look for the server that receives audio. It does not exist.

Where to go next

If you want the details

The full write-up of the three privacy modes, including what each one does and does not store, is at intelliprompter.com/docs/privacy-modes. If you want to read the broader set of commitments the coaching engine operates under, those are on the AI ethics page.

If you want to try the product, the beta is at intelliprompter.com/download. Install it, open Activity Monitor, and watch what it does and does not do on the network during a call. I think that is the fairest test.

Jeff

More field notes are on the way. Feature by feature. Pain and gain.

Join the beta waitlist