Getting dictation software approved by IT

If your company's IT department blocked Otter.ai, Fireflies.ai, or Read AI, you're not imagining an overreaction. Several universities and at least one state technology office have published near-identical policies in the past year, and a federal class action against Otter.ai is now testing, in court, whether that caution was justified. The reason isn't transcription quality. It's that transcription is the easy part — what happens to the recording after it leaves your microphone is what a security review can't sign off on. A cloud dictation or meeting-notetaker sends audio to a vendor's servers, and from there to whatever subprocessors that vendor uses to run its models: a chain of custody that has to be mapped, contracted and audited before anyone in a regulated or security-conscious organization can approve it.

The kind of tool that clears that review fastest is the one with nothing to review in that data flow: software that processes audio entirely on the device it was spoken into, with nothing sent anywhere. That's a narrower claim than "passes IT" — but it's the one that actually holds up, and it's worth understanding exactly what it does and doesn't remove from the checklist below.

Universities are already banning Otter.ai and Fireflies.ai — officially

The clearest documented case is the University of Utah's Office of Artificial Intelligence, which published guidance titled "Using Meeting Transcription and Summarization Tools? Be Sure to Choose Approved Software." It names names: it flags Otter.ai and Fireflies.ai directly as examples of unapproved tools and steers staff toward Microsoft Teams Premium and Zoom AI Companion instead, citing "significant risks related to data privacy, compliance, and institutional liability." The guidance is structured around three sections — key concerns with unapproved tools, the advantages of the university's approved alternatives, and recommended actions for staff — a shape that's becoming a template across higher ed.

Utah isn't alone, and the pattern is recent enough that it reads as a trend rather than one institution's preference:

• Chapman University's IS&T department issued a security notice in August 2025 stating that "the use of Read AI is prohibited due to security, privacy, and institutional data risks," after reports of the tool joining and recording meetings uninvited. It recommends Zoom AI Companion instead, with the consent of everyone on the call.
• The University of Washington deactivated Read AI institution-wide, stating the tool "is associated with security and privacy risks to institutional data" and can join, transcribe and summarize meetings "without the awareness or consent of other attendees."
• Mississippi State University blocked Read.ai and Otter.ai in Microsoft Teams, explicitly noting the decision followed "engaging with several other higher education institutions" — framed as a shared conclusion, not an isolated call.

The legal exposure isn't hypothetical either. In August 2025, Otter.ai was hit with a federal class action — Brewer v. Otter.ai, filed in the Northern District of California (case 5:25-cv-06911) — reported by NPR, alleging Otter's Notetaker recorded private conversations of people who weren't even Otter users and used those recordings to train its transcription models without their consent. That's precisely the scenario IT and legal teams are trying to pre-empt when they write policies like Utah's before an incident, not after one.

What does IT actually check before approving dictation software?

Whether the request lands with a university, a hospital, or a mid-size company, the review usually works through the same handful of questions, roughly in this order:

1. Outbound data flow. Where does the audio go the moment you stop talking — straight to a vendor's servers, buffered locally first, or nowhere at all?
2. Subprocessors and DPAs. Every additional hop the audio takes (the speech-to-text engine, the cloud host, any LLM used to clean up or summarize the transcript) is a separate vendor that needs its own Data Processing Agreement. One unreviewed subprocessor is enough to stall approval.
3. Retention. Is audio deleted right after transcription, or stored — and if stored, for how long, by whom, and can it be reused to train models? That last clause is the exact one under dispute in the Otter.ai lawsuit.
4. Accounts and SSO. Does the tool require a personal account outside the organization's identity provider? A tool that needs no login, or one that federates through existing SSO, is a smaller identity-management liability than one running its own separate user database.
5. Attack surface. What does the tool get access to once installed — calendar, microphone, screen, other participants' data? Read AI's ability to auto-join meetings via calendar integration is exactly what triggered the Chapman and UW notices above.

None of these questions are about how good the transcription is. They're about what a vendor can see, keep and reuse — which is precisely what's different once there's no vendor in the loop for that step.

Does running locally mean a tool automatically passes IT review?

No — and it's worth being precise about what changes and what doesn't, rather than overselling it.

What changes: if audio and transcript never leave the device, questions one through three above collapse. There's no outbound flow to map, no subprocessor to chase a DPA from, no server-side retention policy to interrogate — because there's no server in that path. That's an architectural fact, not a compliance certificate, and it's the same reasoning behind why Inkvox doesn't claim to be HIPAA compliant either — local processing removes one link from the chain a reviewer has to check, not the whole review. See the full breakdown on our privacy page.

What doesn't change: IT still has to evaluate the software itself — where the installer comes from, whether it's code-signed, how updates are delivered and verified, and what OS-level permissions it requests on install. A local app from an unfamiliar vendor is still new software running with system access, and a careful review treats it that way. Questions four and five above (accounts, attack surface) don't disappear just because the audio stays put: a local tool that phones home for license checks or asks for broad permissions unrelated to dictation reintroduces exactly the kind of surface a reviewer is trying to rule out.

So the honest version isn't "local software passes IT review." It's: local processing removes the hardest part of the review — the data flow — and leaves a narrower, more answerable set of questions about the software itself.

A checklist for getting local dictation software approved

If you're the one trying to get a tool approved — or writing the policy that decides — this is roughly the paper trail worth having ready before you ask:

1. Confirm the architecture in writing, not marketing copy. Ask how audio is processed, not just where it claims to stay.
2. Ask what phones home at all. License checks, crash reports, telemetry — and whether any of it can be disabled or is disabled by default.
3. Get the model provenance. Which speech-to-text model, whose weights, downloaded from where — and whether that download is verifiable (checksum, signed release).
4. Check the update mechanism. Auto-update from a known domain over HTTPS, or manual installer only?
5. Confirm account requirements. Does it need a login at all — and if so, does it integrate with existing SSO or create a new identity silo? A tool that skips accounts entirely removes this question outright; see how that plays out with dictation software that needs no account.
6. Ask for a data flow diagram. Even a one-page one. Reviewers move faster with something to sign off on than with a promise.

FAQ

Why do universities ban Otter.ai and Fireflies.ai specifically?

Because their core function — joining meetings, recording, and processing that audio on the vendor's servers — creates exactly the review IT departments want to avoid: an ongoing outbound flow of potentially sensitive conversations to a third party. The University of Utah's own guidance frames this as data privacy, compliance and institutional liability risk, not a transcription-quality complaint. Otter.ai is also currently facing a federal class action (Brewer v. Otter.ai) alleging it recorded conversations without consent and used them to train its models.

Does a local dictation tool need IT approval at all?

In most organizations, yes — software installed on a managed device typically goes through some review, even if it's lighter than for cloud SaaS. The difference is what that review has to cover: a local tool's review is mostly about the software itself (code signing, permissions, update mechanism), not about auditing a vendor's data-handling practices, subprocessors and retention policy.

Is Inkvox HIPAA compliant or SOC 2 certified?

No — Inkvox doesn't claim either certification. It's a private beta product built so that transcription never leaves your device, which removes the data-flow question from an IT review but doesn't replace an organization's own compliance program, risk assessment, or the rest of its software stack.

If your team already tried to get Otter.ai or a similar tool through review and hit a wall, the fix usually isn't a better vendor questionnaire — it's a tool that doesn't need one for the part that matters most. Inkvox runs Whisper large-v3-turbo, quantized, entirely on your own GPU through Vulkan — NVIDIA, AMD or Intel, with a CPU fallback — transcribes a sentence in roughly 0.3–0.4 seconds on a card like an RTX 3070, and never uploads audio: 0 bytes, no account required. It's currently in private beta. Join the waitlist and bring your IT team the architecture instead of a promise.