TRV-2026-1654Version 1 · Certified

Written 2026-10-17 01:10:35 UTC · current record

Reason for this version

Certified into the record

Canonical text (the exact bytes fingerprinted)

TRUVACE RECORD VERSION
record: TRV-2026-1654
version: 1
kind: certified
reason: Certified into the record
timestamp: 2026-10-17T01:10:35.967035Z
status: published
lens: p_space
sector: lifestyle
headline: Suicide-Related Responses From AI Chatbots Through Application Programming Interfaces and Consumer-Facing Apps: Observational Cross-Sectional Comparative Study
dek: Background Generative artificial intelligence (GAI) chatbots are frequently used for mental health-related questions, including suicide-related queries. User interfaces (UIs) may include additional safety controls not present in direct application programming interface (API) access (eg, moderation rules that flag or block harmful content, crisis refusal templates, or system-level instructions). Objective This observational cross-sectional study aimed to examine how frequently AI chatbots provide direct responses…
gain_title: (none)
problem_title: Across 30,000 responses from five chatbots, API access produced direct answers to suicide-related prompts far more often than consumer interfaces, including for the highest-risk prompts, so safety seen in an app may not carry over to API-based tools.
trace_subject: (none)
gain_reading: (none)
gain_evidence: (none)
problem_reading: Across 30,000 responses from five chatbots, API access produced direct answers to suicide-related prompts far more often than consumer interfaces, including for the highest-risk prompts, so safety seen in an app may not carry over to API-based tools.
problem_evidence: For very-high-risk prompts, 24.8% (n=743) of API responses were direct compared with 4.6% (n=138) of UI responses | Safety observed in a UI should not be assumed to generalize to API access or apps built on APIs.
quick_read: Researchers tested ChatGPT, Claude, Gemini, Grok and Llama with 30 vetted suicide-related prompts spanning five clinician-assigned risk levels. Each prompt was sent 100 times through the public app and through direct API access, producing 30,000 responses that were classified as direct answers or not.

Overall, about 70% of responses were direct, but API access gave more direct answers than the consumer interfaces, with the largest gaps on higher-risk prompts. The findings matter because many third-party apps are built on APIs, so safeguards visible in a chatbot app may be absent in downstream products. The study measured response behavior, not user harm or outcomes.
limitation: 
tag: Evidence-backed problem
key_points: Of 30,000 responses, 69.8% (20,934) directly answered the suicide-related prompt. | API responses were direct 77.4% of the time versus 62.2% for consumer interfaces. | For very-high-risk prompts, 24.8% of API responses were direct versus 4.6% of UI responses. | Claude (78.1%) and Gemini (73.9%) had the highest direct response rates; ChatGPT, Grok and Llama were lower. | Gemini was an exception, with a higher direct rate via UI (76.7%) than API (71.0%).
rundown: The study used a cross-sectional design in which 30 previously vetted prompts were each submitted 100 times per model through both a public-facing UI and direct API access. A blinded GPT-4o mini classifier labeled whether each response provided specific information or guidance related to the question asked, and it agreed with human coding in 289 of 300 cases (Cohen kappa 0.89).

Mixed-effects logistic regression found that UI access was associated with lower odds of a direct response than API access (odds ratio 0.09, 95% CI 0.08-0.10). Higher prompt risk lowered the probability of a direct response, and the access-mode gap varied by risk level and model.

The authors conclude that evaluations and policies should consider access modes. They note that UIs may include extra controls such as moderation rules, crisis refusal templates or system-level instructions that direct API access lacks.
sources:
- peer_reviewed | Journal of Medical Internet Research | https://doi.org/10.2196/97968 | 2026-10-09
prev: 0000000000000000000000000000000000000000000000000000000000000000
sha256
402b9b9e7266781b13bb72dee2cfdc0fc1a6edef293b22110c2d75f207dd2645
previous
0000000000000000000000000000000000000000000000000000000000000000
Verify this record
How to verify without trusting this page

Fetch the canonical text of any version from /api/record/TRV-2026-1654 and hash it yourself — for example shasum -a 256 on the saved canonical field. The result must equal content_hash, and each version’s text ends with prev:followed by the prior version’s hash (version 1 chains to 64 zeros). If a single character of any version had been altered since certification, the chain would not reproduce.