IRB-compliant transcription: the checklist for ethics applications

What IRB reviewers actually ask

IRBs do not "approve AI" in the abstract. They assess whether a specific study's data flow protects participants, matches the consent form, and aligns with the institution's data-management policies. When AI transcription is in the workflow, the questions are predictable and you can prepare answers in advance.

The list below comes from a synthesis of published IRB guidance documents at U.S. and Canadian universities. Different boards weight the questions differently, but the same dozen show up everywhere. If your transcription tool cannot answer all of these in writing, the IRB review will stall — usually with a request to "describe the AI tool's data-handling practices in more detail," which is the polite version of "your application is incomplete."

• Where is the audio physically processed? Country, region, on-device.
• Who has access to the audio and transcripts? Vendor employees, sub-processors, no one.
• Is participant audio used to train the vendor's models? Yes, no, opt-out.
• How is data encrypted? In transit, at rest, both, neither.
• Can audio and transcripts be deleted on demand? Within how long?
• What is the default retention period? Configurable per project?
• What sub-processors receive the data? Listed publicly?
• Is a Data Processing Agreement available?
• Is a Business Associate Agreement (BAA) available for HIPAA-covered work?
• Does the vendor have SOC 2 Type II or equivalent certification?
• How are participant identifiers (names, locations) handled in the transcript?
• What is the breach-notification policy and timeline?

Data residency, processing location, and access control

IRBs care about data residency because some research populations and protocols require it. EU participants under GDPR need data processed in the EU or in a country with equivalent privacy protections. Indigenous research often has data-sovereignty requirements that limit cross-border data flow. Health-related research crosses HIPAA jurisdictional lines if data leaves the U.S.

The honest answer for most cloud transcription vendors is: data is processed wherever the vendor's compute is, which is usually U.S. data centers, occasionally with EU options for paid-tier customers. If your study has residency requirements, ask the vendor before signing. If they do not have a clear answer, the answer is no.

Access control is the second piece. Participant audio should be accessible only to authorized study personnel and, where unavoidable, the vendor's automated transcription pipeline. Vendor employees should not browse customer audio for any reason. Look for written policies that name role-based access and audit logging — the absence of these documents is a signal, not an oversight.

Training on user data: the showstopper

The single most disqualifying answer in an IRB review is "yes, the vendor uses participant audio to train their models." Some IRBs categorically reject this; others require explicit participant consent, which makes the consent form harder to write and the participant pool smaller. Either way, training on user data should be considered a hard no for any researcher-facing tool.

The good vendors say "we do not train on your audio" plainly, on a public page, with no qualifying language. The mediocre vendors say "we do not use your audio for training, except as needed to improve service quality." That hedge is a problem. "Improving service quality" is a back-door for training, and an IRB reviewer will catch it.

The straightforward way to evaluate a vendor on this dimension is to ask for a written statement, signed by an officer of the company, that says "Customer audio is not used to train any AI model, period." Vendors who provide this are safe; vendors who refuse or hedge should be eliminated from the evaluation.

Encryption, retention, and deletion

The technical baseline is uncontroversial in 2026 and any vendor below it should not be considered. TLS 1.2+ in transit, AES-256 at rest, encryption keys managed by the vendor or (for higher-tier customers) by the customer. Encrypted backups. No plaintext audio in any ops dashboard.

Retention is more nuanced. The default 30-day auto-delete that several vendors offer is reasonable for most research, but IRB protocols often specify a longer retention (study duration plus a holding period) or a shorter one (post-publication wipe). The right tool exposes a per-project retention setting; the wrong tool has a single account-wide default.

Deletion-on-demand is the participant-rights piece. If a participant withdraws, you have to delete their data, including the audio recording, the transcript, and any embedding or voiceprint extracted from it. The vendor's tool needs to support a single-click delete that propagates across the entire data lineage. Tools that only "soft-delete" or that retain embeddings after audio deletion fail this test — embeddings are participant data.

Anonymization workflows

Most published qualitative research uses pseudonyms in the final transcript and the manuscript. Some studies — particularly health and education research — require anonymization at an earlier stage, before any analyst other than the PI sees the transcript. The transcription tool needs to support this workflow without forcing the researcher to do it manually in a Word document.

Functional requirements: detect and replace names, organizations, locations, and any custom identifier list (school IDs, hospital codes) with placeholders ([NAME_1], [SCHOOL_1], etc.). Do this in a way that preserves the within-transcript consistency — the same name should always become the same placeholder, so the analyst can still track "what did P3 say" through the transcript even though they do not know P3's real name.

One-click anonymize is the user-experience expression of all of this. Open the transcript, click anonymize, get a redacted version that preserves the analytic structure. Tools without this feature force researchers into manual find-replace passes that are error-prone — the kind of work where missing one instance of a name in a 90-minute transcript can compromise the anonymization promise to the participant.

Documentation that copy-pastes into ethics applications

The best IRB-friendly transcription tools maintain a public documentation page specifically for ethics applications. The page reads like a checklist of the questions reviewers ask, with answers in plain language, dates of last update, and links to the underlying policies. Researchers can copy-paste the relevant sections directly into their ethics application's data-management plan without rewriting.

If the tool does not have such a page, the workaround is to assemble the answers yourself from the privacy policy, the security page, the BAA template, and any sub-processor list. That is a several-hour exercise per study and the result is usually incomplete because vendor documentation is fragmentary by default.

Jurisdictional differences: US, EU, Canada

The IRB checklist applies broadly, but the specific weights and required documents shift by jurisdiction. US IRBs operating under the Common Rule focus on consent forms, data security, and breach notification — the BAA is critical only when PHI is involved. EU research under GDPR adds explicit data-residency requirements and the right to be forgotten — even non-clinical research has stronger deletion-on-demand requirements than US studies typically face.

Canadian REBs operating under the Tri-Council Policy Statement (TCPS 2) emphasize Indigenous data sovereignty for any research involving Indigenous communities — that adds a layer beyond standard privacy requirements, often requiring data to remain in Canadian jurisdictions and under community oversight. Researchers working with Indigenous participants should not assume a US-based vendor is compliant; verify residency and access policies explicitly with the vendor before recruiting.

For cross-border research (a US researcher interviewing EU participants, for example), the stricter jurisdiction's rules apply to the data they cover. EU participants' audio cannot be processed under US-only data flows even if your institution is US-based. The cleanest path through this is choosing a vendor with multi-region processing and an explicit data-residency option per project — set the project's region to match the participant pool, not the institution.

The 11-question checklist

Before settling on a transcription vendor for a research study, run through these eleven questions with the vendor. If any answer is "no," "we are working on it," or "not publicly," document that gap in your data-management plan and explain why the residual risk is acceptable. If three or more answers fail, pick a different vendor — the residual-risk argument is not worth the IRB friction.

1. 01Is participant audio processed only in regions our protocol permits?
2. 02Does the vendor publish a written no-training-on-user-data guarantee?
3. 03Is encryption at rest AES-256 and in transit TLS 1.2+?
4. 04Can retention be configured per project to match our IRB-approved window?
5. 05Does delete-on-demand propagate to embeddings, voiceprints, and backups?
6. 06Is the sub-processor list public and current?
7. 07Is a Data Processing Agreement available?
8. 08Is a BAA available if our work covers PHI?
9. 09Does the vendor hold SOC 2 Type II or an equivalent attestation?
10. 10Is a one-click anonymization workflow available for transcripts?
11. 11Is there a public IRB documentation page we can cite in our application?