On-Device Transcription for Research Interviews and Session Notes

The workflow problem

Qualitative researchers, clinicians, therapists, physicians, case managers, coaches, social workers. A surprising number of professions depend on recording conversations that, by the terms of the professional relationship, cannot leave the device they were recorded on.

This creates an awkward situation with transcription. Transcription is genuinely useful for this kind of work. Researchers need interview transcripts for coding and analysis. Clinicians benefit from session notes that capture more than what got typed up afterward. Therapists sometimes work from transcripts when reviewing a session or preparing for consultation. But the transcription tools that come up first when you search all route your audio through a third-party cloud service, which for confidentiality reasons makes them structurally wrong for this kind of work, regardless of how accurate they are.

The result, historically, has been workarounds. Some people transcribe manually, which is accurate but takes forever. Some people skip transcripts and work from the recording and their notes. Some people negotiate with their institution's IT department for an enterprise service that will sign the right paperwork, which mostly only works at large, well-funded institutions. Some people use cloud services anyway and hope the relevant policies hold.

On-device transcription (the audio never leaving the device) is a direct answer to the underlying privacy problem that drives all of those workarounds. This post is about how that changes the workflow, and how to think about it carefully.

An important caveat up front

On-device processing addresses the privacy concern. It does not, by itself, constitute regulatory compliance. HIPAA, FERPA, GDPR, IRB protocols, institutional information security policies: these each have procedural and documentation requirements that live separately from the technology underneath.

If your work is subject to any of those frameworks, the right move is to take the specifics of on-device processing (what it does, what data is and isn't transmitted, where things are stored) to the person or committee responsible for your compliance and ask whether it meets their requirements. Most of the time the architecture is the part they were actually worried about, and an on-device workflow is easier to get approved than a cloud one. But the approval still has to happen through your institution's process. This post is not legal advice. No transcription app is a substitute for your IRB or your compliance officer.

With that said:

What on-device processing actually means

The distinction that matters for this kind of work is between two things that sound similar but aren't.

"Secure cloud processing" means your audio is transmitted to a server, processed there, and transmitted back. The security claim is about transit encryption, storage encryption, access controls, and the vendor's own practices. Those protections can all be real and still not answer the question of whether the audio should be on someone else's server at all. That's often the underlying policy question.

"On-device processing" means the audio is read by the app on your device, processed by a model that runs on the device's own hardware, and the output is written back to local storage. Nothing is transmitted. The claim is architectural: the server simply isn't in the picture.

For work where the concern isn't "is the vendor trustworthy" but "can this audio leave the device at all," on-device is the answer. The conversation doesn't need to be about access controls or SOC 2 reports or business associate agreements, because the thing those documents are trying to govern (data leaving your possession) isn't happening.

MinuteONE is an on-device transcription app for iPhone, iPad, and Mac. Transcription runs through Apple's on-device speech recognition framework on the Neural Engine. Summarization and extraction of structured information from the transcript run through Apple Intelligence, also on-device. There's no server component to the app. MinuteONE doesn't have an account system, doesn't have a backend, and doesn't transmit anything.

Workflow: research interviews

A common shape for qualitative research: the researcher runs a series of semi-structured interviews, records each one, and transcribes them later for coding and thematic analysis.

The on-device version of that workflow:

• Record the interview on an iPhone, iPad, or directly on a Mac. MinuteONE can do live transcription, with the transcript appearing as the interview happens. That's useful as a sanity check that capture is working. Or record on whatever hardware you've been using and import the file afterward.
• Import the audio to MinuteONE on a Mac to process. The transcript generates locally. A summary and any extracted action items generate locally from the transcript, using Apple Intelligence.
• Export the transcript as plain text, markdown, or PDF. Plain text and markdown import cleanly into NVivo, Atlas.ti, Dedoose, or whatever qualitative analysis tool you use for coding.
• Archive the audio and transcript on the same device, or sync across your devices via iCloud, or export to an encrypted local archive, as your data management plan dictates. Because the tool has no cloud component, the retention policy stays under your control.

What this avoids: the step where you'd otherwise be uploading participant audio to a cloud transcription vendor, with the attendant question of whether your IRB approved that, whether the vendor will sign the right agreements, and what your participants consented to when they agreed to be recorded.

For grad students and early-career researchers specifically, there's a budget dimension too. Institutional cloud transcription services are often billed back to a PI's grant. If you don't have a PI, or the grant doesn't cover it, you're personally paying cloud transcription subscriptions on a stipend. Five dollars, once, is a notably different shape of expense than fifteen dollars a month forever.

One practical constraint worth knowing: imported files top out at two hours. For longer interviews, split the file in QuickTime or Audacity first. That's a separate step, not a MinuteONE operation.

Workflow: clinical and therapeutic session notes

This use case needs careful handling, because the range of practice is wide and the regulatory context varies.

Some clinicians record sessions for their own review, supervision, or note generation, with appropriate informed consent from the client. Those recordings, by the terms of the professional relationship and the governing regulations, should not be on a third-party server. The workflow question is: once you have the recording, how do you turn it into useful artifacts (session notes, review material, supervision prep) without violating that?

On-device processing answers the architectural side of that question. The audio stays on your device. The transcript stays on your device. The summary and any extracted structure stay on your device. You control retention. You control deletion. You aren't dependent on a third party's policies.

What this does not do, and it's important to be specific: substitute for your own compliance work. You are still responsible for:

• Obtaining appropriate informed consent to record.
• Following your licensing board's requirements around session recordings.
• Maintaining appropriate device security (strong passcodes, full-disk encryption, physical access controls).
• Handling retention and deletion per your practice's policy and any applicable regulation.
• Consulting with your practice's compliance officer or legal counsel about whether on-device AI transcription is appropriate for your specific context. In particular, the question of whether AI-generated summaries of session audio should exist at all, and how they should be handled if they do, is not a question that technology answers. That's a practice and policy question.

If those considerations check out, the mechanics are straightforward. Import the recording. Get the transcript and summary. Export what you need. Delete what you don't. None of that crosses the device boundary.

Workflow: medical interviews and case documentation

Similar contours. Physicians, PAs, and other clinicians who conduct patient interviews have legitimate interest in transcription for documentation and review, and equally legitimate concerns about patient data leaving the device.

The architectural answer is the same: on-device processing keeps the audio, the transcript, and any generated structured output on your device. The procedural answer runs through your organization's compliance framework, not through anything an app vendor can unilaterally provide. Most hospitals and clinics have policies about AI tools and patient data that need consulting regardless of where the processing happens.

What's worth noting is that many of those policies were written with cloud transcription services in mind and may treat on-device processing as a materially different category. It's often worth asking the question specifically rather than assuming the default answer.

On exports and retention

One thing that matters more in regulated-adjacent work than it does elsewhere: being able to get your data out, and being able to delete it.

MinuteONE exports to:

• PDF, for archival and sharing
• Plain text, for import into analysis tools, EHRs, or research data management systems
• Markdown, for notes systems or anywhere you want lightweight structure preserved

Deletion is local. When you delete a transcript or a recording from MinuteONE, it's deleted from your device. There's no server copy to coordinate with. There's no vendor to request deletion from. That matches well with retention policies that require verifiable deletion.

FAQ

Does MinuteONE claim HIPAA compliance?

No, and be wary of any app that makes a blanket HIPAA claim. HIPAA compliance is a property of how you use a tool in the context of your covered entity's policies and agreements, not a feature of the tool alone. What MinuteONE provides is on-device processing, which is the architectural property most HIPAA concerns about transcription are actually about. Whether that satisfies your organization's specific compliance program is a question for your compliance officer.

Is it appropriate for qualitative research under IRB approval?

On-device processing is generally easier to get IRB approval for than cloud processing, because it doesn't involve transmitting participant data to a third party. Whether it's appropriate for your specific protocol is a question for your IRB. Bring them the specifics of what the app does and doesn't do.

Is the audio encrypted?

Audio and transcripts are stored on your device, protected by your device's full-disk encryption (on by default on iOS, available via FileVault on macOS). MinuteONE does not add a second layer of app-specific encryption. For most uses this is fine. If your requirements go beyond device-level encryption, your compliance team should be consulted.

What about iCloud sync?

iCloud sync is optional. If you enable it, it uses iCloud's standard sync, encrypted in transit and at rest under Apple's terms. If your compliance framework doesn't permit iCloud storage of the relevant data, leave sync off and use the app in single-device mode. The app works the same either way.

What happens if I stop using the app?

Your data stays on your device. There's no vendor-side retention because there's no vendor side. Export what you want, delete what you don't, uninstall the app. All local.

Does the summary generation work the same way as the transcription?

Yes. Summarization, action-item extraction, and decision extraction all run on-device using Apple Intelligence on the Neural Engine. The transcript is the input, the output is written back locally, and nothing about the summary pipeline involves transmission.

MinuteONE is on the App Store for iPhone, iPad, and Mac. For the broader case for on-device transcription, see the main post. Nothing in this post is legal, regulatory, or clinical advice, and you should consult your own compliance framework before adopting any new tool for regulated work.