Meeting bot vs on-device note taker: how the data security differs for interviews
On this page
- How do the two capture methods reach the conversation?
- How do they compare on data security?
- What are the specific risks of a meeting bot?
- What are the specific risks of an on-device note taker?
- Does "no bot" mean the data stays on your computer?
- Which questions decide the security answer?
- Which should a recruiting team choose?
- Questions people ask
A meeting bot is a participant run on the note-taker vendor's servers: it joins the call through the meeting link, usually found through a calendar connection, and the meeting's audio (often video, screen shares and chat too) flows straight into the vendor's cloud. An on-device note taker is an app on the interviewer's computer that captures the microphone and the computer's sound, so nothing joins the call; the security questions move to that app's permissions on the laptop and to where it sends audio and transcripts. Neither is safer by default. What decides it, as of October 2026, is where audio is processed, where the transcript is stored, who can start a capture and who can delete it.
This page compares the two from a security reviewer's seat, with vendor and platform facts linked. How each method works is explained in what is a meeting bot and what is a bot-free AI note taker.
How do the two capture methods reach the conversation?
Meeting bot
- The user connects a calendar. Otter, for example, says its Notetaker needs a connected Google or Microsoft calendar to join automatically (Otter help).
- The vendor reads meeting links from the calendar and sends a bot to the call at start time.
- The bot joins as a participant from the vendor's infrastructure, which may itself be a subprocessor: Greenhouse names Recall.ai as the provider of "the recording bot and transcription service" for Greenhouse Notetaker (Greenhouse FAQ).
- Everything the bot receives is processed and stored outside your network.
On-device note taker
- The user installs an app and grants it access to the microphone and to system audio.
- The user starts capture on the computer the call is running on. Granola says it must be started manually and "won't auto-join or auto-record anything" (Granola security).
- The app records the two audio streams locally, then usually sends audio to a speech-to-text service and stores the transcript somewhere: on the device, in the vendor's cloud, or both.
How do they compare on data security?
| Security question | Meeting bot | On-device note taker |
|---|---|---|
| What gets access, and how | A vendor account with calendar access and the meeting link. Anyone who has the link and a bot service can try to send one. | An app with operating-system permission to the microphone and system audio on one computer. |
| What it can capture | Whatever the platform sends a participant: audio and often video, screen shares and chat. Otter lists Automated Slide Capture among its Notetaker features (Otter overview). | Audio from the microphone and the computer's output; video and screen content only if the app also records the screen. |
| Who can start a capture | Often a calendar rule rather than a person. Otter's "Meetings with a video link" setting joins "all calendar events with a valid Zoom, Google Meet, or Microsoft Teams meeting URL", and Otter says you can send Notetaker to a meeting you cannot attend. | The person at the keyboard, usually by pressing a button for each call. |
| Where audio is processed | Always on the vendor's or its subprocessor's servers. | On the device first; most apps then send it to a cloud speech-to-text provider. Granola names providers "like Deepgram and Assembly". |
| Where the output is stored | Vendor cloud. Greenhouse deletes Notetaker recordings after 30 days by default and keeps transcripts and notes (Greenhouse help). | Varies. Granola keeps no audio and stores transcripts and notes in a US-hosted AWS environment; Fireflies' no-bot mode saves no audio or video files but puts the transcript in its web dashboard (Fireflies guide). |
| Admin control | Meeting platform policies. Microsoft Teams detects external bots and, by default, holds them in the lobby until admitted (Microsoft Learn). | Device management: which apps may be installed, and operating-system permission prompts. Nothing in the meeting platform sees it. |
| Visibility to the candidate | A named participant tile, such as "Greenhouse Notetaker". | None. The interviewer has to say it out loud. |
| Main failure | A bot joins a call nobody meant to record, or keeps a copy outside your compliance boundary. | An app with broad device access, a lost laptop with local transcripts, or a capture nobody announced. |
What are the specific risks of a meeting bot?
- It joins by rule, not by decision. Calendar-driven auto-join is convenient for sales calls and risky for interviews, offer calls and HR conversations that happen to carry a video link. Check the default in every recruiter's account.
- It can attend without its owner. A bot sent to a meeting the user skips records people who never spoke to the person whose account it is.
- It receives more than audio. A candidate who shares a screen to walk through a portfolio or code exercise may put personal or third-party material in front of the bot.
- The data leaves your boundary by design. Microsoft's own admin page lists the concern that external bots may "store meeting data in third-party systems outside of the organization's compliance boundaries."
- The chain is longer than the brand. The bot may be run by an infrastructure provider and the transcript written by another; each is a subprocessor to check.
- Detection is not a wall. Microsoft says "Some external bots may not be detected," so a lobby policy reduces surprise joins rather than ending them.
What are the specific risks of an on-device note taker?
- It needs deep device permissions. On a Mac, apps that capture system audio need the Screen & System Audio Recording permission in Privacy & Security, and Apple notes that what third-party apps collect "is governed by their terms and privacy policies" (Apple Support). On Windows, Microsoft says privacy settings "don't control how desktop apps access personal data on your device" (Microsoft Support). Installing the app is a trust decision about the vendor.
- Local copies live on a laptop. If transcripts stay on the device, the laptop's disk encryption, screen lock, backups and offboarding process become your retention controls.
- Central oversight is thinner. A meeting platform can show who admitted a bot; it cannot see an app capturing audio on someone's computer. Your control is the approved-software list.
- Consent depends entirely on the interviewer. No participant tile appears, so if the interviewer skips the notice, nobody else on the call knows.
- "No bot" can still mean "cloud". Most desktop tools upload audio for transcription and store transcripts with the vendor, so ask the same storage questions you would ask of a bot.
Does "no bot" mean the data stays on your computer?
Usually not. The capture happens locally; the processing and storage often do not. Granola transcribes in real time without storing audio but keeps transcripts and notes in its cloud. Fireflies' desktop mode saves no audio or video files, yet the transcript appears in its web dashboard. Both are reasonable designs; neither is "local only".
Tools differ on exactly this point, so ask for the data flow in writing. As one example, we make Interview Signal, a Windows and macOS desktop app that captures audio on the interviewer's computer with no bot, keeps transcripts, quotes, candidate names, notes and submittals on that computer, sends audio to a speech-to-text provider in short chunks during the call without retaining it, and keeps only counts and durations on its server. Any vendor, including us, should be able to show you that flow on its security page. Tools that keep no recording at all are compared in AI note takers that don't store audio.
Which questions decide the security answer?
The capture method is one row in a security review, not the review. These eight questions settle most cases; the full version is the AI note taker security questionnaire.
- Where is audio processed, and by which named provider?
- Is audio kept, by the vendor or the provider, and for how long?
- Where are transcripts and summaries stored: device, vendor cloud or both, and in which country?
- What starts a capture: a person pressing a button, or a calendar rule?
- What is captured beyond audio: video, screen shares, slides, chat, participant names?
- What access does it need: calendar scopes, email, device permissions?
- Who can delete one candidate's data, and does deletion reach backups and subprocessors?
- Does the vendor train models on it? Policies by vendor are in do AI note takers train on interview recordings.
Which should a recruiting team choose?
| If your main concern is... | Lean toward | Why |
|---|---|---|
| Central admin control and one retention policy | A bot or the meeting platform's own AI notes, under admin policy | Recordings sit in one tenant or vendor account where retention and deletion can be enforced. |
| Keeping copies out of third-party clouds | An on-device tool that stores output locally and keeps no audio | Fewer stored copies, fewer places to answer a deletion request. |
| Candidates or clients who object to bots | On-device | No participant joins, but you must say the notice yourself. |
| Phone screens | On-device, if the call runs through the computer | A bot needs a meeting link; a desktop app can hear a softphone. |
| Interviews with screen sharing of sensitive material | Audio-only on-device capture | Less captured means less to protect. |
Whichever you choose, consent does not change: recording and transcription rules attach to the conversation, not to whether a bot is visible. The wording to use is in the interview recording consent script, and where each kind of tool stores data is mapped in where AI note takers store interview data.
Not legal advice. Vendor and platform facts are from the linked pages as of October 2026 and change often.
Questions people ask
From a data-security standpoint, how do note takers that join as a bot differ from ones that capture audio on the device?
A bot runs on the vendor's servers, joins the meeting as a participant through a meeting link it usually finds via a calendar connection, and receives the meeting stream directly into the vendor's cloud. A device-based note taker is an app on the user's computer that captures the microphone and system audio, so nothing joins the call; the risk moves to the app's permissions on that computer and to wherever it sends audio and transcripts. Neither is safer by default: compare where audio is processed, where transcripts are stored, who can start capture and who controls deletion.
Is an AI note taker without a bot more secure?
Not automatically. Removing the bot removes a participant that can be auto-invited to meetings and that sends the stream to a vendor server, but most device-based apps still send audio to a cloud speech-to-text service and store transcripts in the vendor's cloud. Ask where audio goes, whether it is kept, and where the transcript lives before deciding.
Can IT block AI note-taker bots from interviews?
Partly. As of October 2026, Microsoft Teams detects external bots by default and holds them in the lobby until an organizer admits them, though Microsoft notes some bots may not be detected. Hosts on other platforms can use waiting rooms and remove bots from the participant list. Device-based apps are controlled differently, through software approval and device management on company computers.
Which AI note takers for job interviews work without a bot?
Desktop apps that capture the computer's audio, such as Granola and the Fireflies desktop app's recording-without-a-bot mode, as of October 2026, plus recruiting-specific desktop tools. They need the interviewer to run the app on the computer the call is on, and the interviewer still has to tell the candidate the call is being transcribed.