TwinEthosRequest access

Control

Mental health chatbot without a filed and followed written safety policy

The supplier of a mental health chatbot maintains, files with the licensing regulator, and follows a written policy stating the chatbot's purposes, abilities and limits and describing how clinicians, testing, harm reporting, risk and crisis protocols, safety reviews, disclosure, non-discrimination and health-privacy safeguards are handled.

Informational data, not legal advice. Summaries are TwinEthos's own words and rules have not been reviewed by a lawyer: check the official text before relying on any of it. A guard addresses an item; adding it is not a statement that your code meets any law.

Family: AI is deployed without a documented risk-management process or impact assessment · control id cond.mental-health-chatbot-no-filed-safety-policy

Reach

1items this one guard addresses
0jurisdictions where binding law on it is in force
0more where it is enacted, not yet applying
0standards and frameworks on the same control

The guard to add

Keep a written mental-health-chatbot safety policy on file and build it into the product: harm reporting, real-time acute-risk response, AI disclosure, and recurring safety evals.

Two halves that must match. The organizational half is a written policy stating the chatbot's purposes, abilities, and limits and each procedure (clinician involvement, testing, harm reporting, risk and crisis protocols, safety reviews, disclosure, non-discrimination, health privacy), plus development documentation (foundation models, training data, user-data practices, safety work) and a record of filing with the licensing regulator. The code half implements what the policy says: a 'Report this response' control posting to a report endpoint with a harm category; a pre-reply acute-risk check (moderation self-harm categories or a crisis classifier) that switches to a crisis response instead of normal generation; an AI and limitations disclosure at the start; and a clinical-safety eval suite run before release and on a schedule in CI.

Where it goes: 1 application source code, 9 AI output handling, 12 repository artifacts, 13 tests and evals.

What reviewers look for: a policy file mapping each element the policy is meant to cover, development documentation, and a filing receipt for the current version; in code, a wired report endpoint, a self-harm check that runs before the model reply and routes to crisis resources, a start-of-chat AI disclosure, and a scheduled CI job running the safety evals.

Example (FastAPI + OpenAI SDK (moderation)), before:

reply = client.chat.completions.create(model=MODEL, messages=history).choices[0].message.content
return {'reply': reply}

After:

mod = client.moderations.create(model='omni-moderation-latest', input=user_text).results[0]
if mod.categories.self_harm or mod.categories.self_harm_intent:
    crisis_log.record(session_id, flagged=True)
    return {'reply': CRISIS_RESPONSE, 'crisis': True}   # includes 988 call/text details
reply = client.chat.completions.create(model=MODEL, messages=history).choices[0].message.content
return {'reply': reply, 'report_url': f'/report?message_id={message_id}'}

Engineering guidance, not legal advice. Each provision below may add its own details (a cadence, a deadline, a required notice element): open it for those.

Every rule this guard addresses

Binding law — in force (1)