Washington educational resource

Washington Mental Health AI Chatbot Privacy: Where MHMDA Bites the AI Stack

AI mental health chatbots concentrate every MHMDA risk in one product. The user discloses symptoms, diagnosis, medication, treatment-seeking, and crisis content in free-text form. The chatbot routes that content to a third-party model API. The conversation history is stored in a vector index for retrieval-augmented responses. Crisis flags trigger outreach or partner referrals. Analytics, attribution, and support tooling see chat content. Each of those is a sharing event under RCW 19.373.030 unless the consent and processor architecture are MHMDA-compliant. HIPAA almost never reaches a consumer-facing mental health chatbot.

Last legally reviewed: 2026-05-19. Citations verified against Chapter 19.373 RCW.

What MHMDA reaches inside an AI mental health chatbot

User messages: any message that names symptoms, diagnosis, medication, treatment-seeking, or otherwise discloses mental health status is consumer health data.
Model outputs: chatbot replies that reflect or categorize the user's mental health status are derived consumer health data.
Inference labels: crisis-detection flags, sentiment labels, intent classifications, risk scores.
Conversation history stored in a vector index or RAG store.
Fine-tune datasets or evaluation sets that include user messages.
Analytics events that include message content or derived classifications.
Customer support tooling that surfaces conversation transcripts to agents.

The five processor questions that drive the analysis

Which model provider, and on what API tier? A managed enterprise tier with zero-retention defaults and a Washington addendum is materially safer than a public consumer API tier. Document the tier and the retention setting in writing.
What is the training-data posture? The contract should say messages are not used to train the model or any other model without separate opt-in consent. The default opt-out language in standard model-provider DPAs is not always enough; a Washington addendum or an explicit MHMDA processor contract under RCW 19.373.060 usually is.
What is the retention window at the model provider? Zero retention is the simplest posture. Where retention exists, document the window and the deletion mechanism, and confirm it can be triggered by the user's deletion request under RCW 19.373.040.
What is the vector store posture? Vector embeddings derived from user messages are still consumer health data. The store must be inside the operator's reasonable-care perimeter under RCW 19.373.050 and reachable by the deletion workflow.
Is the model run in your own cloud or via the provider's API? Self-hosted on the operator's cloud (Azure OpenAI inside the operator's tenant, AWS Bedrock inside the operator's account, a hosted open-source model on the operator's infrastructure) keeps the data inside the operator's reasonable-care boundary. API-only usage requires processor contracts and a documented retention posture.

The crisis-flag exception. When the chatbot detects suicidal ideation, intent to harm, or imminent risk, the platform usually needs to route to a crisis line, a partner network, or 911. That can be a permitted disclosure under RCW 19.373.030 as necessary to provide a requested product or service or under a separate sharing consent that names the crisis partner. Document the trigger criteria, the recipient, the data sent, and the legal basis. Do not assume an unbounded "we may share with crisis services" clause covers the disclosure.

What MHMDA requires for an AI mental health chatbot

Separate Consumer Health Data Privacy Policy under RCW 19.373.020 that addresses message content, model provider relationships, vector storage, training-data posture, retention, and crisis routing.
Two-layer consent under RCW 19.373.030: collection of conversation content plus a separate, granular sharing consent for each external recipient category (model provider, analytics, crisis partner, optional human review).
Operational deletion under RCW 19.373.040 that reaches the chat store, the vector index, any RAG cache, the analytics warehouse, and the model provider's retention buffer if any.
Reasonable-care security under RCW 19.373.050. Engineering and support access to conversation content should be logged and scoped to consented purposes.
MHMDA-compliant processor contracts under RCW 19.373.060 with the model provider, the vector store provider, analytics, support tooling, and any crisis partner.
Branding: the chatbot must not use phrases implying a licensed professional relationship, such as counselor, therapist, or attorney framings. "AI Legal Analyst" style framing keeps the disclaimer posture clean and avoids overlap with state professional-licensing law.
If conversation content or any derivative is sold or licensed, sale-of-data authorization under RCW 19.373.070 with all nine elements.

What to send for a written review

Architecture diagram: front-end, server, model API or hosted model, vector store, analytics, support tooling, crisis routing.
Model-provider contract or DPA and any Washington addendum.
Current privacy policy, Consumer Health Data Privacy Policy if separate, signup and consent screens.
System prompt and any user-visible disclosure about what the chatbot is and is not.
Crisis-flag flow: trigger criteria, recipient, data sent, legal basis claimed.
Deletion workflow and which systems are reached.

Sergei's practical note

Mental health chatbots are where I see the biggest gap between marketing claims and MHMDA reality. The marketing site says "private and secure" while the model API tier is the public consumer tier with default retention, the vector store sits outside the deletion workflow, and the system prompt uses phrases implying a licensed professional relationship. The fix is structural: enterprise-tier model provider with a Washington addendum, zero retention by default, vector store inside the deletion workflow, MHMDA-compliant processor contracts on every vendor that touches conversation content, a separate Consumer Health Data Privacy Policy, two-layer consent at signup, and branding language that does not imply licensed-professional services. I review under California license. This is regulatory advisory work, not Washington representation.

Educational resource. Sergei Tokmakov is a California attorney (CA Bar #279869) currently seeking admission to the Washington State Bar. Nothing here creates an attorney-client relationship or is Washington legal advice.