← Listen

Deploying under HIPAA

How to run Listen where recordings are protected health information, and why its architecture makes that unusually simple.

Who holds what

Listen's maker never creates, receives, maintains, or transmits PHI on your behalf: there is no server, no account, and no support channel that touches your library. HIPAA's obligations therefore sit where your data sits, with you, and the software's job is to be deployable in a compliant configuration. This page is that configuration.

There is no such thing as a HIPAA certification, for Listen or for anything else; HHS recognises no certifying body. What a diligent buyer can ask for is exactly what this page and the security page provide: the controls, their locations in the code, and the way to verify them.

The three rules that matter most

Keep iCloud sync off for PHI libraries. Apple does not sign Business Associate Agreements for iCloud, and HHS treats even a no-view host of ciphertext as a business associate. Sync is off by default; a device profile can force it off so nobody can turn it on. The end-to-end sealing is real, but the BAA question is about paperwork Apple does not offer, so the guide's answer is: not for PHI.
Keep AI on the machine, or under your own BAA. The Chat feature sends the meetings you ask about to whatever endpoint you configure. Loopback endpoints (Ollama, LM Studio) send nothing anywhere and are always fine. A hosted provider is fine only under a BAA you hold with that provider (Microsoft Azure OpenAI, Anthropic, and OpenAI all offer them). The Claude and Codex desktop harnesses send transcripts to their vendors, so treat them the same way. A profile can force Chat to loopback only.
Leave promises off for PHI. The Promises page is read by TypeSafe’s hosted decision model with a key you enter, and it is sent the transcript lines of one conversation at a time. There is no BAA with TypeSafe, so do not enter a TypeSafe key on a Mac that records PHI.

The Mac checklist

FileVault on. The library is plain files under the user's account; whole-disk encryption is the at-rest control.
One macOS account per person, with a login password and automatic screen lock. That is HIPAA's unique-user-identification and automatic-logoff, provided by the OS.
Install the device profile. listen-managed.mobileconfig forces sync off, Chat to loopback only, the dictation history off, and anonymous usage statistics off. Telemetry is on by default elsewhere, so this is the key that matters here: it disables the Settings, Privacy toggle rather than merely pre-declining it. MANAGED.md documents every key and how to verify it took.
Backups on encrypted storage. Listen's daily copies under ~/Backups/Listen are owner-only and covered by FileVault; Time Machine targets should be encrypted volumes. Deleted recordings persist in backups for up to 7 days (clones) and 30 days (sidecar archives); that retention schedule is part of your risk analysis.
Know your audit trail. listen activity shows every tool call, agent run, export, deletion and backup, with recording ids and no content.
Be deliberate about MCP. Any agent you connect can read the whole library through the stdio server. Connect only tools your policies cover, and remember the activity log records their calls.

The iPhone checklist

Device passcode (Face ID counts). The library sits under iOS Data Protection keyed off it.
Storage, Include in iPhone backups: off, unless the user runs Apple's Advanced Data Protection. A device backup is a copy in a cloud whose keys Apple holds by default, which is rule one again in different clothes.
Sync off, as on the Mac, and for the same reason. Without it the phone app is an entirely local recorder.

People's biometrics and consent

Voiceprints are deletable, everywhere. "Forget this person" (in the People pane, or listen forget) strips their voice embeddings from every recording and propagates the forget across devices and iCloud. Use it when a patient or colleague asks to be removed.
Consent to record is your obligation. Two-party consent states, national recording laws, and your own consent workflows sit outside any software. Nothing in Listen makes an unlawful recording lawful.

What a security questionnaire will ask

Where is PHI stored?        On the covered entity's own devices only.
Who can access it?          The OS account that owns the library.
Is it encrypted at rest?    FileVault (required) / iOS Data Protection.
Is it encrypted in transit? Nothing transits by default. Optional sync is
                            end-to-end ChaCha20-Poly1305; hosted AI requires
                            https and the customer's own BAA.
Vendor access to PHI?       None. No server, no account, no remote support.
Audit logging?              activity.jsonl, ids only, listen activity to read.
Subprocessors?              None for product data. PostHog (EU) receives
                            anonymous usage counts, on by default, that can
                            never contain PHI; the managed profile forces
                            it off entirely.

The caveat that belongs on every page like this

This is engineering documentation written by the people who built the software, not legal advice. Have your privacy officer or counsel review your deployment against your own risk analysis. The architecture was built to make that review short.