Where Does Your Meeting Data Actually Go? 5 Questions IT Buyers Should Ask

Somebody at your company may already be recording meetings with a tool that nobody in IT has checked. You can actually find that out today.

Your meeting platform's admin console keeps participant logs. Notetaker bots usually join under their own names, so they show up in the attendee list as people who obviously aren't people. Google Meet, Zoom, and Teams all give you some visibility into this.

That's shadow IT, and meeting tools are one of the easier ways it walks in. It's also the easy part, and it only catches tools that actually join the call. If someone is recording from their laptop without joining as a bot, there may be no trace of it in the meeting platform at all. That difference matters, and we'll come back to it in question 4.

The harder part is the tool you're being asked to approve. In that case, all you may have to go on is a privacy page.

There are five questions that can get you much further. Together they make a vendor due-diligence checklist, and for each one there's a check you can actually run instead of simply taking the vendor's word for it.

These are the questions that get asked from the other side of the table. Buyers in healthcare, fintech, and services ask them before they sign off on a tool, and they're the ones worth borrowing.

Full disclosure before we start: we build Meetily, an open-source meeting assistant that transcribes meetings on your own machine. So we have a stake in question 3.

Don't take our word for it. Run the same checks on us that you'd run on anyone else, and tell us if we've got something wrong.

Does the audio leave the machine? Does your content train a model? And whose model is it in the first place?

Let's go through it.

The five questions, up front

Use that as your security checklist before approving any meeting tool. Start with question 1: the offline check answers most of it in a couple of minutes, without asking anyone for a document. The rest of this post is those five questions in that order, with what a good answer looks like and how to get one.

Under GDPR, the responsibility is yours

This changes how everything below reads, so it belongs before the questions.

Under GDPR, the company whose employees are being recorded is the controller. You decide why and how their data is processed, so the responsibility sits with you. That's Article 4(7). The vendor is the processor. They process the data on your instructions.

If a vendor mishandles your recordings, the regulator can come to you first.

That's why "we picked a tool with a good privacy page" isn't a defense. Article 28(1) says you can only use processors that provide "sufficient guarantees" about how they handle data. Our GDPR compliance guide walks through what that means for meeting recordings specifically.

A guarantee means evidence, and getting that evidence is your job. That gap between what a policy says and how a system is actually built is the subject of Why "Privacy Policy" Is Not the Same as "Privacy Architecture".

What's actually sitting in a transcript archive

"Your data is valuable" doesn't mean much anymore. So here's what that actually looks like.

A year of meeting recordings at a normal company can contain:

• Pipeline reviews with named accounts and real numbers
• Board and investor calls, months before anything goes public
• Salary bands, offer decisions, and performance conversations
• Legal strategy and acquisition talks that could be material non-public information

People say things in meetings they would never put in writing. And a recording can capture people who never signed up for the tool in the first place: candidates, customers, and your own employees. In several countries, a person's voice can also count as biometric data, which is why regulated sectors like healthcare treat recordings differently from other documents.

That's why meeting AI deserves a closer look than most of the tools you approve. The longer argument is in Why Your Meeting Data Belongs on Your Device and on our data sovereignty page.

Question 1: Where does the audio go?

Every meeting AI will tell you it's secure and private. The useful differences show up when you ask a question where a wrong answer could mean a contract breach, or when you can verify the answer yourself on the network.

The first thing you'll often hear is, "It's encrypted in transit."

That only tells you the file was protected while it was being uploaded. It doesn't tell you who has it afterward, where it's stored, or how long they keep it.

So start with a simpler question: Does the audio leave the device at all?

If it does, ask which company receives it, which country it goes to, and how long it's kept. Push for an actual number on that last one. "Deleted after processing" can still leave room for quality reviews, model testing, backups, or support access.

How to check: watch your own network

Run the tool and watch what it does on the network. On macOS, Little Snitch or lsof -i can show you outbound connections. On Windows or Linux, you can use Wireshark or your own egress logs.

1. Start a recording and let it transcribe for five minutes.
2. Write down every destination it connects to.
3. Disconnect the network and try again.

If a tool can transcribe completely offline, transcription itself doesn't require an upload. It doesn't prove nothing is shipped later: a tool can transcribe locally and still queue the audio to upload when the network comes back. The live packet capture from step 2 is what shows you that.

Step 3 needs no tooling and takes a couple of minutes. Step 2 is the slower half: if you've never set up a network monitor, budget an afternoon the first time, and read the destinations carefully, since TLS hides what was sent but not who it went to. Either way you're not asking anyone for documents or trusting what a vendor tells you, which is why we'd run this before asking the vendor a single question.

Question 2: Is your content used for training?

This is probably the question buyers ask most often, and one of the easiest to ask badly.

A promise on a marketing page is just copy. It can be changed without notice, and there's usually no version history for you to check. A real commitment should be in the contract, usually the data processing agreement.

Think about the last tool you approved. Did you actually open the agreement, or did you read the privacy page and move on?

Four words to search the contract for

Open the agreement, search for each of these, and read the sentences around every match.

Why "de-identified" catches people

Under HIPAA, de-identification has a specific technical standard in 45 CFR 164.514. You either have an expert determine that the data is de-identified, or remove eighteen specific identifiers. Our HIPAA setup guide covers what that means when a meeting tool is in scope.

GDPR doesn't use "de-identified" in the same way.

It does distinguish between pseudonymized and anonymized data. Pseudonymized data is still personal data and remains covered by GDPR. Properly anonymized data falls outside the law, but the bar is much higher than most people assume.

So if a vendor writes "de-identified" in a European contract, don't assume they mean anonymized. Ask them which one they mean, and get the answer in writing.

How to check: get it into the contract

Don't stop at the website. Search the contract, and get the answer written into the agreement.

Question 3: Whose model is it?

Buyers often skip this one, and skipping it can undo everything question 2 established.

Most meeting tools don't run their own AI models. They send the data to somebody else's model. So the terms that actually govern what happens to your transcripts may belong to the model provider, not the meeting tool you bought.

A vendor can honestly tell you, "We don't train on your data," while sending your data to a provider whose default tier does allow training.

Both statements can be true at the same time. Only one tells you what happens to your data.

The data isn't sitting with one company. It passes through three or four before it ends up anywhere permanent, and each one has its own terms.

Meeting AI works the same way.

Ask which provider handles the text, which tier you're on, and which agreement covers it. Enterprise and API tiers can have very different retention and training terms from the consumer product with the same name. You won't always hear that distinction in a sales call unless you ask.

We keep reference pages for the major providers, including OpenAI, Azure OpenAI, Gemini, and Anthropic, with the rest here.

How to check: name the provider and the tier

Get the provider and the exact tier in writing. Then read that provider's terms yourself instead of relying on the meeting vendor's summary.

Question 4: Who else can read it?

There are three groups to ask about, and vendors usually answer for only the first.

Vendor staff

Can a support engineer open your transcript?

If so, who approves that access? Is it logged? Can you get the access log?

"Only with customer permission" sounds good, but there needs to be a mechanism behind it, not just a sentence in a policy. Our own answer is on the security page.

Subprocessors

The transcription engine, model provider, cloud host, and analytics tool may all be different companies, each with its own retention policy.

That's why the subprocessor list is one of the most useful documents a SaaS vendor can give you. It's basically an inventory, so there's less room to hide behind vague language than there is in a privacy policy.

It's also often buried three clicks deeper than it should be.

Article 28(2) gives you a right to be involved when a processor wants to add subprocessors, subject to the terms of your agreement. That's why you should ask for the actual list rather than settling for "we use trusted third parties."

The bot, if there is one

A bot is an account with access to your meeting. That's what made the check at the beginning of this post possible.

It also creates a separate question: who agreed to let that bot into the meeting?

Recording from someone's laptop without a bot avoids the visible attendee, but creates a different problem. Nothing in the meeting itself tells people that recording is happening.

That's the trade-off we discuss on our bot-free page, and at more length in You Don't Need a Bot in the Room to Take Compliant Meeting Notes.

Either way, telling people they're being recorded is still your responsibility. No meeting tool, whether it joins as a bot or records quietly from a laptop, can take that responsibility away from you.

How to check: read the subprocessor list first

Most vendors publish it as a separate page, usually linked in small type at the foot of the privacy policy or inside the data processing agreement. If you can't find one, that's itself an answer: ask for it in writing and note how long it takes to arrive.

Question 5: Can anyone outside the vendor confirm it?

Everything above is still a claim until someone outside the company can check it.

So ask what evidence exists.

Is there a SOC 2 report you can read under NDA, or just a badge on the website? Is there a penetration-test summary? Can anyone inspect the code?

Article 28(3)(h) requires processors to provide information needed to demonstrate compliance and to allow for audits, subject to the terms and conditions of the agreement.

That changes the conversation. If the contract gives you audit or information rights, the vendor has to explain how those rights work rather than close the subject.

Where a free tier's money comes from

Buyers often treat the price as the warning sign, so this is worth looking at from another angle.

If a vendor isn't making money from you, it's making money somewhere.

Maybe investors are funding growth. Maybe the plan is to move you onto a paid tier. Maybe your data helps train their models. Or maybe the software is cheap to run because the expensive computing happens on your own hardware instead of theirs.

All four are legitimate business models.

The important difference is what you can actually verify. The last one is a fact about how the software works. The other three depend on a business model that can change with the next funding round.

How to check: ask what an outsider examined

Ask what an outside party has actually examined, and what they were allowed to see.

When the source code is public, anyone can inspect it, including you.

Open source or a brand name

Both can give you something valuable, but they're different kinds of guarantees.

A large, established vendor can give you indemnity, a support contract, a compliance team, and a company you can hold accountable.

Open source gives you something different: the ability to inspect the code, self-host the whole thing, and keep running the software even if the company behind it disappears. If your requirement is that meeting data never leaves infrastructure you control, that's an Enterprise conversation.

Your procurement process probably already tells you which of those matters more to your organization.

What's worth questioning is choosing the first while getting none of the second, especially when the data is this sensitive and the vendor's claims are this difficult to verify.

We have comparison pages for Granola, Fireflies, Otter.ai, Read AI, Zoom AI, Microsoft Copilot, Fathom and ChatGPT record mode. The wider argument is on our open source page, and the sourced incidents are in Are AI Meeting Assistants Safe?.

Running the checklist on Meetily

It would be a pretty poor checklist if we left ourselves out of it.

1. Where does the audio go? Nowhere. Transcription runs on your device with Whisper.cpp.

How you'd check it: run the network-off test from question 1.

2. Is your content used for training? Not by us. We never receive it. If you point summaries at a cloud model with your own key, whether that provider trains on the transcript is governed by their terms, not ours.

How you'd check it: run the same test for us. For the provider you chose, read their API terms.

3. Whose model is it? Both editions can run summaries on a local model on your machine. Both can also use a cloud provider with your own API key if you'd rather.

How you'd check it: check which model you have configured. On a local model, nothing leaves the machine. On a cloud model you chose, the transcript text goes to that provider, never to us.

4. Who else can read it? No bot joins the meeting. We don't hold your transcripts, so our support team can't read them. In Community, no subprocessor handles your meeting content.

How you'd check it: check the participant list and inspect the code.

5. Can anyone outside the vendor confirm it? The code is public and MIT licensed.

How you'd check it: inspect it on GitHub(opens in new tab).

Question 3 is the one where we have something to disclose.

Meetily Community is free and MIT licensed. Meetily Pro is $10/user/month billed annually. On both, transcription always runs on your machine, and both default to an on-device model for summaries as well.

Both also let you point summaries at a cloud provider using your own API key. If you do that, the transcript text goes to the provider you chose, under that provider's terms. The audio doesn't. And it doesn't go to us. But the transcript does leave your machine.

We're spelling that out because it is the honest answer to our own question 3, and because a checklist that told you to test a vendor's claims would be worth nothing if ours were written to survive the test rather than to be true.

See /free, /pricing, what actually leaves the device, and the Pro privacy terms.

What to do next

Run the checklist on whatever you're evaluating, and run it on us too.

If you want the method applied across the whole field, we keep a roundup of privacy-focused meeting transcription tools. If you'd rather just test the local-processing claim yourself, Community is free. Pro has a 14-day trial with no payment required, which is worth using if you want to run the network-off test against the API-key path as well, since that's the one setup where anything leaves your machine.