Can You Use an AI Notetaker at Work? Matching the Tool to Your Company's Data Policy

MimicScribe offers an AI notetaker that runs audio processing locally on a Mac, allowing users to choose which cloud provider handles text features, aligning with company data policies that restrict unvetted third-party access. The tool avoids common objections by keeping audio on-device and letting users select approved AI providers for transcription and summarization.

All posts /blog Can You Use an AI Notetaker at Work? Matching the Tool to Your Company's Data Policy You want better meeting notes. Your company has a policy about where its data is allowed to go. Those two things are usually in tension — and the tension isn’t really about you. It’s about the tool. Most AI notetakers work in a way that a careful data policy is right to block. The practical fix isn’t to go without AI. It’s to choose where the AI runs. MimicScribe keeps the audio on your Mac and lets you point the text features at whatever provider your company has already approved — your own Google key, an OpenAI-compatible provider, or a model on your own machine. You don’t have to get a new vendor through security review. This post is how each option works, what still touches the cloud, and how to verify where your transcripts actually go. None of it asks you to take it on trust. You choose who handles the text — ideally a provider your company already controls — and you can watch the traffic to confirm it goes there and nowhere else. What your company’s policy is actually objecting to The objection is almost never “notes are bad.” It’s that a vendor your company never vetted ends up holding the meeting. The common AI-notetaker design — a cloud service that connects to your calendar and sends a bot into each call — triggers that objection three ways: A third party becomes a participant. The bot is visible to everyone, and the recording lives with the vendor, not your company. Your audio leaves the building. The raw recording — a voiceprint of everyone on the call, not just you — is uploaded and stored on someone else’s infrastructure. Retention and training are the default. Many services keep transcripts indefinitely and reserve the right to use customer data to improve their models. Opting out is often an enterprise-only setting. The operative word is unvetted . A provider your company has already approved isn’t a new risk to evaluate — it’s the one your security team already cleared. That distinction is the whole basis for the setup below. The audio never leaves your Mac MimicScribe captures audio at the operating-system level using Core Audio process taps. No bot joins the call. Transcription and speaker separation run on-device, and the audio file is never uploaded, streamed, or copied to a server. Audio is worth keeping off a vendor’s servers for reasons the transcript doesn’t share: it’s a voiceprint of everyone who spoke, it captures people who never agreed to a transcription service, and it’s the one copy you can’t un-record. Most bot-based notetakers store that file indefinitely. Here, it exists nowhere but your Mac — on a company-managed machine, that’s inside the perimeter your IT team already controls. What keeping the audio local does not do on its own is protect the content. The words — the numbers, names, and decisions — are just as exposed in the transcript as in the recording, and the transcript is what the AI features work on. Where that goes is the real question for your company’s policy. The good news is that it’s your choice. On-device also doesn’t cost you quality. Transcription uses NVIDIA’s Parakeet model, and speaker separation is measured at 97.9% aggregate speaker attribution accuracy across a public 52-file benchmark https://github.com/MimicScribe/benchmarks/blob/main/diarization/results/RESULTS.md — corpus and scoring method public. The text AI is the part in question — and you pick the provider The text features — summaries, action items, the live meeting assistant, dictation cleanup — need a large language model to run. MimicScribe doesn’t lock you to one. You choose which provider handles them, per feature, in Settings → AI . Out of the box, those features use Google Gemini through an open-source, stateless proxy https://github.com/mimicscribe/mimicscribe-proxy — no account, no database, no stored copy, with a one-way hardware hash for rate limiting. That zero-config default is built for evaluating the app and for meetings where the stakes are low. It’s a real privacy posture, but it routes through our infrastructure, which is exactly what a company setup will want to change. So change it. Use the AI provider your company already trusts The practical secure setup is to route the text AI to a provider your company has already cleared, using a key on your company’s own account. Then the only vendor holding your transcript text is one that’s already through your security review — and we’re not in the path at all. Two ways to do it, depending on what your company has standardized on: A Google key — ideally one your company issues you. If your company uses Google, enter a Gemini API key in Settings → AI ; transcript text then goes directly to Google under that key, bypassing our proxy. It can be your own key, but the stronger move is to ask your IT or security team for one on the company’s Google account. Then the usage runs under the company’s existing Google relationship — company-owned, billed, auditable, revocable by them, and covered by the terms they’ve already agreed to https://ai.google.dev/gemini-api/terms . A personal key works, but it routes company data through your personal Google project, which many security teams treat as exactly the shadow IT they’re trying to prevent. Enterprise data-residency and retention controls live on Google’s side under the company’s agreement; your security team knows what theirs covers. Your own OpenAI-compatible provider. If your company has standardized on something else, point MimicScribe at it. Anything that speaks the OpenAI chat-completions API works — OpenAI itself, OpenRouter, or an internal OpenAI-compatible gateway the common way companies put Azure OpenAI or a self-hosted model behind one endpoint . Set the base URL and a company-account key under Settings → AI → Custom endpoint and route the features you want to it. Transcript text goes to that provider instead of Google. Setup: custom endpoint guide https://mimicscribe.app/docs/custom-endpoint . In both cases MimicScribe is the capture-and-routing layer, not the AI vendor. Your company doesn’t have to trust us with the transcript — it only has to trust the provider it already trusts. And you can prove the routing: Settings → Network Log shows each AI request going to your provider’s address, not ours. The realistic shape of this for most people: you will use a cloud AI provider, and the point is that it can be the one your company’s policy already allows. That’s the core of it. Every text feature follows your routing — including reference-document search, vocabulary hints, and OCR. With your own Google key, nothing goes through our proxy; it all runs under your key. With a non-Google provider or a local model, nothing reaches Google or our proxy at all. If no cloud provider is allowed: on-device or offline Most companies that permit AI at all have an approved provider, so the setup above covers them. If yours allows none, two fallbacks keep MimicScribe useful: Run the model on your Mac. Point the text features at a local model — Ollama, LM Studio, or llama.cpp — and the transcript text never leaves the machine. Summaries, action items, and the live assistant all still run. The honest tradeoffs are quality and speed: you get whatever model your hardware can run, and a local model is slower than the cloud. A summary that comes back in seconds from Gemini can take much longer locally — the bigger the model, the slower — and while it runs it’s using your GPU and memory, so the Mac is working hard and less responsive until it finishes. The live assistant feels this most, since it’s trying to keep up with the conversation in real time; on modest hardware, expect it to lag. Pick the largest model your Mac runs comfortably — the on-device AI guide https://mimicscribe.app/docs/on-device-ai walks through it. Offline Mode. Turns cloud AI off for a meeting entirely. Transcription and speaker separation still run, nothing is transmitted, and you backfill a summary later if you want one. It’s the simplest “nothing leaves, period” switch. Either way the meeting stays yours and stays usable — your transcripts and summaries are stored locally, and your own tools can read them through MimicScribe’s local MCP server. These are the fallback, though, not the headline. For most people the answer is a cloud provider; the win is that it’s one your company already approved. Match the setup to your company’s line | Your company’s line | Setup | Who holds the transcript text | |---|---|---| | “Use a provider we’ve already approved” | Your own Google key, or an OpenAI-compatible endpoint | Your approved provider, on your company’s account — not us | | “We just want to try it” | Built-in Gemini proxy default | Google, via our no-retention open-source proxy | | “No cloud for this meeting” | Local model | Nobody — the text AI runs on your Mac | | “No AI at all” | Offline Mode | Nobody — transcription only, nothing transmitted | The audio never leaves your Mac in any of these rows. The choice is only ever about where the text goes. The consent question — don’t skip it Choosing a trusted provider doesn’t remove your obligation to tell people you’re taking notes. If anything, it raises it: because no bot joins the call, the other participants get no automatic indication that a notetaker is running. The disclosure is on you, not the tool. Many company policies — and the recording laws in some places — require notifying participants before you record or transcribe a conversation. None of the routing choices above change that. Tell people on the call. How to verify it yourself The principle is verify, don’t trust : a privacy claim is only worth what you can check. Settings → Network Log shows every request the app makes, live: its purpose, destination, status, and timing. It records metadata only — never request bodies or credentials — and clears when you quit. Each AI request lists the endpoint it went to: your own provider’s address with a key configured, 127.0.0.1 with a local model, and nothing at all in Offline Mode. To confirm from outside the app, where the app can’t influence what you see, nettop -x -p <pid shows live connections per process and a firewall like Little Snitch shows the same traffic at the system level. What to send your security team If your company wants to vet this before you use it, the useful thing about the architecture is that there’s less to vet — and what there is, is inspectable rather than asserted. Hand them this: No new vendor relationship to approve. With your own key or endpoint, the transcript text goes to a provider your company already cleared. There’s no data-processing agreement to sign with us, because we’re not in the path — confirmable in the Network Log, not just a claim. And because it’s your key, access is yours to cut: revoke it and every AI call stops, with no dependency on us to offboard. No integration into your identity provider. It doesn’t connect to your calendar and uses no OAuth sign-in. There’s no third-party app holding standing scopes inside your Google or Microsoft tenant — nothing to surface in an OAuth-app audit, because nothing was ever granted into your workspace. No central store of your meetings to breach. There’s no account and no server-side copy of your data, so the failure security teams plan for — a vendor gets breached and every customer’s transcripts leak — has nothing to leak here. There’s no honeypot because there’s no store. The audio never leaves the Mac. It’s captured and transcribed on-device and is never sent on any path. It sits on the machine under whatever disk encryption and device management you already run — not in a new location to govern. The traffic is watchable. The Network Log inside the app and nettop / Little Snitch outside it let them confirm what leaves the machine, with the full endpoint inventory in the network activity guide https://mimicscribe.app/docs/network-activity . And two things to be straight with them about, because they cut the other way: There is no central admin console or MDM management. No account means no org-wide policy enforcement or audit dashboard. For a company that requires centrally-managed, auditable software, that’s a real gap — this is an individual or small-team decision, not an enterprise procurement. Data policy isn’t the only policy. A device or software-installation policy and a recording-consent policy may still apply regardless of where the data goes. Check those too. The point of all of it: you’re not asking your security team to believe a privacy page. You’re handing them a setup where the AI provider is one they already approved, an architecture they can read, and traffic they can watch. A few common questions Can I use an AI notetaker with my company’s approved AI provider? Yes. Enter your own Google/Gemini key, or point MimicScribe at any OpenAI-compatible endpoint your company uses, in Settings → AI. The transcript text goes to that provider on your company’s account — not through us. Do I have to use MimicScribe’s servers for summaries? No. The zero-config default routes through an open-source, no-retention proxy, but you can switch the text features to your own provider key, an OpenAI-compatible endpoint, or a model running locally on your Mac. How do I prove to IT that data isn’t going somewhere it shouldn’t? Use the in-app Network Log to see each request’s destination, then confirm from outside the app with nettop -x -p <pid or a firewall like Little Snitch. With a local model or Offline Mode, there’s no cloud connection to see at all. MimicScribe runs on macOS as a menu bar app, started from a keyboard shortcut. Download it https://mimicscribe.app , read the custom endpoint setup https://mimicscribe.app/docs/custom-endpoint , or read the full privacy policy https://mimicscribe.app/privacy .