Privacy by architecture vs HIPAA — the difference

HIPAA-compliant is a property of how a vendor handles your patients' data. Architectural privacy is the property of not having it. The two are not equivalent. Here's why it matters for your practice.

There is a sentence on most therapy-tech websites that I want to push back on.

Both halves of that sentence describe the vendor's relationship to data they have. Neither describes the relationship you, the licensed clinician, would prefer them to have, which is — ideally — none.

This post is the long version of an argument we're going to make a lot: HIPAA-compliant and privacy by architecture are not the same thing, and the difference matters for the documents that end up in your compliance file.

What HIPAA actually requires

HIPAA is a US federal law that defines two roles for any entity that touches Protected Health Information (PHI): the Covered Entity (you — the clinician, your practice) and the Business Associate (a vendor that processes PHI on your behalf).

When a vendor handles your patients' data — receives it, stores it, transmits it, sees it on a server they own — the law requires you to sign a Business Associate Agreement (BAA) with them. The BAA is a contract that:

1. Names the vendor as a Business Associate.
2. Lists the protections they will apply to PHI.
3. Names the consequences if they fail to apply those protections.
4. Obligates them to notify you of breaches.

A “HIPAA-compliant” vendor is one that has the technical and contractual machinery to be a Business Associate competently. It does not say their architecture is good. It says they have committed, on paper, to protect data they hold.

What that paper covers

A BAA covers the case where the vendor is doing what they said they were doing. It does not cover:

• A breach you don't learn about until 18 months later.
• A subpoena to the vendor in a malpractice case where their compliance team produces session audio you didn't know was still stored.
• A subprocessor — the vendor's vendor's vendor — having a worse breach posture than the vendor you signed a BAA with.
• The vendor going out of business, getting acquired, or pivoting to enterprise sales and changing their data-handling practices.
• The vendor honestly believing your data is encrypted, while their cloud provider has a configuration mistake nobody noticed.
• A single rogue employee at the vendor exfiltrating data because the vendor's internal access controls were the same in March as they were when the BAA was signed in November.

None of these are hypothetical. All of them have happened to mid-tier health-tech companies in the last five years. A BAA is paper. It transfers liability after the fact. It does not transfer outcomes.

What architectural privacy is

Architectural privacy is a property of the design, not of the contract. It says: the data the vendor cannot have, the vendor cannot lose.

A vendor with privacy-by-architecture cannot:

• Be subpoenaed for client audio they never received.
• Suffer a breach of session transcripts they never stored.
• Have a rogue employee exfiltrate notes their database does not contain.
• Ship a configuration mistake that exposes data they never had.
• Pivot to enterprise sales by selling access to a corpus of recordings they don't hold.

In Bryl's case, the architectural property is concrete: your session audio, the transcript, and the AI-generated note never leave your iPhone. There is no Bryl server that processes them. There is no cloud-based AI provider that receives them. The closest the data gets to leaving your device is when you copy the signed note into your EHR — at which point you, the licensed clinician, are the agent doing the copy, not us.

This is not a marketing claim. It is a structural property. We could not violate it without changing the architecture and pushing a software update — which would take engineering effort and would be visible to anyone watching network traffic from the app.

Why no BAA?

Because we are not a Business Associate to your practice.

A Business Associate, in the language of 45 CFR 164.502(e), is a person or entity that “creates, receives, maintains, or transmits” PHI on behalf of a Covered Entity. Roushan, Inc., the company that publishes Bryl, never creates, receives, maintains, or transmits your patients' PHI. The architecture prevents it.

You do not need a BAA with the manufacturer of the Sharpie you use to write physical notes. You do not need a BAA with the manufacturer of the lockable filing cabinet where you keep the notes. You do not need a BAA with Apple for the iPhone you use to record. The data-protection contract is between you and your patient.

Bryl is — architecturally — closer to the Sharpie than to the SaaS scribe. We provide the on-device tool. You remain the sole party with access to the content.

What goes in your compliance file

Your professional liability insurer, your licensing board's ethics committee, your malpractice attorney, and — in jurisdictions that have adopted them — state regulators will eventually ask you for documentation of how an AI tool you use handles client data. We've published the architectural attestation as a public page so you can drop the URL into your file or print the PDF. It contains:

1. The single sentence: “No client audio, transcript, or note-draft generated by Bryl ever leaves the licensed clinician's iPhone.”
2. A description of where the data lives — encrypted at rest under iOS Data Protection plus an additional AES-256-GCM layer keyed to a value held in the iOS Keychain.
3. The complete list of network calls Bryl can make (StoreKit, optional crash reports, optional anonymous event counters), none of which carry clinical content.
4. The legal reasoning for why no BAA is required.
5. The list of subprocessors for non-clinical paths (Apple, Cloudflare for the marketing site, Sentry and PostHog if you opt in to telemetry).
6. Verification steps you can run yourself to confirm the substantive claims.

We will provide a signed PDF version on letterhead, for jurisdictions or insurers that require it, on request to legal@bryl.app.

A practical reframe

When you're evaluating any AI tool for your practice — Bryl or otherwise — the question to ask the vendor is not are you HIPAA-compliant? Almost everyone says yes, because they have the paper to back it up.

The better question is: what data leaves my device, where does it go, who can read it, how do I verify your answer?

If the vendor cannot answer the fourth part — how do I verify — the first three answers are taken on trust.

For Bryl, the answer to the verification question is short. Turn off your network. The app keeps working. The work belongs in the room.