The Liability Question: Why Emobot Never Records What Your Patients Say

In every serious conversation we have with a medical director or clinic C-suite, the same scenario surfaces within the first 30 minutes. A recent version of it came up in a meeting with the leadership team of a multi-site US interventional psychiatry network — a medical director, a network COO, and a physician with two decades of emergency medicine experience.

The physicians in that room were not asking a technical question. They were asking a malpractice question. And they were right to ask it — because the case law around AI tools in psychiatric care is actively being written, and the states with the highest malpractice awards (Florida, New Jersey) have juries, not peer reviewers, deciding outcomes.

The short version: Emobot's design makes this specific liability scenario structurally impossible. Here is why.

What most people assume AI voice monitoring does

When clinicians hear "AI listening to the patient's voice," they reasonably assume one of two architectures — both of which would create an immediate duty-to-act problem.

A plaintiff's attorney does not care about your regulatory classification if they can show that your system had information suggesting imminent harm and did not act on it. Both cloud architectures fail that test. Emobot's does not.

What Emobot actually does

Emobot's EmoDTx processes four signal streams — facial microexpressions, vocal acoustics, actigraphy, and digital behavior — entirely on the patient's device. The AI model lives inside the phone. Nothing is streamed to a server for processing.

For voice specifically, the system analyzes the acoustic properties of speech: prosody, energy distribution, frequency patterns, speech rate, pause structure. It listens to how the patient speaks, not to what the patient says.

The text of the speech is never transcribed. It is never stored. It is never transmitted. The model is mathematically incapable of producing a text output because it was never trained to do so. At the architectural level, there is no transcript — not on the phone, not in our servers, not anywhere.

Why this matters for malpractice exposure

The ER physician in the network meeting made the point crisply: in front of a jury, "our platform is not FDA-regulated" is not a defense. Neither is HIPAA compliance.

The liability question therefore reduces to: did the platform ever have that information in the first place?

With an active, content-aware AI — yes. The platform saw the words. It had constructive notice. Liability transfers.

With Emobot — no. The platform received an acoustic signal. It produced a mood trend line. It did not, and could not, detect the statement "I want to end my life." There was no content to see. There is no transcript to subpoena. There is no record to produce in discovery because the record does not exist.

This is not an after-the-fact legal opinion. It is a design constraint we committed to before shipping the first version, because we had already anticipated this exact conversation happening in every US clinic.

The alert architecture reinforces this

The second design decision makes this even cleaner: Emobot sends nudges to patients, not alerts to providers.

When the system detects a deteriorating trend, the nudge goes to the patient. The app suggests they reschedule with their clinician. The patient is the one who takes action. The provider dashboard shows a mirror of what the patient sees — a mood graph over time. There are no pop-up emergencies. There is no red alarm the physician is expected to respond to within 15 minutes.

This is why the product is classified as a consumer wellness application and not a medical device. The FDA does not regulate it because it does not make clinical decisions. It makes behavioral recommendations to the patient.

The implication for liability is important: there is no workflow in which a physician is expected to monitor Emobot data in real time and act on it outside clinic hours. That expectation does not exist because the product does not create it.

What you can tell your patients

The language we recommend — tested across 150+ clinicians in the US, France, Germany, and Canada — is direct and short.

Patients who were initially uneasy about the word "listening" almost always relax once this distinction is clear. In a population that includes paranoia-prone presentations, that framing matters. In our deployments, 80% of patients activate the app within 48 hours when a clinician proposes it and installs it with the patient during the visit.

What to add to your consent workflow

Clinics that want an additional layer of documentation typically add three sentences to their existing treatment consent form.

That language matches the regulatory reality of the product and documents the patient's informed choice to use it. Our customer success team can share the template used across US deployments.

The underlying principle

Good medical technology is designed around the constraints of clinical practice — not around what is technically possible to capture. The constraint in US interventional psychiatry is specific: providers cannot accept data streams that create round-the-clock duty of care without the staffing model to support it.

So we built a system that delivers the clinical value — continuous, objective, between-visit monitoring — without the liability surface of content capture and provider alerts. The outcome is a tool that is usable by a six-physician clinic with a normal after-hours policy, not only by academic centers with dedicated monitoring staff.

That design decision is the reason 150 clinicians have put this into their clinics. The alternative architecture — the one people assume we built — would not have been deployable.