OpenAI is rolling out a new safety feature for ChatGPT that’s designed to kick in when a conversation suggests a user may be at risk of self-harm. The update, reported as a “Trusted Contact” safeguard, reflects a broader shift in how AI companies think about responsibility: not just preventing harmful outputs, but building escalation paths that can connect people to real-world support when timing matters.
While most AI safety systems have historically focused on what the model says—refusing certain requests, offering crisis resources, or encouraging users to seek help—this new approach adds an additional layer. The core idea is straightforward: if a chat appears to be moving toward self-harm, the system can attempt to involve a trusted person who could provide immediate assistance. In other words, the safeguard is meant to bridge the gap between an AI’s ability to detect risk and the human support that risk situations often require.
This is not the first time OpenAI has emphasized mental-health-related safeguards. Over the past few years, ChatGPT and other AI systems have increasingly incorporated crisis guidance, including directing users to appropriate hotlines and encouraging them to reach out to local emergency services when necessary. But the “Trusted Contact” concept signals a more ambitious goal: reducing the chance that a user remains isolated during a critical moment, even if the user is interacting with an AI rather than a clinician or friend.
The unique challenge here is that self-harm risk is rarely a single sentence. It’s often a pattern—language that shifts from distress to intent, references to methods, statements about inability to cope, or descriptions of plans. Detecting those patterns reliably is difficult, and it raises a question that safety teams across the industry wrestle with: how do you intervene without being overly intrusive, and how do you avoid false alarms that could harm trust?
OpenAI’s framing, as described in coverage of the rollout, suggests the company is trying to strike a balance. The “Trusted Contact” safeguard is positioned as an extra layer of support in high-risk moments, not as a default behavior for every mention of self-harm. That distinction matters. Many people discuss mental health in ways that are serious but not necessarily imminent. A safety system that escalates too aggressively could discourage users from seeking help through AI tools at all. Conversely, a system that waits too long could miss the window where a human intervention could make a difference.
So what does “Trusted Contact” actually mean in practice? The term implies a mechanism where a user can designate someone—typically a friend, family member, or another person they trust—who could be notified if the system detects concerning signals. The notification would presumably be limited to the minimum necessary information, aiming to protect privacy while still enabling the trusted person to act. The safeguard is also likely to be governed by thresholds: the system would need to determine that the situation is sufficiently concerning to justify escalation.
This is where the update becomes more than a feature—it becomes a policy decision embedded into product design. Trusted-contact escalation forces a company to define what counts as “possible self-harm,” what level of confidence is required, and what the user experience should look like when the system decides to escalate. It also requires careful consideration of consent. If a user has not opted into such a mechanism, the system should not treat escalation as automatic. If a user has opted in, the system still needs to communicate clearly what will happen and under what conditions, so the user understands the tradeoff between privacy and safety.
In many ways, this is the same tension that appears in other safety domains, such as fraud detection or child-safety reporting. The best systems don’t just detect risk; they explain their logic in a way that users can understand. They also provide controls—so users can decide how much they want the system to do on their behalf. For mental health, those controls are especially important because the emotional context is fragile. A user who feels judged or surveilled may disengage at precisely the moment they need support.
OpenAI’s move also fits into a larger industry trend: AI safety is evolving from “content moderation” toward “risk management.” Content moderation asks, “Should the model produce this?” Risk management asks, “What should happen next to reduce harm?” That shift changes the engineering and product work involved. It means building monitoring layers, designing escalation workflows, and coordinating with external resources—whether that’s crisis hotlines, emergency services, or, in this case, a trusted person.
There’s another layer to consider: the role of the AI itself. In a self-harm scenario, the user may be seeking validation, coping strategies, or a sense that someone is listening. If the system escalates too quickly, it might interrupt that therapeutic conversation. If it escalates too slowly, it might fail to prevent harm. The “Trusted Contact” safeguard therefore likely works alongside existing crisis-response behaviors rather than replacing them. The AI would still aim to respond empathetically, encourage immediate help, and provide crisis resources. The trusted-contact step would be an additional action taken when the system believes the risk is high enough.
That combination—empathetic conversation plus escalation—can be powerful, but only if it’s implemented carefully. Users need to feel that the AI is acting to help them, not to punish them or report them. The tone and timing of the transition matter. A good design would ideally include a brief explanation before escalation: something like, “I’m concerned about your safety. I’m going to reach out to someone you trust so you’re not alone.” Even a short message can preserve dignity and reduce panic.
At the same time, there’s a practical reality: not every user has a trusted contact available, and not every trusted contact will be reachable. Some users may live in environments where involving another person could increase danger. Others may not have someone they feel safe contacting. That’s why the safeguard must be optional and configurable, and why it should probably fall back to other forms of help when trusted-contact escalation isn’t possible.
This is where the “Trusted Contact” concept becomes a window into how OpenAI may be thinking about mental-health safety as a system rather than a single response. A robust safety framework typically includes multiple pathways:
1) Immediate supportive guidance from the AI.
2) Crisis resources (hotlines, emergency numbers, local services).
3) Escalation to a trusted person when appropriate and consented.
4) Potentially, additional steps depending on jurisdiction and policy.
Even if the trusted-contact step is the headline, the real value is likely in how these pathways interact. For example, the system might prioritize crisis resources first, then offer trusted-contact escalation if the user indicates they want that support or if the risk threshold is met. Or it might do both in parallel, depending on the design.
A unique take on this update is to view it as a product-level answer to a question that has haunted digital mental-health tools for years: “How do we make sure help arrives when it’s needed?” Traditional apps often rely on user-initiated actions—tap a hotline, call a friend, find a local service. But in moments of crisis, user initiative can collapse. People may be unable to call, unable to search, or too overwhelmed to act. An AI that can detect risk and initiate outreach could reduce that friction.
However, that promise comes with ethical obligations. The system must avoid turning mental health into a surveillance pipeline. It must minimize data exposure, limit what is shared, and ensure that any notifications are proportionate. It also must be transparent enough that users can make informed choices. If users feel blindsided, the tool could become counterproductive.
There’s also the question of accuracy. Self-harm risk detection is inherently uncertain. Language can be ambiguous. Some users discuss self-harm historically, metaphorically, or in a therapeutic context. Others may express suicidal ideation without immediate intent. A safety system that treats all such language equally could create unnecessary alarm. Conversely, a system that is too conservative could miss genuine emergencies.
To address this, OpenAI likely uses a combination of signals—text patterns, contextual cues, and possibly user-level factors—to estimate risk. But even with sophisticated models, uncertainty remains. That’s why thresholds and calibration are crucial. The system should be designed so that escalation is reserved for cases where the probability of imminent harm is meaningfully higher than baseline. It should also include safeguards against repeated false positives that could erode trust.
Another important dimension is user agency. A trusted-contact safeguard can be framed as supportive, but it can also feel like loss of control. The best implementations tend to give users some say. For instance, users might be able to set their trusted contact, choose whether notifications are allowed, and review what kinds of information would be shared. They might also be able to opt out at any time. Even if the system ultimately escalates only under strict conditions, giving users control over the mechanism can reduce anxiety.
From a user-experience standpoint, the moment of escalation is delicate. The AI must continue to provide emotional support while the system initiates outreach. It should not abruptly stop the conversation. It should also avoid language that could intensify distress. Instead, it should focus on grounding the user, encouraging immediate help, and reassuring them that they are not alone.
For the trusted contact, the notification must be actionable. A vague alert like “Your contact may be at risk” might not be enough. But sharing too much personal detail could violate privacy. The ideal notification would include enough context to prompt a check-in—perhaps a message indicating that the user may be in danger and encouraging the trusted person to contact them directly or call emergency services if they cannot reach them. The system should also ideally include guidance for the trusted contact on what to do next, because many people don’t know how to respond to a crisis message.
This is where the “Trusted Contact” safeguard could differentiate itself from simpler crisis-resource prompts. Hotlines and emergency numbers are useful, but they require the user to act. Trusted-contact escalation can mobilize a second person who can act on the user’s behalf. It can also provide continuity: