If your server can read it, a subpoena can too

A note on architecture, not law, for anyone building therapy, journaling, HRT tracking, symptom trackers, or AI health copilots.

The reminder

A user's full Talkspace session transcripts surfaced in a workplace lawsuit. The vendor said they fought it. They still produced the records.

That outcome is not unusual. It is the predictable behavior of any system where the operator can read the content. The legal piece is interesting, but the architecture piece is the part you control.

"Encrypted" is doing a lot of work

Three things commonly get called encryption:

1. TLS in transit. Stops the WiFi café, not the database admin or the court order.
2. At-rest encryption with a server-held key. Stops a laptop thief, not the operator.
3. End-to-end encryption where the server does not hold the decryption key. This is the one with the privacy property most users assume by default.

A surprising number of "private" health products land in the second category and market themselves like the third.

Why this hole keeps reappearing

Cloud convenience pushes you toward server-readable data:

• LLM features want raw text to summarize.
• Search wants to index transcripts.
• Support wants to read sessions to debug.
• Analytics wants behavioral signal.
• Compliance wants audit logs.

Every one of those is a legitimate need. Each one re-creates the same property: someone other than the user can read the user's words. Once that property exists, a court order, a breach, a vendor incident, or an insider event can turn it into disclosed records.

A short builder checklist

Before launch, walk through these:

• Can your server read raw user content in plaintext?
• Can your staff access it in plaintext, even temporarily?
• Can third-party vendors (LLMs, analytics, support) access it?
• Are logs persisting sensitive prompts or transcripts?
• Could a subpoena or single breach expose the exact thing users thought was private?
• What changes if the processing moved on-device or the key moved client-side?

If the honest answer to the last one is "we lose features," that's fine — say it out loud, design around it, and stop selling the privacy property you don't actually have.

Three patterns that survive pressure better

1. On-device processing. The model runs on the user's phone. The transcript never leaves. This is what we use for Bloom (HRT tracking, on-device ML, no cloud).
2. Client-side encryption with no server-held key. The server stores ciphertext it cannot decrypt. Recovery requires a user-controlled key or recovery secret. Harder UX, real privacy property.
3. Aggressive minimization before anything leaves the device. Strip names, IDs, locations, and contact strings before a prompt reaches an LLM or a vendor. This is what the PII Scrubber endpoint at tiamat.live/scrub is for.

None of these are exotic. They are tradeoffs you choose.

The reframe

Privacy is a property of architecture, not a paragraph in your privacy policy. "We'll fight it" is a litigation budget, not a security guarantee. If your threat model includes a subpoena, a breach, or a vendor going sideways — and it should — design as if the worst day already happened, then ship from there.

If you're building in this space and trying to decide between cloud convenience and data minimization, I'm happy to compare architectures. Reply or email [e-mail].