Otter.ai is being sued in the Northern District of California for capturing audio, transcripts, and voiceprints from Zoom, Teams, and Google Meet calls without participant consent, then using that data to train its models. Fireflies.ai is facing a separate biometric privacy suit in Illinois over the same kind of voiceprint capture. Google Meet now denies third-party notetaker bots entry by default. None of that goes away by switching SaaS vendors. It goes away when the audio never leaves infrastructure you control.
This guide covers why enterprises, law firms, and healthcare organizations are pulling Otter.ai and Fireflies off sensitive calls, what to deploy instead (a meeting bot or local capture layer, faster-whisper for transcription, an open-weight LLM for summaries), and how to size the GPU for 10, 50, or 200 concurrent meetings. If you're new to self-hosting decisions generally, our AI buyers guide covers the broader framework for evaluating hardware control and total cost of ownership before you commit to any GPU cloud provider.
Why Enterprises Are Banning Otter.ai and Fireflies for Sensitive Calls
Otter.ai has more than 35 million users and has processed over a billion meetings as of December 2025, according to UC Today's coverage of the ongoing litigation. That scale is exactly why the current lawsuits matter: this isn't a niche tool, it's infrastructure that a huge number of companies plugged into their calendars without reading the data flow closely.
The Legal Exposure Driving the Ban: BIPA, ECPA, and the Otter.ai Class Action
In re Otter.AI Privacy Litigation (case 5:25-cv-06911, N.D. Cal.) consolidates four suits filed in August and September 2025. Plaintiffs allege that OtterPilot, Otter's meeting bot, captured audio, transcripts, screenshots, and voiceprints from participants who never consented, then used that data to train Otter's models. A motion-to-dismiss hearing is scheduled for May 20, 2026.
The damages math is what should get a general counsel's attention. UC Today's reporting breaks down the exposure across three statutes: ECPA claims carry the greater of $10,000 per violation or $100/day, CIPA claims carry $5,000 per violation, and BIPA claims carry $1,000 to $5,000 per violation. Multiply any of those by a few hundred meetings a quarter and the number stops being theoretical.
Otter's CEO Sam Liang has been unambiguous about the company's position: "My view is that we are on the right side of history. We're building this new AI revolution. If you want AI to help, you need to put AI in the meetings." Otter's April 2026 court filing takes the narrower legal line that plaintiffs "do not plausibly allege they disclosed private information, that Otter intercepted communications in transit, or accessed computers without authorization." Whichever way the motion to dismiss lands, the underlying architecture, a third-party bot recording and retaining voiceprints by default, is the thing companies are now trying to route around rather than defend.
The consent model underneath the Otter suit is the actual design flaw. Jackson Lewis's Workplace Privacy Report points out that Otter sought recording permission only from the meeting host, and sometimes not even that, rather than from every participant on the call. The report frames the resulting exposure plainly: that single-consent model "is risky in states like California that require all-party consent," which is exactly the gap plaintiffs are pointing at in the complaint.
Fireflies.ai has its own version of the same problem. *Cruz v. Fireflies.AI Corp.*, filed in Illinois in December 2025, alleges the company's "Speaker Recognition" feature generates voiceprints without the written notice or consent BIPA requires. A second case, Fricker v. Fireflies.AI Corp., followed in the Northern District of Illinois in March 2026.
Platform-Level Lockout: Google Meet and Microsoft Teams Now Flag Third-Party Bots
As of March 2026, Google Meet screens incoming join requests into two queues based on risk: a queue for confirmed participants already on the invite or in the host's organization, and a second queue for anything Google's system flags as potentially risky, which is automatically denied unless the host steps in. Third-party notetaker bots land in that second queue by default. A host has to manually admit the bot into every single meeting; there's no persistent allowlist. Microsoft Teams is rolling out a comparable move: the platform now detects third-party bots as they try to join, labels them "Unverified" in a "Suspected threats" area of the meeting lobby, and requires the organizer to explicitly admit them, with an automatic-block option for admins arriving in August 2026 that skips the approval step entirely and just keeps unrecognized bots out. Read AI avoided the same fate by shipping a botless, first-party integration built directly on Google's Meet Media API in March 2026, which is the exception that proves the rule: the vendors still getting flagged are the ones still relying on a bot joining as an unapproved third-party participant.
Neither company built this because of the litigation specifically. Both frame it as a security response to bots masquerading as legitimate participants. But the practical effect is the same either way: a workflow that used to be "the bot joins silently" is now "the host manually approves a flagged third-party tool, every time, for every meeting." That friction alone is pushing IT teams to look for something that doesn't trip the flag at all, because it isn't a third-party bot in the first place.
Who's Already Banning Them: Health Systems, Law Firms, and Regulated Industries
The clearest real-world example isn't a hypothetical. An Otter.ai transcription bot gained access to a hospital's virtual hepatology rounds meeting through a former physician's personal calendar, over a year after that physician had left the organization, and emailed the transcript to 65 people including former staff. The Ontario Information and Privacy Commissioner investigated. The hospital's response, per reporting on the incident, was to block AI scribe tools like Otter.ai at the firewall, update privacy training to cover AI transcription explicitly, and tell physicians to check the participant list for unapproved AI tools before discussing any patient information.
Law firms face a parallel obligation. NYC Bar Formal Opinion 2025-6, issued December 22, 2025, holds that attorneys must get client consent before using AI to record, transcribe, or summarize a client call, must evaluate the AI vendor's data storage and training practices as part of that decision, and must independently verify AI-generated transcripts for accuracy before relying on them professionally. That last requirement, verifying accuracy, is hard to satisfy for any tool whose model and data pipeline you can't inspect. Our self-hosted legal AI guide covers the broader pattern of law firms moving off hosted AI vendors for the same reason: privilege and accuracy obligations are easier to defend when the infrastructure is yours.
Healthcare has its own version of this requirement layered on top through HIPAA. If clinical intake calls, patient consultations, or care coordination meetings are being transcribed, the deployment needs to satisfy the Security Rule the same way any other PHI-touching system does. Our HIPAA-compliant GPU cloud guide covers what that checklist actually requires, since no LLM or transcription model is HIPAA certified on its own, only a full deployment can be.
The Self-Hosted Stack: Real-Time Transcription Plus an Open-Weight Summarization Model
A self-hosted meeting assistant has three layers: something to capture the audio, something to transcribe it in real time, and something to turn the transcript into notes and action items. None of these need a frontier model or a hosted API.
Transcription Layer: Whisper and faster-whisper for Live ASR
Whisper is the transcription backbone for both open-source options in this space, and running it well is a solved problem at this point. We've already covered the deployment mechanics in detail in our faster-whisper on GPU cloud guide, so this post won't re-derive them. The short version: faster-whisper runs on the CTranslate2 backend, hits 4-5x the throughput of reference Whisper, and uses roughly half the VRAM at INT8 quantization with under 0.2% WER regression. On an RTX 4090, a 3-second audio chunk transcribes in under 15ms with faster-whisper at INT8, against 300-600ms for the same chunk on CPU. That latency gap is what makes GPU-based live meeting transcription feel instant instead of laggy, and it's the same reason a self-hosted setup can match or beat what Otter.ai's backend does today.
Meeting Bot Layer: Joining Zoom, Teams, and Google Meet Without a Third-Party Vendor
Two open-source projects cover the capture layer, with genuinely different architectures.
Vexa is Apache 2.0 licensed and works the way Otter and Fireflies do today: it sends a bot into Google Meet or Microsoft Teams (Zoom support is in progress) via a meeting URL, transcribes with Whisper, and does speaker diarization at sub-second latency. The difference is that Vexa exposes transcripts through REST, WebSocket, and MCP endpoints and is fully self-hostable via Docker, Kubernetes, OpenShift, or bare metal, so meeting data stays on infrastructure you control instead of a third-party's inference backend. Vexa also offers a hosted bot tier starting at $0.30/hour if you want to skip self-hosting the bot layer specifically while still owning the transcription and summarization stack.
Meetily, built by Zackriya Solutions and MIT licensed, takes the opposite approach: no bot, no browser extension, no platform integration at all. It's a Tauri desktop app (Rust backend, Next.js frontend) that captures system and mic audio directly on the machine it's running on, transcribes with Whisper or Parakeet via whisper.cpp, and summarizes with Ollama or a bring-your-own API key. GPU acceleration is automatic: CUDA on Windows and Linux, Metal and CoreML on macOS.
The choice between them comes down to how centralized you need the transcript store to be. Vexa is the right shape for a company-wide deployment where IT wants one API and one place transcripts land. Meetily is the right shape for a team that wants zero platform-side footprint and doesn't need a central bot managing every meeting.
Summarization Layer: Picking an Open-Weight LLM for Meeting Notes and Action Items
Meeting summarization doesn't need a frontier reasoning model. It needs reliable instruction-following on a long transcript, consistent extraction of action items and owners, and low enough latency that notes land in someone's inbox minutes after the call ends, not hours. Our open-source LLM VRAM tier guide has the full model-by-model breakdown by VRAM budget; for meeting notes specifically, a 7B-8B instruction-tuned model handles short standups and status calls well, and a 32B-class model produces noticeably better long-form summaries and action-item extraction on hour-long strategy or client calls. Either tier fits comfortably on a single A100 40GB instance at FP8 quantization, the same sizing that works for co-located transcription-plus-summarization deployments generally.
GPU Sizing for Live Meeting Transcription at Company Scale
Per-Meeting VRAM and Throughput Math
The math that matters here isn't raw compute, it's concurrency headroom. Because a 3-second chunk transcribes in under 15ms on a GPU, any single meeting stream uses a tiny fraction of a card's real-time compute budget. The actual constraint is VRAM and scheduling overhead across simultaneously loaded model instances and audio buffers, not whether the GPU can keep up with any one call in isolation. That's why sizing for meeting transcription is a concurrent-streams question, not a per-meeting compute question.
Sizing for 10, 50, and 200 Concurrent Meetings
Our Whisper v4 production ASR guide has the full concurrency benchmarks this table draws from:
| Concurrent meetings | GPU tier | Notes |
|---|---|---|
| Up to 10 | A100 40GB or L40S | Well under either card's streaming ceiling; room to co-locate the summarization model on the same instance |
| Up to 50-60 | A100 40GB or L40S | Approaches the ~60+ concurrent Whisper Large v3 INT8 stream ceiling per card; plan a second instance if headcount is growing |
| 200 | H100 SXM5 | Scales to 150-250+ concurrent streams on a single card; two A100/L40S instances behind a load balancer is the alternative if you'd rather scale horizontally |
A 40GB A100 instance on Spheron runs $1.71/hr on-demand as of this writing, which comes out to roughly $1,231/month kept warm 24/7, the same shape of number we found sizing a self-hosted AI SDR on the same card. An H100 SXM5 runs $5.07/hr on-demand ($2.94/hr spot), or roughly $3,650/month kept warm continuously on-demand. L40S availability varies by region on a marketplace GPU cloud, so check current GPU pricing for the live rate before committing to a specific card.
Pricing fluctuates based on GPU availability. The prices above are based on 27 Jul 2026 and may have changed. Check current GPU pricing → for live rates.
On-Demand vs. Spot for Meeting Workloads
Spot pricing looks attractive on paper (roughly 42% cheaper on H100 SXM5 at today's rates) but a live meeting transcription workload is a bad fit for a card that can be reclaimed without notice. If a spot instance gets preempted mid-meeting, you lose transcription for whoever is on the call at that moment, not a batch job you can simply requeue. Spot makes sense for the summarization layer, where a queued job can wait a few minutes to retry, but keep the live transcription tier on-demand.
Keeping Recordings and Transcripts Inside Your Own Infrastructure
Storage, Retention, and Access Control for Meeting Data
Self-hosting only delivers on the privacy promise if the storage layer is actually locked down. Encrypt transcripts and audio at rest, scope access by role rather than giving every employee read access to every meeting's notes, and set a retention window that matches your actual legal obligation rather than keeping everything indefinitely by default, which is precisely the pattern that made Otter.ai's data footprint a target in the first place. If you're feeding summarized transcripts into a broader knowledge base for search, our self-hosted document intelligence guide covers the ingestion pipeline for turning meeting notes and other documents into a searchable, access-controlled RAG store rather than a flat pile of files.
Consent and Compliance Still Apply Even When You Self-Host
Self-hosting removes the vendor from the data path. It does not remove the consent requirement. Two-party consent states still require every participant to agree to being recorded regardless of who owns the transcription server, and NYC Bar Formal Opinion 2025-6's rule that attorneys must disclose AI recording to clients applies just as much to an in-house Vexa deployment as it does to Otter.ai. Build a visible, spoken or on-screen consent notice into the bot join flow (both Vexa and Meetily support custom bot display names, which is a reasonable place to signal "recording in progress") and don't treat self-hosting as a substitute for that step.
Confidential Computing for Legal, Healthcare, and Financial Meetings
For meetings where the content itself is the risk, board discussions, client-privileged legal calls, patient consultations, deal terms, self-hosting alone handles the "no third-party vendor" problem but not the "what if someone with infrastructure access looks at GPU memory" problem. Our confidential GPU computing guide covers NVIDIA's TEE mode and encrypted VRAM, which adds hardware-level attestation so that even the infrastructure provider can't inspect what's running during inference. That's the right tier for the subset of meetings where "we self-host it" isn't quite enough assurance on its own.
Self-hosting a meeting assistant is the same pattern we've seen play out across other per-seat AI categories: our self-hosted AI SDR guide walks through nearly identical infrastructure and cost math for replacing a SaaS sales agent, and the conclusion holds here too. The GPU cost is flat and predictable. The legal exposure of routing sensitive audio through a third-party vendor's inference stack is not.
Otter.ai and Fireflies' legal exposure is a data-path problem, not a model-quality one. Running transcription and summarization on your own GPU keeps that data path entirely inside your infrastructure.
Frequently Asked Questions
For a team running 10-50 concurrent meetings, one A100 40GB instance handles both live transcription and summarization comfortably. At Spheron's on-demand rate that runs roughly $1,231/month kept warm 24/7. Add a small CPU node for the bot orchestration layer (Vexa's REST API or a Meetily deployment) at $30-80/month. Total: roughly $1,260-1,310/month against a per-seat SaaS contract that scales with headcount indefinitely.
Pick based on where your meetings happen and who needs to see the notes. Vexa (Apache 2.0) sends a bot into Google Meet, Microsoft Teams, or Zoom and exposes transcripts over REST, WebSocket, and MCP, which is the right shape for a company-wide deployment that needs one central transcript store and API access for downstream tools. Meetily (MIT) is a local-first desktop app that captures system and mic audio directly with no bot and no browser extension, which suits an individual or small team that wants zero platform-side footprint at all, at the cost of not centralizing transcripts automatically.
Self-hosting removes the specific defect named in the current lawsuits, that a third-party vendor captured audio and voiceprints without consent and reused them for model training, because there is no third-party vendor in that data path anymore. It does not remove your own obligation to get consent from meeting participants under two-party consent states or under professional rules like NYC Bar Formal Opinion 2025-6. Self-hosting changes who is accountable for consent and retention, not whether consent is required.
An L40S (48GB VRAM) or A100 handles roughly 60+ concurrent Whisper Large v3 INT8 streams, which is enough for most mid-size companies. At 200 concurrent meetings you need H100-class capacity: a single H100 SXM5 (80GB) scales to 150-250+ concurrent streams. Run the summarization model on a separate GPU (or a second instance) sized for your chosen open-weight model's VRAM tier, since transcription and summarization have different latency profiles and shouldn't share a scheduling queue under load.