AI Note-Takers Meet the Wiretap Statute: Inside the CIPA Litigation Wave and What It Means for Your Product's Privacy Architecture

If you ship a transcription feature, a meeting bot, or anything that touches audio from a conversation you didn't originate, this piece is for you. The privacy litigation aimed at AI recording tools is no longer theoretical. Four consolidated class actions against Otter.ai. A denied motion to dismiss against Google's AI voice product. A healthcare system sued for deploying an ambient clinical documentation tool. The common thread: plaintiffs are winning early procedural fights under statutes written decades before large language models existed, and the legal standard courts are converging on (capability, not intent) maps directly onto architectural decisions you are making right now in your codebase.

Key Takeaways

• Courts are applying a "capability test" under CIPA: if your system has the technical ability to use recorded data for its own benefit, that alone can sustain a wiretap claim, regardless of whether you actually use the data that way.
• The "we're just a passive tool" defense is failing. Google tried it; the court denied the motion to dismiss on all grounds.
• Liability extends beyond the vendor. Organizations that enable AI notetakers in meetings with residents of all-party-consent states face the same exposure as the software maker.
• SB 690, the California bill that would have created a broad commercial exemption to CIPA, has been gutted. No legislative safe harbor is arriving soon.
• Your own marketing copy and privacy policy language about model training can become a plaintiff's exhibit. Architecture choices (ephemeral processing, no training on customer audio) are not marketing flourishes; they are your legal defense.

What Statutes Are Actually Being Invoked Against AI Recording Tools?

Three overlapping regimes drive most of the active litigation. You need to understand each one separately, because they differ in consent requirements, available defenses, and damages.

CIPA (California Invasion of Privacy Act), §§ 631 and 632. California is an all-party-consent state. Section 631 prohibits wiretapping or reading the contents of a communication "without the consent of all parties." Section 632 makes it a crime to record a confidential communication without consent. Statutory damages run up to $5,000 per violation. Because California is home to most AI transcription vendors (and a large share of their users), CIPA is the statute doing the heaviest lifting in current complaints.

Federal ECPA (Electronic Communications Privacy Act), 18 U.S.C. § 2511. The federal wiretap statute allows the greater of $10,000 per violation or $100 per day. But it also provides an "ordinary course of business" exception that CIPA does not. In at least one call-analytics case, a court accepted that defense and rejected the ECPA claim. The practical effect: ECPA claims are sometimes easier to beat than CIPA claims, which makes CIPA the preferred tool for plaintiffs' counsel in California.

BIPA (Illinois Biometric Information Privacy Act). If your product does speaker identification or voice enrollment, you are collecting voiceprints, which BIPA treats as biometric identifiers. A lawsuit against Fireflies.AI alleges its speaker recognition feature collects and stores voiceprints from non-users who never consented, without written notice, a retention policy, or a destruction schedule. BIPA damages: $1,000 per negligent violation, $5,000 per intentional violation. And liability is not limited to the vendor named in the complaint; organizations that enable AI notetakers in meetings with Illinois residents can find themselves in the same lawsuit.

What Is the "Capability Test" and Why Does It Matter to Your Architecture?

It is the single most important legal development in this space. In Ambriz v. Google, the Northern District of California denied Google's motion to dismiss on February 10, 2025, holding that the definition of a third-party wiretap under CIPA extends to AI voice products that have the capability to use data for the software provider's benefit. Not proof that the provider actually trained on the data. Not evidence of a sale to a third party. Capability alone.

Google argued it was not a call participant but merely provided a tool, like a tape recorder. The court rejected that framing on all grounds. The "passive tool" defense did not survive the motion-to-dismiss stage.

This test is now spreading across the Otter, Google, and Fireflies cases. Legal commentary from Paul Hastings notes that courts are grappling with whether to classify AI transcription tools as third parties or mere software instruments, and plaintiffs have survived motions to dismiss wherever a vendor's mere capability to use data for its own purposes was found sufficient to implicate CIPA liability.

What does this mean if you are building? Your architecture is your defense. If your system retains audio server-side, if your privacy policy says you use conversation data to improve your models, if your infrastructure has the technical capability to route recorded content back into a training pipeline, then under the capability test, you may satisfy the elements of a CIPA wiretap claim regardless of what you actually do with the data.

What Does the Otter.ai Litigation Look Like Concretely?

Four federal class actions have been consolidated into In re Otter.AI Privacy Litigation (5:25-cv-06911, N.D. Cal.). The complaints allege that Otter's notetaker bot joins meetings through one participant's calendar integration and records non-Otter participants without their consent. The causes of action include CIPA §§ 631 and 632, ECPA, CFAA, and CDAFA.

A motion-to-dismiss hearing took place on May 20, 2026 before Judge Eumi K. Lee. As of mid-June 2026, the ruling was still pending.

The scale matters. Otter's own December 2025 press release stated its user base exceeded 35 million people with over a billion meetings processed. Multiply that by CIPA's $5,000-per-violation ceiling and you begin to see why this case has drawn attention beyond privacy law circles.

How Are Healthcare Deployments Being Targeted?

The litigation is not limited to knowledge workers on Zoom calls. A lawsuit alleges that Sharp HealthCare deployed an AI vendor in April 2025 to automatically record clinical encounters on clinicians' devices and generate draft notes, without obtaining all-party consent as required under CIPA. Clinical conversations are precisely the kind of "confidential communication" that § 632 was designed to protect. If you are building ambient clinical documentation, or selling a transcription API into a healthcare vertical, the Sharp complaint is your required reading.

Why Is the "Passive Tool" Defense Failing?

Because courts are looking at what the vendor's infrastructure can do, not what the user intended. The analytical move is straightforward: a tape recorder sits on the table and does nothing with the audio. An AI transcription service ingests audio, processes it through models hosted on the vendor's infrastructure, stores transcripts, and (in many cases) feeds data back into product improvement loops. That processing chain gives the vendor capabilities a tape recorder does not have. Under the capability test, those capabilities are enough.

The IAPP has framed this as "dressing old laws in class action suits," and that framing is accurate. CIPA was written in 1967. It was not drafted with cloud-based NLP pipelines in mind. But its text is broad enough to cover them, and courts are reading it that way.

Can Your Own Marketing Copy Become a Plaintiff's Exhibit?

Yes. It already has. In the ConverseNow case, the court pointed to the company's own website and privacy policy language stating that its "self-learning system improves with each processed conversation" and that caller data is used "to improve its platform, advertisements, products, and services." That language was treated as evidence of the vendor's capability (and arguably intent) to use intercepted communications for its own benefit.

Go read your own marketing site right now. If you have a page that says your AI "learns from every conversation" or "gets smarter over time," you have created potential evidence that a plaintiff's attorney will screenshot and attach to a complaint. This is not hypothetical; it has already happened in a case that survived a motion to dismiss.

Do Platforms Like Google Meet and Microsoft Teams Add Another Layer of Risk?

They add friction, which changes the consent calculus. Google Meet now flags AI notetaker bots as "potential risk," and Microsoft Teams routes them to a "Suspected threats" lobby via policy setting MC1251206. Microsoft's ExternalBotAccessMode includes options like RequireApprovalWhenDetected (the default) and BlockDetectedBots, which lets an IT admin block all bot-based notetakers tenant-wide with a single command.

If you rely on bot-based meeting access, these platform-level controls can break your product overnight. More relevant to the legal question: if a platform actively warns meeting participants about your bot, and a participant admits the bot anyway, does that constitute "consent" under CIPA? The case law has not answered that yet. But the fact that the platform flagged your tool as a potential threat is unlikely to help your defense.

Is Legislative Relief Coming?

No. Not soon. SB 690, the California bill that would have added a broad "commercial business purpose" exemption to CIPA, has been repeatedly scaled back. The broad exemption that would have insulated businesses using common tracking technologies from CIPA claims is gone. The July 2, 2026 amendment eliminated the "commercial business purpose" exemption entirely. Opposition groups have not shifted toward neutral or support.

If your compliance roadmap includes a line item that says "wait for SB 690," delete it.

Which States Require All-Party Consent?

Twelve U.S. states require all-party (sometimes called "two-party") consent for recording: California, Connecticut, Florida, Illinois, Maryland, Massachusetts, Michigan, Montana, New Hampshire, Oregon, Pennsylvania, and Washington. Each has its own statutory nuances. If even one participant on a call is located in an all-party-consent state, the strictest standard arguably applies. For a distributed team on a multiparty video call, that means your consent flow needs to handle jurisdiction detection per participant, not per meeting.

How Should You Audit Your Consent Flow?

Start from the assumption that your current flow is insufficient, and work backward. Here is what courts and compliance analyses are looking at:

Does your consent gate actually gate anything?

This is the "broken banner" problem applied to meeting bots. Compliance write-ups on CIPA website cases have established that a site promising no tracking after a user declines, but tracking anyway, is treated by courts as worse than having no banner at all. The same logic applies to your recording consent prompt. If your bot displays a "recording will begin" notification but starts capturing audio before every participant has affirmatively consented, you have a consent flow that creates liability rather than mitigating it.

Test this at the network level, not just the UI level. Intercept the traffic from your bot and verify that no audio data leaves the client before consent is captured from each participant. A UI element that says "waiting for consent" while audio packets are already streaming to your transcription endpoint is worse than useless.

Are you capturing per-participant consent or per-meeting consent?

CIPA requires consent from "all parties." A single consent from the meeting organizer does not satisfy the statute. You need evidence that each recorded participant was notified and consented. If a participant joins the meeting after your consent prompt fires, they were never asked. Your system needs to handle late joiners.

Do you have an audit trail designed for discovery?

If you are ever named in a CIPA class action, your attorneys will need to produce records showing what consent was obtained, from whom, at what timestamp, and whether recording began before or after consent was captured. If your consent events are logged in a different system than your recording-start events, or if timestamps are not synchronized, you will spend months in discovery trying to reconstruct a timeline. Build the audit trail now, in the same data store, with the same clock.

Are your consent prompts jurisdiction-aware?

A one-party-consent state and an all-party-consent state require different disclosures and different consent mechanics. If you can determine participant location (from IP, from profile data, from calendar metadata), you should adjust your consent flow accordingly. If you cannot determine location, the conservative approach is to default to all-party consent everywhere.

What Architectural Choices Serve as Legal Defenses?

Under the capability test, your system architecture is directly relevant to your legal exposure. The question a court will ask is not "did you misuse the data?" but "could you have misused it?" That reframes several engineering decisions:

Server-side audio retention. If you retain audio on your servers after transcription is complete, you have the capability to use it later for training, analytics, or any other purpose. If audio is processed ephemerally and never written to persistent storage, the capability argument weakens substantially. This is a design decision with direct legal consequences.

Training on customer audio. If your models are trained (or fine-tuned) on customer conversation data, you have not just the capability but the demonstrated practice of using intercepted communications for your own benefit. A contractual commitment not to train on customer data, backed by an architecture that enforces it (separate data pipelines, no access paths from the transcription service to the training infrastructure), is a stronger defense than a privacy policy sentence.

Data-use disclosures. Everything on your marketing site and in your privacy policy is potential evidence. Audit it. If your landing page says "our AI learns from every conversation," you should either (a) stop saying that, or (b) make sure you have airtight consent covering that use. The ConverseNow court treated exactly this kind of language as evidence supporting the plaintiff's claims.

Does Liability Extend to Your Customers?

Yes. This is the part most vendors are not warning their customers about, and it creates a secondary obligation for you. Analysis of AI meeting recorder lawsuits notes that liability is not limited to the vendor named in the complaint. An enterprise customer that deploys your meeting bot across its organization, recording calls with external participants who never consented, can be drawn into the same CIPA or BIPA action.

This means your customers need tools to demonstrate their own compliance, not just trust that you, the vendor, are handling consent. Shipping per-participant consent logs, jurisdiction-aware consent prompts, and audit trails that your customer's legal team can pull in response to a discovery request is not a nice-to-have. It is a feature that reduces your churn from legal-department-mandated removal, and it reduces the blast radius of any litigation that does materialize.

What About the ECPA "Ordinary Course of Business" Exception?

It exists, and it has worked in at least one case. A court rejected an ECPA claim against a call-analytics vendor, ruling that the alleged interception was done in the ordinary course of the defendant's electronic communication business, an exception the ECPA provides. But CIPA does not offer a comparable exception. If your users are in California (and statistically, many of them are), the ECPA defense does not help you with the CIPA claim. You need to survive both.

What Should You Do This Week?

A concrete checklist, in priority order:

1. Audit your marketing site and privacy policy for "self-learning" or "model improvement" language. If it says your AI improves from customer conversations, either remove it or ensure your consent flow explicitly covers that use.
2. Test your consent gate at the network layer. Verify that zero audio data is transmitted before per-participant consent is recorded. A UI prompt that fires after audio capture has already begun is a liability multiplier.
3. Implement per-participant consent logging with synchronized timestamps. Store consent events and recording-start events in the same system, with the same clock source.
4. Handle late joiners. If a new participant enters a recorded meeting, your system should pause recording (or at minimum notify and capture consent) before processing that participant's audio.
5. Default to all-party consent in ambiguous jurisdictions. If you cannot determine a participant's location, treat the conversation as subject to the strictest applicable standard.
6. Review your architecture for capability exposure. Do you retain audio server-side? Do you have a data path from your transcription pipeline to your training infrastructure? Under the capability test, the existence of that path is itself a risk factor.
7. Ship consent tooling for your customers, not just for yourself. Give your enterprise customers audit trails, exportable consent logs, and jurisdiction-aware prompts they can point to when their own legal teams come asking.

Where Is This Heading?

The motion-to-dismiss ruling in In re Otter.AI Privacy Litigation will be the next significant data point. If the court follows the Ambriz capability test, expect the litigation wave to accelerate. If it finds a meaningful distinction (perhaps based on how Otter's consent flow works relative to Google's), there may be a narrow path for vendors with strong consent mechanics.

Either way, the structural incentives are clear. CIPA statutory damages at $5,000 per violation, multiplied by class sizes in the millions, create settlement pressure that is difficult to resist. Plaintiffs' firms have noticed. The number of CIPA filings targeting AI tools is increasing, not plateauing.

And the biometric front is compounding. If your product does speaker diarization, voice enrollment, or any form of speaker identification, you are collecting biometric data under BIPA's definition. That is a separate cause of action, with separate damages, and separate consent requirements (written consent, a published retention schedule, a destruction policy).

The founders who will navigate this successfully are the ones who treat consent as an engineering problem, not a legal afterthought. Consent flows that actually gate recording. Architectures that minimize capability exposure. Audit trails built for adversarial scrutiny. Marketing copy that does not hand plaintiffs their exhibits.

None of this is glamorous. It is plumbing. But the plumbing is what courts are examining, and what they find there will determine whether your company is a defendant or a case study in how to do it right.

If you want an AI assistant built with this kind of architectural discipline, start a free 7-day trial, no card required.

Michael C.

Founder & Principal Engineer, Selina Labs

Michael builds Selina, a privacy-first AI that remembers you across conversations. He ships security-sensitive AI in production — real attacks, real fixes, measured in minutes and dollars — and writes about privacy, security, and LLMs from that seat. Top Rated Plus and expert-verified on Upwork.

• www.upwork.com
• x.com
• medium.com
• selinalabs.io