← Resources

HIPAA and dictation: architectural vs contractual privacy

"Is this dictation app HIPAA compliant?" turns out to be two different questions stacked into one. There is a contractual answer (a cloud vendor signs a Business Associate Agreement, sets retention controls, takes on the safeguards HIPAA expects of business associates) and there is an architectural answer (the audio never leaves the device, so HIPAA’s rules around third-party processors of Protected Health Information do not engage at all). Both answers can be correct. They are not the same kind of correctness.

The two models, briefly

Contractual privacy is the default model for any cloud product handling PHI. The covered entity (a clinician, practice, hospital or health plan) and the business associate (the cloud vendor) sign a BAA. The vendor commits to specific safeguards and breach notification timelines. Optional controls layer on top: encryption in transit and at rest, regional data residency, zero data retention, audit logs, role-based access. The audio leaves your machine and is processed in the vendor’s data centre, then the contract scopes everything that happens around it.

Architectural privacy is a different shape of guarantee. The audio is captured, transcribed and discarded on the same Mac. No third party processes the audio because no third party receives it. PHI does not become "disclosed" in the HIPAA sense, because the disclosure step does not happen. There is no business associate to bind because the business associate role does not exist for the audio.

The honest summary: contractual privacy manages risk around audio that has left the device; architectural privacy keeps the audio from leaving the device in the first place. Both are real privacy postures. They have different attack surfaces and different failure modes.

What contractual privacy does well

Most US health systems already run on cloud-based clinical software, and their procurement teams are practised at signing BAAs and reviewing SOC 2 reports. Adding one more cloud business associate to that estate is a familiar exercise. The legal framework is well-understood. The vendor’s controls are auditable in the standard ways.

There are real practical advantages, too. Cloud vendors can support languages a local model has not been trained on. They can offer features that depend on aggregated context, like ambient encounter scribing across multiple devices and clinician-template libraries hosted server-side. The cross-device continuity that a covered cloud service makes possible is genuinely useful at scale.

What contractual privacy cannot change

The audio leaves the device. That is structural to a cloud transcription service: the speech model lives in the data centre, so audio has to reach the data centre. The BAA constrains what the business associate is allowed to do with it once it arrives. It does not change whether it arrives.

That has a few downstream consequences worth being honest about:

  • Breach surface. Cloud business associates have data breaches. The BAA requires you to be notified; it does not stop breaches happening.
  • Subprocessor sprawl. Modern cloud products are built on stacks of subprocessors: cloud infrastructure (AWS, GCP, Azure), observability vendors, content delivery networks, sometimes downstream model providers. Each link in that chain is something a covered entity has to evaluate.
  • Network reachability. Cloud dictation depends on the internet. For locked-down clinic networks, slow rural connections, hospital wifi under load or fieldwork outside reliable coverage, that dependency is operational risk.
  • Audit-log retention. The audit trail is itself a record of PHI handling. It needs to be retained and protected by the business associate under its own controls.

None of these break HIPAA compliance. They are the operational cost of choosing the contractual model. For some teams that cost is a fair trade for the features cloud transcription enables; for others it is heavier than the use case warrants.

What architectural privacy does well

The audit answer is short. "Does any audio leave the device?" "No, by architecture." That is one of the cleanest answers an audit framework can receive. There is no BAA to renew, no subprocessor map to maintain, no breach-notification clause that might fire because of something a vendor did, no data-residency setting to misconfigure.

The operational benefits are real:

  • No internet dependency. Transcription works in any room, on any network, on a train, in flight mode, on a locked-down clinic LAN.
  • One vendor relationship, not a tree of them. The local app is the only thing to evaluate; there are no downstream subprocessors handling audio.
  • Predictable for solo practitioners. A GP, a sole-practising solicitor, a therapist in private practice can deploy without a procurement team to negotiate a BAA.
  • GDPR alignment. Under UK and EU data protection law, voice is biometric data when it can identify a speaker. Not transmitting it removes a category of processing that would otherwise need a lawful basis and a Data Protection Impact Assessment.
  • Legal professional privilege. For solicitors and barristers, privileged matter on a local device never crosses a network boundary or lands in a third party’s audit log.

What architectural privacy cannot help with

The on-device model has its own honest limits.

  • Endpoint security still applies. Disk encryption, screen lock, device management and backup hygiene matter exactly as much as they did before. If the Mac itself is compromised, "audio never left the device" is small comfort.
  • Language coverage tracks the local model. A model trained on 25 European languages cannot transcribe Mandarin or Arabic, however well-architected the privacy. If the dictation has to work in a non-supported language, cloud is the trade you have to make.
  • Ambient encounter scribing is a different category. Capturing both sides of a clinical encounter and producing a structured note is a different product from push-to-talk dictation. That category is still cloud, by virtue of the model sizes involved.
  • Cross-device continuity. If a clinician moves between three workstations during a shift and expects identical dictation behaviour signed in everywhere, the cloud model fits that pattern more naturally.

Beyond HIPAA

The same framing carries to other regimes. Under GDPR and the UK Data Protection Act 2018, transmission of voice data to a processor outside the device is processing of (potentially biometric) personal data. A contractual model needs a lawful basis, an Article 28 processor agreement, transfer mechanisms if data leaves the UK or EU and a DPIA when the risk is non-trivial. An architectural model removes the transfer and the third-party processing from the assessment.

Under NHS information governance for UK practitioners, the same logic applies. The Data Security and Protection Toolkit asks how third parties are managed. With on-device dictation, there is no third party in scope for the dictation pathway itself.

Under legal professional privilege for solicitors and barristers, the assumption is that privileged communications stay between the lawyer and the client. Routing privileged matter through a cloud transcription vendor introduces a third party that did not exist in the original communication; a BAA equivalent for legal data is not part of the standard procurement framework most firms operate. Keeping the audio on the Mac removes the question.

A simple decision frame

  • If your organisation already manages a portfolio of cloud business associates under HIPAA, and you need features that only the cloud architecture provides (ambient scribing, non-European languages, cross-device sign-in), the contractual model is the established fit.
  • If your default question is "did this audio leave the device" and the right answer is "no", or if you are a sole practitioner or small clinic without procurement scale, the architectural model is the shorter path.
  • For most working clinicians, therapists and solicitors who dictate on a Mac as part of normal practice, the architectural model removes a category of risk without adding meaningful friction.

Where Parakeety fits

Parakeety is the architectural answer for Mac dictation. The speech model runs on the Apple Neural Engine; audio is captured to memory, transcribed locally, pasted at the cursor and discarded. The only outbound traffic ever generated by the app is a one-time speech-model download and periodic license checks, neither of which carries audio.

The audience pieces walk through how the same answer looks in each working context: Parakeety for clinicians and GPs, Parakeety for therapists and counselors and Parakeety for lawyers and solicitors. The product-level comparisons against specific cloud and local alternatives are in Parakeety vs Wispr Flow, Parakeety vs Dragon and Is Wispr Flow HIPAA compliant?.

FAQ

What is the difference between architectural and contractual privacy?
Contractual privacy is a promise. A vendor processes your data on its servers under a contract (in HIPAA terms, a Business Associate Agreement) that scopes what they are allowed to do, requires breach notification, and obligates safeguards. Architectural privacy is a property of the system. The data never reaches a third party in the first place, so there is no vendor relationship to bind. Both can be valid answers; they fail in different ways and they suit different deployments.
Does on-device dictation need a BAA?
No. A BAA is required when a covered entity discloses Protected Health Information to a business associate. If audio is captured, transcribed and discarded on the same Mac without ever being transmitted, there is no business associate in the chain. License-validation traffic (a license key, a hardware ID hash, a machine name) is not PHI under HIPAA.
Can architectural privacy fail?
Yes, in the same way any local software can. If the device itself is compromised, lost, or backed up to a misconfigured iCloud Drive, the protection it provides is the same as any other data on that machine. Architectural privacy removes the network leg of the threat model; it does not remove the endpoint. Disk encryption, device management and ordinary endpoint hygiene still matter.
Which model do auditors prefer?
It depends on the auditor and the deployment. US health-system security teams are well-practised at evaluating cloud business associates and signing BAAs; for them, contractual privacy is the established path. For NHS information-governance reviews, sole-practitioner GDPR DPIAs and any audit framing where "did this data leave the device" is the first question, the architectural answer is shorter to defend and removes whole categories of follow-up.

Try it

Parakeety is a Mac menu-bar app. Hold the section key, talk, release; your words paste at the cursor in whichever app you were typing into. Audio never leaves the machine. There is a free 7-day trial with no card required. After that it is $30 once.

Try Parakeety free →