Meeting notes when your company blocks AI notetakers: take them locally on your Mac, with no bot in the participant list and no audio leaving the device. That's the whole pitch in one sentence, and it's the shape of the rest of this guide. If you've worked anywhere serious in the last few years, you've seen the email. "Effective immediately, all AI meeting assistants (Otter, Fireflies, Read, and similar) are prohibited on company calls." The reasoning is consistent across security teams: a third-party bot joins the call as a visible participant, captures audio, ships it to a vendor, and stores transcripts in an account nobody on your team controls. IT has legitimate concerns, and the bans aren't irrational. The problem is the second-order effect. People still need notes. They revert to typing, they lose nuance, they skip meetings they should attend, or they use a tool IT doesn't know about - which is usually a worse compliance outcome than the ban itself. There's a third path: a tool that transcribes locally, never appears as a participant, and asks nothing of your calendar or contacts. This article walks through what that looks like in practice, using on-device Whisper as the worked example, and the specific questions an IT security review will put to you.

Why companies block AI notetakers in the first place

It's worth naming the actual concerns, because most of them are reasonable and most of them are addressable with the right architecture. The common pattern looks like this. A vendor's bot joins a Zoom or Teams call as a visible participant. It records the audio, sends it to the vendor's cloud, runs a transcription model there, stores the result in the vendor's database, and exposes it through a web app the employee logged into with their work email. The vendor has a BAA or doesn't, has SOC 2 or doesn't, has a DPA or doesn't - all of which become procurement problems before the first transcript is even generated. Worse, the recording happens regardless of whether attendees consented, which exposes the company to wiretapping and confidentiality concerns around conversations involving third parties on the call. That's why IT bans the category. The fix isn't to argue the policy; the fix is to switch the architecture so the listed concerns stop applying.

Pro tip: When IT pushes back, mirror their own categories. "Where does audio go?" "Who has access?" "Does anything join the call?" Most security questionnaires are lists of these same questions with different formatting. If you can answer them with one sentence each, you've done most of the work.

What a security review of a meeting-notes tool actually asks

Security reviews aren't really about the tool. They're about whether the tool introduces new flows of data the company can't account for. Here are the six questions that come up in nearly every review I've watched or read about, with the kind of answer an on-device transcription app can give.

Question IT asks	What they're actually worried about	On-device answer
Does audio leave the device?	Vendor or subprocessor exposure	No - the model runs locally
Is there an account?	Data subject to a third-party ToS	No account in local mode
Is anything phoning home?	Background telemetry, analytics, crash reports	No telemetry, no analytics
Where does the model live?	Model weights shipped from where, and how	Downloaded once, on-device, ~950 MB
Where do API keys sit?	Key leakage, plaintext storage	macOS Keychain (encrypted at rest)
Does anything join the meeting?	Bot in the participant list, calendar access	No - the app hears through your Mac's mic

The rest of the article maps to these six rows. If you can show a security reviewer that each one is satisfied by the runtime behavior of the tool, the conversation usually moves to operational concerns (managed devices, MDM, notarization) rather than to architecture.

Does audio leave the device?

This is the single question that decides the conversation. If audio stays on the Mac, most of the downstream questions become much easier, because there is no third-party data processor in the loop. MetaWhisp's local mode uses WhisperKit to run Whisper large-v3-turbo on the Apple Neural Engine. The audio is captured from your Mac's microphone through standard macOS audio APIs. It goes straight to the on-device model. The transcript is written to the system clipboard or auto-pasted into the active app. Nothing in that loop requires a network connection. You can verify it the same way IT will: open Activity Monitor or Little Snitch while dictating, watch for outbound connections from the app, and notice that the network tab stays empty. The app behaves identically with Wi-Fi turned off.

Is there an account, and does anything phone home?

Local mode has no account. You download the app, you grant microphone permission, you dictate. No email, no signup, no license server to call home to. There's no analytics SDK and no crash reporter shipping data anywhere, because the app doesn't include one. This is unusual in 2026. Most Mac apps you've installed in the last five years have at least one of: an account wall, an analytics endpoint, an update beacon, a "send anonymous usage data" toggle that defaults to on. Local mode has none of those. The trade-off is real: there's no cloud sync, no cross-device history, no team dashboard. If you need those, that's what a different tool is for, and IT will need to evaluate it on its own terms. A common follow-up question: what about macOS itself? The OS will log microphone permission events and may surface that in audit reports, but that's the operating system doing its job, not the app. It's the same log your Mac already writes for any app you grant mic access to.

Where does the speech model live, and where do API keys sit?

The speech model is downloaded once, the first time you dictate in local mode - about 950 MB of weights for Whisper large-v3-turbo. After that it lives on disk in the app's sandboxed container, the same place every Mac app stores its data. It does not stream from a server per utterance; it does not phone home to check for model updates; it runs entirely from local storage. API keys are a separate question. If you choose to use MetaWhisp's AI post-processing modes - Structured, Correct, Rewrite, or any of the others covered on the processing modes page - on your own OpenAI or Cerebras account, you paste the key once into the app and it goes into the macOS Keychain. Keychain items are encrypted at rest, scoped to your user account, and require your login password (or Touch ID) to read. The key never appears in plaintext config files, never gets written to disk in a way a backup tool would index, and never leaves your Mac unless you explicitly export it. The thing IT will want to understand, and the thing you should be honest about: when you enable any text-polish mode, the transcript text (not the audio) is sent to your chosen provider under your account and your contract. MetaWhisp itself does not see it. But it's a real data flow that needs to be on the diagram.

Does anything join the meeting as a participant?

No. MetaWhisp is not a meeting integration. It doesn't ask for your calendar. It doesn't connect to Zoom, Meet, or Teams. It doesn't appear in the participant list. It doesn't post a "Hello, I'm OtterBot" announcement. What it does is listen to your Mac's audio input. The natural way to use it for a meeting is to put your meeting on speaker (or route it through a virtual audio device) and run the local capture on your machine, which produces a transcript of everything the meeting said. There's no server-side processing. There's no recording uploaded anywhere. The transcript lives where you decide: clipboard, Notes app, your favorite text editor, or pasted into a CRM. This is the second-biggest IT objection after "where does audio go," and it's answered cleanly: the app does not integrate with the meeting platform at all. It is a microphone listener and a text writer. The meeting platform never knows it exists, and the app never talks to the meeting software. For a more thorough walk-through of this no-bot workflow, the meeting transcription without a bot guide covers system-audio routing in detail, and the offline AI meeting secretary workflow shows the post-meeting side of the same setup.

What the free local tier covers, and what triggers a second IT review

There's a clean line between two modes, and IT will want it drawn. Free local mode does unlimited on-device transcription. No account, no time caps, no API key required. The model is the local-tier model. The accuracy is the local-model accuracy - in our own benchmark run on LibriSpeech test-clean, MetaWhisp measured 2.76% WER (about 97% accuracy) on Whisper large-v3-turbo. The BYOK features (your own OpenAI or Cerebras key for text polish or translation) work on the free tier; they just require you to provide the key. MetaWhisp Pro is the line that requires a second look. Pro removes the bring-your-own-key requirement (the cloud AI is built in), and it adds cloud-based transcription powered by Whisper large-v3-turbo with a daily cap. Pro cloud mode does send audio to MetaWhisp's servers for transcription. That is a different architecture and a different conversation with IT. If you don't need Pro features, don't enable Pro features; the local mode is enough for most individual users.

Pro tip: The cleanest way to keep IT happy is to deploy local-only and never give anyone a Pro seat. If somebody eventually wants cloud polish, you do a second review on the Pro path specifically, with the relevant data flows on the diagram. Don't try to make one review cover both.

How to pitch an on-device transcription app to your security team

The fastest path is to give IT exactly the answers they would have asked the vendor. In my experience, the conversation goes like this. First, the architecture diagram. One Mac, one model file on disk, one microphone. Audio in, transcript out, no network hop. A single PNG is worth an hour of words. Second, the runtime proof. Offer to demo on a corporate Mac with Little Snitch running. Dictate a sentence. Show that no connection leaves the device. This is the moment security teams relax, because they're used to vendors talking about "we don't sell your data" while their app quietly pings five analytics endpoints. An app that can't phone home because it has nothing to phone home to is rare enough that it's persuasive on its own. Third, the data flow document. Spell out which features send what where. Local transcription: nothing leaves. Text polish with your own OpenAI key: transcript text goes to OpenAI under your contract. Pro cloud mode: audio and transcript go to MetaWhisp's servers. The reviewer gets a one-page table instead of digging through privacy policies. Fourth, the operational story. Where does the binary come from? Is it notarized for macOS Gatekeeper? What's the update channel? Is there a managed-install path? These are not architecture objections, they're IT operations objections, and they have well-understood answers. A useful framing for the meeting: "I'm not asking you to approve a vendor relationship. I'm asking you to approve installing one signed binary on my laptop that does its work locally. There is no data processing agreement because there is no data processing."

The honest caveat: local does not mean pre-approved

Here's where I'd push back on the easy version of this pitch, because I think it does a disservice to the people reading it. A local architecture answers the data questions. It does not answer the install question. On a managed corporate Mac, you still have to get the app onto the device, which usually means IT has to deploy or approve the .app bundle. There may be an MDM policy that restricts which apps can run, a Gatekeeper setting that requires notarization, a baseline configuration profile that blocks microphone access for non-approved apps. None of those are problems the app solves on your behalf. In practice, this means even MetaWhisp - a notarized, code-signed, free Mac app with no account and no network behavior - goes through some version of the same approval process as any other tool. Local is the right architecture; local is not a free pass. If your company has a software-request portal, use it. If your company has an exception process for "approved personal productivity apps," use that. The conversation is shorter, but it still happens. The other thing worth saying out loud: I am the founder of MetaWhisp, and I'm telling you this because I'd rather you go into the IT conversation prepared. We don't have SOC 2, we don't have an enterprise sales motion, we don't ship MDM controls, and we don't pretend otherwise. What we have is a free local mode that doesn't phone home and a Pro cloud mode that does - and both are priced and described honestly on the pricing page. For workflows that need HIPAA-style guarantees, local mode fits a HIPAA-style workflow in the sense that no audio leaves the device, but the HIPAA compliance itself belongs to the practice, not to us. Bring the questions; we'll answer them.

About the author

Andrew Dyuzhov is the CEO and solo founder of MetaWhisp, a free on-device voice-to-text app for macOS. He's a marketer and builder with ADHD who assembled MetaWhisp with AI coding tools on top of open-source Whisper. He dictates daily in Russian and English and uses voice-first workflows to get past writing paralysis. He's not a security researcher and won't pretend to be - the goal of this article is to put the architecture questions on the table and answer them honestly, the way he wishes someone had done for him when he was the one trying to get tools approved at a previous job.

Related reading

• Private voice to text on Mac: free, no cloud, no account
• Meeting transcription without a bot joining the call
• An offline AI meeting secretary workflow on Mac
• Processing modes: how local post-processing keeps text off the cloud

Download MetaWhisp free →