You're probably here because you already wrote the sentence. Somewhere in your IRB protocol — or the informed consent form your participants signed — is language close to "audio recordings will be stored on a password-protected device, accessible only to the principal investigator and named research personnel." You wrote that before AI transcription was a normal part of the workflow, and now you're looking at a transcription tool wondering whether feeding your interviews into it quietly breaks a promise you already made to your ethics board.
That's a reasonable thing to wonder, and the honest answer is: it depends on where the audio actually goes, not on what the product page says. What follows is what data-handling clauses in IRB protocols typically require, why routing audio through a cloud AI service creates real friction with those clauses even when the vendor means well, and a concrete list of questions to put to any transcription tool — ours included — before you build a multi-year study on top of it.
What your protocol actually commits you to
IRB data-handling sections aren't usually vague. Boards work from templates, and the clauses that matter here tend to be specific and checkable, not aspirational.
Storage location. Most protocols name where recordings and transcripts live — an encrypted institutional drive, a password-protected laptop, a specific departmental server. "Somewhere in the cloud" is rarely what got approved.
Access restricted to the research team. Consent forms typically promise that only the PI and named study personnel — sometimes listed by name in the protocol itself — will have access to identifiable recordings. This is usually the tightest constraint, and the one most likely to be violated without anyone intending to.
Retention period. Funders and institutions commonly specify a retention window — a few years past publication is typical, though the exact number comes from your funder's data management plan, not a universal rule — after which recordings should be destroyed, not archived indefinitely.
Third-party access. Most protocols are silent on "AI vendor" specifically, because they were written before that was a live question. But they're rarely silent on third-party access in general. If your consent form says data won't be shared beyond the study team, a transcription vendor is a third party — regardless of whether the party in question is a person reading a transcript or a server processing it.
Why cloud transcription creates a technical compliance gap
Here's the mechanism, stated plainly: the moment an audio file leaves your device — whether it's headed to a general-purpose API, a dedicated transcription SaaS, or the AI feature built into a QDA tool you already own — it is, for some window of time, on infrastructure the study team doesn't control and can't fully audit. That's true even for vendors with genuinely good privacy practices.
"We don't retain your data" is a common vendor claim, and it may well be accurate. It's also not something you can hand to an IRB as evidence, because it's a policy statement, not a technical guarantee your board can verify. Your protocol likely promised access limited to named research personnel; a cloud vendor's servers, request logs, and — for API-based transcription — the underlying model provider's own infrastructure are all, technically, additional parties that touched the data, even if only for milliseconds and even if no human ever looks at it. Whether that counts as a protocol violation is a judgment call your IRB gets to make. It isn't the vendor's call, and it isn't yours either.
None of this is a knock on any specific product. It's just how client-server architecture works: a cloud AI feature involves, by definition, a server that isn't yours. If your protocol's promise was specifically about devices and named personnel, cloud processing sits in tension with that promise no matter how carefully the vendor's retention policy is worded.
A representative example of the kind of clause under discussion here, drawn from common IRB template language: "Digital recordings will be stored on an encrypted, password-protected device and will be accessible only to the principal investigator and listed study personnel. Recordings will be destroyed [N] years after study completion."
Read that clause literally, and it's easy to see why "we ran it through an AI transcription API" is a harder sentence to say out loud in a continuing review meeting than "we ran it on the laptop named in the protocol."
A checklist for evaluating any transcription tool under IRB review
Whatever tool you're considering — again, ours included — these questions are specific enough to actually test. Vague reassurance doesn't survive them.
- Where does the model run? On your device, or on a server the vendor operates? Ask for the specific answer, not "we take privacy seriously."
- Does audio or text ever leave the device, even transiently? "We don't retain it" is a retention claim. "It never left" is a transmission claim. Those are different questions, and only the second one determines whether your access clause held.
- Can you turn the network off and run the full pipeline? Transcription, speaker separation, coding — if a tool works with wifi disabled, that's demonstrable evidence, not a policy you have to trust.
- Can you see network activity while it runs? A visible indicator that shows outbound connections, or the lack of them, is something you can screenshot for a protocol amendment. A privacy policy is not.
- Does the vendor call a subprocessor? A lot of "AI transcription" products are a thin interface over someone else's API. Ask directly whether your data touches a fourth party you haven't heard of, and get the answer in writing.
- What does deletion actually mean? "No longer visible in your account" and "destroyed from all systems, including backups" are different claims. Ask which one you're getting.
None of these questions require you to understand machine learning. They require a vendor willing to give you a specific, falsifiable answer instead of a comforting one.
What local processing doesn't solve
Here's the part that's easy to oversell, so we won't. Running transcription entirely on your own machine answers exactly one question: does the audio leave the device. That's an important question, and for a lot of protocols it's the one actually creating the blocker. But it's one axis of IRB compliance, not the whole of it.
Local processing does nothing, by itself, about the exact wording of your consent form, your institution's data retention and destruction schedule, whether de-identified excerpts can be shared for secondary research, or your breach-notification obligations if a laptop goes missing. It also doesn't retroactively cover you if your original consent form named a specific piece of software — switching tools mid-study, even to a more private one, is usually a protocol modification your IRB needs to see, not a call you get to make on your own.
So: a tool that keeps processing on-device removes the "did this cross to a third party" problem. It does not make a study IRB-compliant by itself, and any vendor telling you otherwise is overselling. Compliance is a determination your board makes about your specific protocol; the tool you choose is one input to that determination, not a substitute for it.
This is the specific gap Sondera's architecture is built around: transcription, speaker diarization, and AI-assisted coding designed to run entirely on-device, with a network activity indicator that's visible rather than promised — so "no data left the machine" is something you can demonstrate live in front of a committee, not a line you're asking them to take on faith from a privacy policy. It's not available yet: Sondera is in development for macOS, with a beta planned for fall 2026, and it won't write your consent form or set your retention schedule for you. It's aimed at making one specific, common blocker checkable instead of merely promised.
Building toward local-first, AI-assisted coding.
Sondera is in development for macOS — beta fall 2026. Join the waitlist for early access and pricing.