BYOK cloud transcription for confidential meetings - your provider, your 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
- 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 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
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.
Need the strongest posture, where audio stays on the device end to end? Use on-device transcription for that meeting and pick a cloud provider per call when your security team has signed off.