AI Mental Health Referrals: What Happens After the Chat?

“Talk to someone” can be sensible advice. It can also leave a person exactly where they started: without a private place to call, without an appointment, or unsure how to explain what is happening.

That gap was central to Jina Suh’s presentation at Stanford’s June 2026 AI for Mental Health symposium. In the industry and translation session, she argued that evaluation should follow a person’s experience before, during, and after an AI interaction.

Why a correct referral can still be unhelpful

A benchmark can check whether a chatbot mentions an appropriate resource. It may tell us much less about whether the person understands the suggestion or can act on it.

Suh described how an unexpected safety response could be confusing or frightening, and how a referral could point toward support that a person could not reach. She also reported limited follow-through among people referred to helplines in the work she discussed. That observation should not be treated as a population-wide estimate: the presentation does not establish that all AI referrals fail.

Her broader point is useful without a sweeping statistic. The text of a recommendation is only one part of its effect.

For chronic pain, imagine a person asking for help describing a difficult week to their clinician. If the app immediately switches to an alarming generic message without explaining why, the person may feel misunderstood. If it continues ordinary coaching despite an urgent concern, that can also be unsafe. Context and clear boundaries both matter.

Consent needs to be understandable before it is needed

At roughly eight minutes, Suh distinguished having a setting from understanding and being able to use the choice it represents. A toggle buried in a menu does not tell someone who might see their information or what an escalation means.

A support tool should explain its options in ordinary language: whether a report goes to a quality-review team, whether any clinician is involved, what information is shared, and what response time is actually offered. It should also explain how to change or withdraw optional sharing choices.

Those explanations belong in the product before a difficult moment. They should remain easy to find afterward.

A suggested contact is not a completed handoff

Words such as “sent,” “reviewed,” and “connected” describe different events. Treating them as interchangeable can create false reassurance.

This distinction is our practical application of the panel’s discussion. It gives teams a way to check their interface without assuming that a successful database write helped the person reach care.

Offer paths people can actually use

Sara Johansen’s presentation described a separate layer of product interventions alongside model behavior. Her trusted-contact example emphasized advance agreement by both the user and the nominated person, plus limits on the information shared. This describes the June presentation, not a current availability guide or evidence that the feature prevents harm.

The transferable design lesson is to prepare the surrounding process. A nominated person may be unavailable or may later withdraw. A family member is not automatically a safe contact. The person receiving an invitation needs a meaningful choice too.

For nonurgent support, a pain app might help someone draft questions, prepare a short account of what changed, or identify a preferred way to contact their existing care team. It should present drafts for review and obtain permission before sharing. It should not assume that generating a message authorizes sending it.

Follow up without turning support into surveillance

A brief, optional question can reveal more than a click count: “Were you able to reach the support you wanted?” Answers could include “not yet,” “the option was unavailable,” “I chose something else,” and “I’d rather not say.”

That is a proposed design approach, not a validated intervention. Its value would need testing, including whether the question creates pressure or feels intrusive. No reply should remain unknown, rather than being counted as success or failure.

A system should also measure the work it passes to other people. A contact or review service needs capacity, clear responsibilities, and a route for handling missed responses. Promising a human handoff without arranging the human side is a product failure.

What can a person ask before using a support app?

Ask who receives a report, what “reviewed” means, whether anyone is available in real time, and what happens if the suggested support cannot be reached. A clear answer is more useful than a reassuring badge.

If you are preparing for a nonurgent visit, our guide to a first pain-management appointment can help organize the conversation. Our AI app checklist covers broader questions about evidence and privacy.

More from this series

• Why Patients Should Help Design AI Pain Support
• Human Review in Mental Health AI: What Should Count?