Confidential meeting transcription for board, M&A, and strategy meetings
For meetings where the answer to "should we let a third party hear this?" is "no". Keep the recording, transcript, and search on the device. No vendor meeting bot. No upload to a cloud provider. Just the browser, your microphone, and a local transcript you control.
On your device
When to keep transcription on-device
Use on-device for boardroom conversations, M&A discussions, exec strategy sessions, and anything where the default "send it to a meeting bot" workflow is the part that worries the legal team.
The technical claim is narrow on purpose: the recording and transcript live in the browser workspace on the current device. They don't leave unless you explicitly choose to export, back up, send to a BYOK provider, or switch to a cloud provider.
That's a workflow, not a compliance certificate. Whether it satisfies your policy is a call your security team makes. Keeping transcription on-device just gives them a much smaller surface to evaluate.
How it works on your device
- Open jotty.pro on the device approved for the meeting.
- Keep transcription on-device for the recording and transcript.
- Review the transcript before generating any summary or export.
- If your policy allows it, send only selected passages to a BYOK provider.
- Keep cloud providers off for this workflow until your team has signed off on cloud transcripts.
With your own cloud key
If your security team has already approved a transcription provider, jotty.pro routes audio to that provider under your own API key. Transcripts come back and stay on the device, in local DuckDB. We never see them.
When a cloud provider is the right call
Use a cloud provider when your organization already trusts one of OpenAI, Groq, Deepgram, Google, Mistral, X.AI, HuggingFace, DeepSeek, or Ollama, and wants the speed, accuracy, or speaker diarization those providers offer on long board, M&A, or strategy calls.
The tradeoff is real: audio leaves the device. It only goes to the one provider your IT team configured, under that provider's terms and data-processing agreement. We don't provision or hold enterprise keys. Your IT issues the key, you paste it in, we route requests through it.
Transcripts persist locally in DuckDB on the current device. That part doesn't change whether you stay on-device or send audio to a cloud provider.
How it works with your key
- In onboarding, pick a cloud provider and paste the API key your IT issued.
- Start the recording in the browser. Audio is captured on the device.
- We send the audio to your configured provider for transcription under their terms.
- Ask for a summary or action items: same provider, or a different approved one per task.
- The finished transcript writes to local DuckDB on the device. No copy hits our servers.
How it compares
| Option | Where audio goes | Whose terms apply | Key custody | Where the transcript lives |
|---|---|---|---|---|
| Cloud meeting bots (Otter, Fireflies, etc.) | Vendor infrastructure | The vendor's | Vendor-held | Vendor servers |
| Hardware recorder + manual transcription | Device, then wherever you ship the file | Whoever you ship it to | Your team | Wherever you store the file |
| jotty.pro on the device | Nowhere: it stays on the device | Yours only | No key needed | Local DuckDB on the device |
| jotty.pro with your cloud provider key | Only your chosen provider | That provider's DPA | Your IT or the individual | Local DuckDB on the device |
Honest answers
Can we prove the local workflow during a security review?
Yes. Your security team can inspect the browser session directly and decide what gates to require before allowing BYOK, export, backup, or any cloud-provider action. The on-device path is small enough to reason about in one sitting.
Should every confidential meeting default to on-device?
On-device is the safer default when content is sensitive, but the bigger questions (whether to record at all, what consent the participants need, who's allowed to attend) still belong to your organization. We just narrow the technical question to "where does this content live?"
What if we need the transcript on another device later?
That's a cloud-provider or export decision, not an on-device one. Don't switch this workflow to a cloud provider until your team has reviewed the Privacy Policy, Terms, and any internal approval requirements for cloud transcripts.
Why route confidential meetings through a cloud provider at all?
Because your security team has probably already done the diligence on one or two transcription providers, and refusing to use them means people fall back to whatever's convenient. Using your approved provider lets you keep that relationship and still keep the transcript local. The audit story is short: "transcripts live on the device, audio touches one named provider under our DPA."
How do we prove the workflow during a security review?
The team inspecting the workflow can confirm which provider key is configured and review that provider's DPA directly. The transcript boundary is the same either way: transcripts persist in DuckDB on the device, not on our servers. Everything beyond that is the provider relationship you already control.
What if our provider changes its terms mid-engagement?
Swap the key for a different approved provider, or fall back to on-device transcription for that meeting type. You're not locked in. Nine providers are supported, so a terms change at one vendor doesn't strand the workflow.