How privacy works when your AI copilot listens to every meeting

If you stop and think about it, putting an AI listener in every meeting on your calendar is a remarkable expansion of what gets recorded about your work life. Five years ago, the default assumption about most meetings was that nothing said in them would be stored beyond the participants' memories. Today, the default for many tools is full transcription, persistent storage, and AI processing of every word.

This is a real shift. It has real benefits — searchable history, automated recaps, cross-meeting pattern detection. It also has real costs, and pretending otherwise is the kind of dishonesty that erodes trust.

Here is the honest version of how a meeting copilot should handle privacy. This is our approach, and where we think the industry needs to land. We're not going to pretend it's solved.

The five questions

When evaluating any meeting copilot's privacy story, there are five questions to ask. Most tools answer one or two well and dodge the rest.

Consent. Who has to agree before the AI starts listening? How is the agreement obtained? Can it be withdrawn?
Scope. What data does the AI store? For how long? In what form?
Access. Who in the organization can see what was said? Under what conditions?
Use. What is the AI allowed to do with the data? Training? Cross-customer? Internal analytics?
Deletion. What happens when someone leaves the company, or asks for their data to be removed?

These are the questions. The right way to evaluate a tool is to ask them all and listen carefully to the answers.

Consent: the part most tools get wrong

The default consent model in many meeting tools is "if the meeting organizer enables it, everyone in the meeting is recorded." This is legally fraught in some jurisdictions (most of Europe, parts of California) and ethically fraught everywhere.

A better consent model has these properties:

Explicit, not implicit. Every participant has to actively agree to be recorded. Not "by attending you consent" — that's not real consent. A visible UI prompt that requires a click.

Per-meeting, not per-org. Just because you agreed to be recorded in the meeting last week doesn't mean you've agreed to all future meetings. Each meeting should require fresh consent, even if the system can remember your default preference.

Revocable mid-meeting. If you change your mind partway through, you should be able to opt out of recording, and the partial transcript should be deleted. Some tools do this; many don't.

Scoped to specific data types. A user might agree to live transcription for accuracy purposes but decline to have the transcript stored long-term. Or agree to the transcript but decline to have it included in cross-meeting search. Granularity matters.

Honored for guests. Customers, candidates, and external participants need the strongest consent protections, because they have the least power in the relationship. The bar should be higher for non-employees, not lower.

In our product, consent is per-meeting and revocable. The host can't override an individual participant's choice. If anyone in the meeting hasn't consented, recording doesn't start. This is restrictive — it sometimes prevents recording when only one person has declined — but it's the only model we think is defensible.

Scope: data minimization beats data security

A common framing is "we'll keep your data safe." This is necessary but not sufficient. The real question is: what data do you have in the first place?

Every piece of data you collect is a piece of data that can be:

Subpoenaed
Leaked in a breach
Used in a future product feature you didn't anticipate
Trained on
Sold or transferred in an acquisition

The cheapest, most reliable form of privacy is not collecting the data. This is "data minimization", and it's an underrated approach.

For a meeting copilot, data minimization means asking, for every category of data:

Do we actually need this?
For how long?
In what form?

Concretely:

Audio. Do you need to retain the raw audio? Most tools do, "for re-processing." We think most tools shouldn't. The audio is the most sensitive form of the data — it includes voice, tone, background sounds, things people accidentally said. Once the transcript is generated, the audio's value drops dramatically. Our default is to delete audio within 24 hours of processing.

Transcripts. Do you need the full transcript, or just the summary? For some use cases (search, decision archeology), the full transcript matters. For others (a single one-off recap), it doesn't. We let users choose per-meeting whether to retain the transcript or only the summary.

Identifiable speaker labels. Do you need to know who said what, or is the content the value? For some meetings, speaker labels are critical. For others, they add risk without value. We default to labels-on but make it easy to anonymize.

Sentiment, engagement, talk-time data. Do you need to compute these? Most teams don't. We don't compute them by default; we offer them as opt-in features for sales teams where they're legitimately useful.

The fewer fields you store, the smaller the attack surface, the lower the breach impact, the simpler the deletion story. Data minimization is the highest-ROI privacy decision a tool can make.

Access: who sees what

The access question is messier than it sounds. There are usually four or five distinct constituencies who might want access:

The meeting participants
Their managers
Their teammates
Other employees at the company
Legal/compliance teams

Different access for different types of meetings is the right answer, but it requires careful defaults.

For our product, the defaults are:

1:1s and private meetings: access only to the participants. No managers (unless the manager is a participant). No team-wide.
Team meetings (standup, planning, retro): access to the team members. Not to other teams by default.
Cross-team meetings: access to all attendees plus, optionally, the broader stakeholder group designated by the organizer.
All-hands and broadcast meetings: access to everyone the meeting was distributed to.
External-facing meetings (customer calls, candidate interviews): access to the internal participants only. Never to the external participant unless explicitly shared.

Crucially, no meeting is visible to anyone outside its access scope, regardless of role. Admins can't browse all meetings. Managers can't read their reports' 1:1s with other people. This restriction is real and enforced at the data layer, not just the UI layer.

The exception is legal/compliance access, which requires (in our model) a formal request, written justification, and the affected employees' notification. The bar should be high, not just available.

Use: what is the AI allowed to do

The most concerning category of "use" is training. Many AI products train their models on customer data. This is a legitimate value exchange in some contexts; in meeting data, it's almost never appropriate.

Our position: customer meeting data is not used for model training. Period. We use foundation models from third parties (Anthropic, OpenAI) that have their own data policies. When you use Pavleur, your meeting data flows through these providers under their enterprise-grade no-training agreements. We do not export meeting data to a separate training pipeline.

This is non-trivial. Foundation models get better when trained on more data. Meeting transcripts would be valuable training material. The temptation to use them exists in any company building this kind of product. The temptation should be refused, every time, because the trust cost of using customer meeting data for training is much larger than the model-quality benefit.

Other "uses" to scrutinize:

Cross-customer analytics. Does the vendor aggregate data across customers? "Anonymized" data is often re-identifiable. We don't aggregate across customers; each customer's data lives in their own isolated scope.

Internal product analytics. Some product telemetry is necessary (how many meetings are being processed, what features are being used). Telemetry should be about usage patterns, not content. We collect usage metrics; we don't analyze what was said.

Future feature development. When a vendor adds a new feature, are they backfilling it against existing meetings? This is a common pattern that surprises users. The right move is to require explicit opt-in for any new feature that uses existing data.

Deletion: the unsexy critical detail

Deletion is the most boring privacy topic and one of the most consequential.

The questions:

When an employee leaves the company, what happens to their meeting data?
When a customer cancels their account, what happens to their data?
When a user asks for their data to be deleted, how long does it take?
When a meeting is deleted, is it really deleted — or just hidden in the UI?

Our policies:

Employee leaves: their personal meetings (1:1s where they were a participant) are deleted within 30 days unless retained by the other participant. Team meetings they attended remain with the team.
Customer cancellation: all data exported on request, then deleted within 90 days.
User deletion request: processed within 30 days for the user's identifiable data; processed by content within 90 days (this longer window is for the technically hard work of removing them from cross-meeting search indices and decision graphs).
Deletion is hard-delete: the data is actually removed from primary storage, backups expire within 90 days.

These are GDPR-aligned but we'd hold to them regardless of the regulation. They're the right policies because they limit the long-tail risk of data persisting longer than its value.

Where the industry needs to do better

A few things most meeting copilots get wrong today, including, in places, us:

Consent banners that feel like checkboxes. "By joining this meeting you consent to recording" is not real consent. The user didn't have a chance to decline. The bar should be: would a reasonable person, given the actual choice, consent to this?

Buried data deletion options. Many tools make data deletion technically possible but practically obscure. The right move is to make deletion at least as easy as deletion of any individual file in a normal cloud storage product.

Vague training policies. "We may use your data to improve our service" is not specific. The right policy is explicit: "your meeting data is never used to train models; here is the contract with our LLM provider that enforces this."

Cross-meeting search that doesn't respect scope. It's easy to build a search index that surfaces results from meetings the searcher wasn't supposed to see. This requires careful access checks at query time, not just at storage time. Many tools get this subtly wrong.

Re-identification risk in aggregate analytics. "Anonymized" aggregate data can often be re-identified by combining multiple data points. If a tool publishes "engagement scores by team", and your team has three people, an "anonymous" score is really a score for the three of you. Worth scrutinizing.

The honest version of the privacy story

Putting an AI in every meeting is an expansion of surveillance. Even when done well, even with strong consent and minimization, the amount of meeting content that is recorded and processable is dramatically higher than it was a decade ago. Pretending this isn't a real change is dishonest.

The case for doing it anyway is that the value — searchable history, automated recaps, decision capture, productivity gains — is genuine and high. The case for doing it carefully is that the alternative is doing it carelessly, and careless meeting AI is going to produce the kind of breach or scandal that sets the whole category back five years.

We think the right approach is to be paranoid by default, transparent about the tradeoffs, and honest when we're getting something wrong. The companies that build this technology have a real obligation to handle it carefully. The customers who use it have a real obligation to demand answers to the five questions above.

If a vendor — including us — can't answer those questions clearly, that's the answer to whether you should trust them with your meetings.