← 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 two rules that matter most

  1. 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.
  2. Keep AI on the machine, or under your own BAA. The Ask 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 Ask to loopback only.

The Mac checklist

The iPhone checklist

People's biometrics and consent

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.