Security
Your IT policy blocks cloud transcription. Now what?

Dylan de Heer
The request comes back rejected and the reason is one line: no third-party cloud transcription.
You are not being told the tool is bad. You are being told that sending recordings of internal conversations to a vendor's servers is outside what the organisation has agreed to carry. That is usually a correct decision, and arguing with it directly rarely works.
What does work is understanding what the policy is actually protecting against, then bringing back an option that does not trigger it. There are four, and only two of them survive a strict reading.
What IT is actually blocking
"No cloud transcription" is shorthand. Underneath it there are usually four separate objections, and they have different answers.
A new data processor. Every vendor holding your recordings is another entry on the processing register, another agreement to negotiate, another breach notification path. For a small security team, the cost of onboarding a vendor properly is often higher than the value of the tool.
Data leaving the jurisdiction. If the vendor stores in the United States and you are in the EU, someone has to justify the transfer. For a vendor certified under the EU-US Data Privacy Framework that rests on the adequacy decision rather than on standard contractual clauses, and the framework itself is under appeal at the Court of Justice. Either route is real work, and neither is free.
Training on the content. Otter trains on de-identified meeting content by default, with the opt-out sitting in an individual user's account settings. Most of the other well-known notetakers publish the opposite position, so this is a per-vendor question rather than a category assumption. Either way, a setting in one employee's account is not a control the organisation can evidence.
The bot in the call. A recording participant that appears in external meetings creates a consent problem with people who are not your employees, and in some sectors that alone is disqualifying.
Notice that only the second and third are about the cloud specifically. If you come back with a tool that answers all four, you are not asking for an exception. You are removing the reason for the rule.
The four options, ranked by how far they get

1. On-device processing
The recording, the transcription and the summary all happen on the machine that is already trusted and managed. No meeting content is uploaded, so for that content there is no processor, no transfer, no training question and no bot.
This is the only option that removes all four objections rather than mitigating them. For IT it is also the cheapest to approve, because approving it does not mean approving a vendor's security posture. It means approving an application on a managed endpoint, which is a process the organisation already has.
The catch is platform coverage. The mature on-device tools are Mac-first, which matters if your fleet is mixed.
2. Self-hosted or open source
Run the transcription and summarisation stack on infrastructure you control. Your security team can audit every part of it, and nothing leaves the network.
This is the strongest option on paper and the hardest in practice. Someone has to run it, patch it and answer for it when it breaks. If you have a platform team with capacity, this is excellent. If "IT" is one person who also manages laptops, proposing it will not help you.
3. The platform's own assistant
If you already run Zoom, Microsoft 365 or Google Workspace, their built-in assistants sit inside a vendor relationship the organisation has already assessed. No new processor, no new agreement.
This is usually the fastest approval in the building, and it is often the right answer. Its limits are real: it works only inside that platform, so an external client on a different tool leaves you with nothing, and the host controls whether it runs at all.
4. A cloud notetaker with an enterprise agreement
A dedicated vendor, procured properly: data processing agreement, regional hosting, training disabled contractually rather than by a checkbox, SSO and audit logs.
This works, and for a large organisation it is often the outcome. It is also the slowest and the most expensive, and it is precisely the path your policy already declined once.
What to bring back to IT
If you are going to make the request again, make it answerable. A security reviewer cannot approve "it's private". They can approve specific claims they are able to verify.
Bring these:
Where does audio get processed, exactly? On the endpoint, or on a server? If a server, whose and where?
What is transmitted, and when? Some tools capture locally and upload for processing, which is not the same as local. Ask what leaves the machine and at what point.
Is meeting content used to train models? Ask whether the answer covers the vendor's own models and the model providers it calls. Those are different sentences.
What is retained, and for how long? Retention is what turns a processing step into an archive.
Does anything join the meeting? A visible participant changes the consent position for external attendees.
What is the deletion path? Who can delete what, and can the organisation compel it?
What certifications exist, and what do they cover? A SOC 2 report has a scope. Ask for it rather than the badge.
Question 7 deserves a warning, because it cuts both ways. On-device tools frequently do not hold SOC 2 or ISO 27001, and a reviewer who treats certification as the only acceptable evidence will reject the architecturally safest option while approving a certified vendor that trains on your content. Certification tells you a company has controls. It does not tell you your recordings stay on the laptop. Both facts matter, and they are not substitutes.
What the options look like in practice
Weeve is the on-device option on a Mac. Recording, transcription, speaker labels and the summary all run on the machine, so there is no upload step and no cloud copy. It captures the Mac's own audio, which means it works in Zoom, Teams and Google Meet without a bot joining and without the host enabling anything.
For a security review, the useful property is that there is nothing to review on the vendor side of the boundary: no meeting content reaches a server, so there is no processor agreement covering meeting content, no data transfer to justify and no training policy to constrain. Weeve does use online services for sign-in, billing, updates, downloads and content-free analytics, in the way most desktop software does. The downloads matter for a reviewer: the local models are fetched on first run. That is the honest scope of the claim.
Three limits worth stating before you propose it. It is Mac only and needs Apple Silicon, with no Windows client and no mobile app, so a mixed fleet and any remaining Intel Macs need a second answer. The free Starter plan is capped at 10 recordings a month and 2 projects, which a single team will reach during a pilot. And it is not SOC 2 or ISO 27001 certified, so if your process requires a certification rather than an architectural argument, it will not clear that bar on its own.
Meetily is the self-hosted and open-source option. It records, transcribes and summarises on your own machine, it is MIT licensed, and your engineers can read the source rather than trust a claim. Run with a local model it is fully local; it can also be pointed at an external API if you configure it that way, which is a thing to standardise before rollout rather than leave to each user. The same applies to any on-device tool: Weeve fetches its models on first run, so the egress a reviewer should ask about is the download, not the meeting. It runs on macOS and Windows, with Linux built from source, and its setup expects Node.js, Python and FFmpeg to be present.
Zoom, Microsoft and Google are the incumbent-vendor option. Worth knowing for the review: Zoom's terms state it does not use customer content, including audio, video and chat, to train its own or third-party AI models. Microsoft publishes an equivalent commitment for Copilot, that prompts, responses and Graph data are not used to train the foundation models, and operates an EU Data Boundary that speaks directly to the jurisdiction objection. Google commits not to use customer data to train generative models without permission. None of that makes the platforms unusual: the dedicated notetakers below publish comparable positions. It does mean the platform assistant is an easier approval than people expect, because the paperwork already exists. The limits are platform lock and host control, not training.
Jamie, tl;dv and Fireflies are the procured-vendor option if the organisation decides a cloud tool is acceptable with the right paperwork. Jamie states that storage and processing stay within the EEA, Switzerland and the UK, that audio is deleted after transcription, and that data is never used for training by it or its model providers, and it holds ISO 27001. tl;dv states its data centres are in Europe, that no customer data trains its AI, and it holds SOC 2 Type II; privately hosted AI is available on request, and the AI hosting region itself is a choice between Europe and the US, which is worth pinning down in writing. Fireflies states a zero-day retention policy means meeting data is not used to train internal or external AI models, imposed contractually on its own vendors, offers storage in a location of your choosing on Enterprise, and holds SOC 2 Type II and GDPR compliance with a HIPAA business associate agreement available. All three are still processors, and all three will need the agreement your policy asked for.
A short honest note about "bot-free"
Several vendors market bot-free recording as a privacy feature, and it is often presented as though it answers the cloud objection. It does not.
Bot-free means no extra participant appears in the call. The recording is still captured and, in most of these products, still uploaded to the vendor to be transcribed and summarised. tl;dv's own documentation is clear that bot-free recordings are stored in your library. That is a genuine improvement to the consent problem in external meetings, and it is worth having. It is not the same as the audio staying on the machine, and a security reviewer will spot the difference immediately.
If someone brings you a bot-free tool as the answer to a cloud policy, the question to ask is simple: where does the audio go after it is captured?
If the answer has to work on Windows
The honest position is that this narrows considerably. The mature on-device notetakers are Mac-first. Your realistic options are Meetily, which runs on Windows and is open source, a self-hosted stack your platform team runs, or the platform-native assistant you already pay for.
It is better to say that plainly than to propose a Mac-only tool to an organisation that does not run Macs.
The shape of a request that gets approved

Combining the above, the version that tends to clear review looks like this:
Name the specific policy clause you are addressing, rather than asking for an exception to it
State where processing happens in one sentence, and how a reviewer can verify it
Answer the training question explicitly, including whether it covers model providers
Say what leaves the device, including the things that do, like licensing and analytics
Name the limits yourself, before the reviewer finds them
Propose a scope: one team, one quarter, with a review date
The last one matters more than the rest. Security teams say no to permanent, organisation-wide commitments and yes to bounded trials with a date on them.
The tools that are easiest to approve are the ones with the least to explain.
If the shortest version of that explanation is "the audio never leaves the laptop", Weeve's Starter plan is free and runs entirely on the Mac, which makes it cheap to pilot before anyone has to write a policy exception. Try it on a real meeting.
FAQ
Why does IT block AI notetakers?
Usually for four reasons at once: it adds a data processor, it may move data to another jurisdiction, the vendor may train models on meeting content, and a recording bot creates a consent problem with external attendees. A tool that answers all four is not asking for an exception, it is removing the reason for the rule.
What is the difference between on-device and bot-free?
On-device means the audio is processed on your own machine and never uploaded. Bot-free only means no extra participant appears in the call; the recording usually still goes to the vendor's cloud to be transcribed. They are often confused and they are not the same control.
Is there an AI notetaker that works with no account and no cloud upload?
On-device tools come closest. Weeve processes meeting content entirely on the Mac, though it uses online services for sign-in, billing, updates, model downloads and content-free analytics like most desktop software. Meetily is open source and can run fully locally, which is the strongest position if you want no vendor relationship at all.
Can we self-host a meeting notetaker?
Yes. Meetily is open source under an MIT licence and can be run on infrastructure you control, with local models for summaries. The trade is that someone has to own it operationally.
Will an on-device tool pass a SOC 2 requirement?
Often not, because smaller on-device vendors frequently are not certified. This is where reviews go wrong in both directions: certification evidences a company's controls, while architecture determines whether your recordings leave the endpoint at all. If your process only accepts certifications, say so early, because it rules out the architecturally safest options.
Does the platform's own assistant count as cloud transcription?
Technically yes, but it usually sits inside a vendor relationship the organisation has already assessed, which is why it is often the fastest approval. Zoom, for instance, states it does not use customer content to train its own or third-party AI models.
Do we still need consent if processing is local?
Yes. Consent is about recording a person, not about where the file is processed, and in many places the law requires it. There is a fuller breakdown in the guide on whether it is legal to record a meeting.
Can I test transcription quality without installing anything?
Yes. Weeve's free browser-based transcriber produces a transcript from a file without it leaving the page, which is a reasonable way to judge accuracy before asking anyone to approve software.


