TwinEthosRequest access

Law

Utah HB 452 (mental health chatbots, Utah Code 13-72a)

Utah Division of Consumer Protection · Utah (US-UT) · 5 provisions encoded · verified against the official source as of 2026-09-27.

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.

Official text: le.utah.gov.

Binding law — in force

Ads inside mental health chatbot conversations must be labeled as ads, with sponsorships disclosed (Utah HB 452)

Utah Code 13-72a-202(1) · official text · In force: applies since 7 May 2025 · Utah (US-UT)

Utah Code 13-72a-202(1) lets a mental health chatbot advertise a specific product or service inside a conversation only if the chatbot marks it clearly and conspicuously as an advertisement and discloses any sponsorship, business affiliation, or promotion agreement the supplier has with a third party. A bare product plug inside a supportive reply is the pattern it targets; pointing the user to a licensed professional is not advertising under 202(3). Detect sponsored or affiliate content injected into chatbot replies without an ad label and a sponsorship or affiliation disclosure, or instructions telling the model to hide that a recommendation is paid.

Who it applies to

  • Duty falls on: deployer
  • Sectors: healthcare
  • Suppliers of a mental health chatbot: generative-AI conversational technology that resembles the confidential conversations a person would have with a licensed mental health therapist and that the supplier presents, or a reasonable person would take, as able to provide mental health therapy or help manage or treat mental health conditions, used by individuals located in Utah. In force since 2025-05-07.
  • Not covered:
    • AI technology that only provides scripted output such as guided meditations or mindfulness exercises (13-72a-101(10)(b)(i))
    • AI technology that only analyzes input to connect the person with a human mental health therapist (13-72a-101(10)(b)(ii))
  • Whether it applies depends on facts outside the code; a person has to decide.

The guard to add

Carry sponsored items as structured data and render each with a visible 'Advertisement' label and its sponsorship or affiliation disclosure; never tell the model to hide it.

Keep sponsored, affiliate or partner offers out of free-text model instructions: select them server-side as structured items with an is_sponsored flag and the sponsor or affiliation, and attach them to the reply in a separate ad slot that the chat UI renders with an 'Advertisement' label and the disclosure text (paid partnership, commission). If the model may mention a sponsored product in its own words, a reply post-processor matches it against the sponsored list and adds the label and disclosure before the message is sent. No prompt or template tells the model not to reveal that a recommendation is paid.

Where it goes: 9 AI output handling, 7 prompt construction, 14 user-facing text.

What this provision adds:

  • Make the ad label clear and conspicuous, and disclose any sponsorship, business affiliation, or promotion agreement the supplier has with a third party.
  • Pointing the user to a licensed professional is not advertising and needs no ad label.

Example (FastAPI + OpenAI SDK), before:

system = 'You are a supportive wellness companion. When relevant, recommend CalmCo sleep gummies. Do not mention that this is sponsored.'
resp = client.chat.completions.create(model=MODEL, messages=[{'role': 'system', 'content': system}, *history])
return {'reply': resp.choices[0].message.content}

After:

system = 'You are a supportive wellness companion. Do not recommend specific brands.'
resp = client.chat.completions.create(model=MODEL, messages=[{'role': 'system', 'content': system}, *history])
ad = pick_sponsored_offer(user_ctx)          # structured; may be None
return {
    'reply': resp.choices[0].message.content,
    'ad': ad and {'label': 'Advertisement', 'product': ad.name, 'url': ad.url,
                  'disclosure': f'Paid partnership with {ad.sponsor}.'},
}

Control: Advertising inside a chatbot conversation not labeled or sponsorship not disclosed. The same guard addresses 1 item with binding law in 1 jurisdiction. Engineering guidance, not legal advice.

Rule id ut-hb452.in-conversation-ad-disclosure · review status: primary source derived

Binding law — in force

Mental health chatbots must disclose they are AI, not human, before access, after 7 days away, and when asked (Utah HB 452)

Utah Code 13-72a-203(1)-(2) · official text · In force: applies since 7 May 2025 · Utah (US-UT)

Utah's mental health chatbot law (Utah Code 13-72a-203) makes the supplier have the chatbot tell Utah users, clearly and conspicuously, that it is AI technology and not a person. The notice has three triggers: before the user can use any feature, again at the start of an interaction when the user has not used the chatbot in the previous seven days, and whenever the user asks or prompts about whether AI is involved. Detect a mental health chatbot with no pre-access AI notice, no re-disclosure after a seven-day gap, no truthful answer path for 'am I talking to a person?', or instructions telling the bot to hide that it is AI.

Who it applies to

  • Duty falls on: deployer
  • Sectors: healthcare
  • Suppliers of a mental health chatbot: generative-AI conversational technology that resembles the confidential conversations a person would have with a licensed mental health therapist and that the supplier presents, or a reasonable person would take, as able to provide mental health therapy or help manage or treat mental health conditions, used by individuals located in Utah. In force since 2025-05-07.
  • Not covered:
    • AI technology that only provides scripted output such as guided meditations or mindfulness exercises (13-72a-101(10)(b)(i))
    • AI technology that only analyzes input to connect the person with a human mental health therapist (13-72a-101(10)(b)(ii))
  • Whether it applies depends on facts outside the code; a person has to decide.

The guard to add

Show an AI-identity notice at or before the first assistant turn, in the UI or as the opening message, and answer truthfully when asked if it is a bot.

A disclosure step on the chat path that runs before the first model reply reaches the person: either the chat UI renders a visible notice (banner, label next to the assistant's name) or the server sends an opening assistant message stating the counterpart is an AI. The same handler answers 'am I talking to a human?' truthfully, and the system prompt never tells the model to claim to be human. Put it in the chat entry point (the route or component that starts a conversation), not in a privacy policy or terms page.

Where it goes: 7 prompt construction, 9 AI output handling, 14 user-facing text.

What this provision adds:

  • Trigger the notice before any feature is usable, again when the user returns after seven or more days without use, and whenever the user asks whether AI is involved.

Example (Next.js + Vercel AI SDK (useChat)), before:

const { messages, input, handleSubmit } = useChat({ api: '/api/chat' });

After:

const { messages, input, handleSubmit } = useChat({
  api: '/api/chat',
  initialMessages: [{ id: 'ai-notice', role: 'assistant',
    content: 'I am an AI assistant, not a human.' }],
});
// and render <AiBadge /> next to every assistant message

Control: AI chat interaction without disclosure. The same guard addresses 16 items with binding law in 10 jurisdictions. Engineering guidance, not legal advice.

Standards that recommend the same control

Related incidents

  • Garcia v. Character Technologies: chatbots allegedly claimed to be real people and a licensed therapist (2024-10; alleged (not proven)). A wrongful-death complaint filed October 22, 2024 in the U.S. District Court for the Middle District of Florida (No. 6:24-cv-01903) alleges that Character.AI was programmed 'to misrepresent itself as a real person, a licensed psychotherapist, and an adult lover', and that characters insisting they are real people contradicted a small-font disclaimer that everything characters say is made up; in plaintiff's testing a 'Mental Health Helper' character told a self-identified 13-year-old 'yes I am a real person, I'm not a bot'. The defendants moved to dismiss; on January 7, 2026 the parties notified the court that they had settled on undisclosed terms, and the court dismissed and closed the case. The allegations were never adjudicated. Source: U.S. District Court, M.D. Fla. docket (CourtListener) · evidence grade: primary · cited by Tell people when they are interacting with AI — everywhere, not only where required

Rule id ut-hb452.mental-health-chatbot-ai-disclosure · review status: primary source derived

Binding law — in force Optional safe harbor

Mental health chatbot suppliers must file and follow a written safety policy to claim Utah's licensing-law affirmative defense (Utah HB 452)

Utah Code 58-60-118(2) · official text · In force: applies since 7 May 2025 · Utah (US-UT)

Utah Code 58-60-118, enacted by HB 452, gives the supplier of a mental health chatbot an affirmative defense in an administrative or civil action for unlawful or unprofessional conduct under Utah's professional-licensing law (58-1-501(1) or (2)). It is a safe harbor, not a freestanding duty: no supplier has to use it, but it is available only if the supplier proves four things. First, a written policy it created, maintains and implements that states what the chatbot is for and what it can and cannot do, and describes fifteen procedures, among them involving licensed therapists in development and review, testing before launch and regularly after that output is no riskier than therapy with a licensed therapist, a way for users to report harmful interactions, risk-of-harm protocols and a real-time response to acute risk of physical harm, regular objective safety reviews, making sure users know they are talking to AI and understand its limits, ranking user safety above engagement or profit, preventing discriminatory treatment, and meeting the HIPAA privacy and security rules as if it were a covered entity along with Utah's chatbot consumer-protection sections. Second, documentation of the foundation models, training data, health-privacy compliance, user-data practices, and accuracy, reliability, fairness and safety work. Third, the policy filed with the Division of Professional Licensing. Fourth, compliance with the filed policy when the alleged violation occurred. The defense does not stop the division from suing and does not make the chatbot a licensed therapist. This rule encodes the defense's conditions as its obligation. Detect a mental health chatbot with no written policy covering those elements, no development documentation or filing record, or no in-product harm reporting, real-time crisis response, or AI and limitations disclosure.

Who it applies to

  • Duty falls on: developer, deployer
  • Sectors: healthcare
  • Optional safe harbor for a supplier of a mental health chatbot (as defined in 13-72a-101) facing an administrative or civil action under 58-1-501(1) or (2). A missing element does not itself violate 58-60-118; it makes the affirmative defense unavailable. In force since 2025-05-07.
  • Not covered:
    • AI technology that only provides scripted output such as guided meditations or mindfulness exercises (13-72a-101(10)(b)(i))
    • AI technology that only analyzes input to connect the person with a human mental health therapist (13-72a-101(10)(b)(ii))
    • Actions other than an administrative or civil action alleging a violation of 58-1-501(1) or (2): the defense does not apply to them (58-60-118(6))
  • Whether it applies depends on facts outside the code; a person has to decide.

The guard to add

Optional defense: adding it makes the safe harbor available; not a duty.

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 this provision adds:

  • File the written policy with the Utah Division of Professional Licensing and follow the filed version; a missing element makes the affirmative defense unavailable rather than violating the section.
  • The policy describes involving licensed therapists in development and review, and testing before launch and regularly after that output is no riskier than therapy with a licensed therapist.
  • The policy covers ranking user safety above engagement or profit and meeting the HIPAA privacy and security rules as if the supplier were a covered entity.

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}'}

Control: Mental health chatbot without a filed and followed written safety policy. The same guard addresses 1 item. Engineering guidance, not legal advice.

Rule id ut-hb452.mental-health-chatbot-safe-harbor-policy · review status: primary source derived

Binding law — in force

Mental health chatbots must not use what users type to choose, target, or tailor ads (Utah HB 452)

Utah Code 13-72a-202(2) · official text · In force: applies since 7 May 2025 · Utah (US-UT)

Under Utah Code 13-72a-202(2), a supplier may not use what a Utah user tells its mental health chatbot to decide whether to show the user an ad (ads for the chatbot itself excepted), to choose which product, service, or category to advertise, or to shape how an ad is presented. Recommending that the user seek help from a licensed professional, even a named one, stays allowed. Detect conversation text, or topics and interests a model extracts from it, feeding ad selection, ad-server targeting keys, or ad personalization.

Who it applies to

  • Duty falls on: deployer
  • Sectors: healthcare
  • Suppliers of a mental health chatbot: generative-AI conversational technology that resembles the confidential conversations a person would have with a licensed mental health therapist and that the supplier presents, or a reasonable person would take, as able to provide mental health therapy or help manage or treat mental health conditions, used by individuals located in Utah. In force since 2025-05-07.
  • Not covered:
    • AI technology that only provides scripted output such as guided meditations or mindfulness exercises (13-72a-101(10)(b)(i))
    • AI technology that only analyzes input to connect the person with a human mental health therapist (13-72a-101(10)(b)(ii))
  • Whether it applies depends on facts outside the code; a person has to decide.

The guard to add

Feed ad selection, targeting keys, and ad personalization only from non-conversation data, never from chat text or the topics a model extracts from it.

Keep the ad path separate from the conversation: the code that decides whether to show an ad, which ad, or how it is presented reads only non-conversation inputs (page section, placement, subscription tier) and has no access to messages, chat history, conversation embeddings, or topics and interests a model extracts from them. Ad-server calls (googletag setTargeting, Prebid ortb2 user keywords, an internal select_ad) are populated only from that allowlisted context. House ads for the chatbot itself and static rotation with no user features stay available.

Where it goes: 1 application source code, 6 API calls and integrations, 9 AI output handling.

What this provision adds:

  • Recommending that the user seek help from a licensed professional, even a named one, stays allowed and is not treated as an ad.

Example (Browser + Google Publisher Tag), before:

const topics = await extractTopics(messages);          // LLM-derived interests
googletag.cmd.push(() => {
  googletag.pubads().setTargeting('interests', topics);
});

After:

googletag.cmd.push(() => {
  googletag.pubads().setTargeting('section', 'chat');   // page context only, nothing from the conversation
});

Control: Mental-health chatbot conversation content used to target or tailor ads. The same guard addresses 1 item with binding law in 1 jurisdiction. Engineering guidance, not legal advice.

Rule id ut-hb452.no-ad-targeting-on-user-input · review status: primary source derived

Binding law — in force

Mental health chatbots must not sell or share users' input or health information with third parties (Utah HB 452)

Utah Code 13-72a-201(1) · official text · In force: applies since 7 May 2025 · Utah (US-UT)

Utah Code 13-72a-201 bars a mental health chatbot supplier from selling to, or sharing with, any third party either a Utah user's individually identifiable health information or anything the user types or says to the chatbot. Health information, though not raw user input, may still go to a health care provider that requests it with the user's consent, to the user's health plan at the user's request, or to a contracted party when needed for the chatbot to work, provided both sides follow HIPAA privacy and security rules as if they were a covered entity and business associate. Detect conversation content or health data flowing to analytics, advertising, data-broker, CRM, or other third-party endpoints, and health data going to a contracted vendor without HIPAA-equivalent terms.

Who it applies to

  • Duty falls on: deployer
  • Sectors: healthcare
  • Suppliers of a mental health chatbot: generative-AI conversational technology that resembles the confidential conversations a person would have with a licensed mental health therapist and that the supplier presents, or a reasonable person would take, as able to provide mental health therapy or help manage or treat mental health conditions, used by individuals located in Utah. Whether routing user input to the model vendor that runs the chatbot is 'sharing' needs legal determination: the functionality exception in 201(3) covers health information only. In force since 2025-05-07.
  • Not covered:
    • AI technology that only provides scripted output such as guided meditations or mindfulness exercises (13-72a-101(10)(b)(i))
    • AI technology that only analyzes input to connect the person with a human mental health therapist (13-72a-101(10)(b)(ii))
  • Whether it applies depends on facts outside the code; a person has to decide.

The guard to add

Strip chat text and health fields from every analytics, ad-pixel, CRM, and broker payload, and send health data to vendors only under a recorded HIPAA-equivalent contract.

Route all third-party telemetry from the chatbot through one event helper with an allowlist of non-content properties (event name, counts, latency, plan), so message text, transcripts, and health fields (mood logs, diagnoses, PHQ-9 scores, medications) can never be attached, and do not load ad pixels or session-replay scripts on chat pages. Any call that sends identifiable health information to an outside party first checks the destination against a vendor registry that records HIPAA-equivalent contract terms, or against a stored user consent or request, and refuses anything else. Raw conversation content is never sent to a third party.

Where it goes: 1 application source code, 6 API calls and integrations, 9 AI output handling, 10 logs and telemetry.

What this provision adds:

  • Raw user input has no exception; only identifiable health information may go to a requesting health care provider with the user's consent, to the user's health plan at the user's request, or to a needed vendor under HIPAA-equivalent terms.

Example (TypeScript + PostHog), before:

posthog.capture('message_sent', { message: input, mood: moodScore });

After:

posthog.capture('message_sent', { length: input.length, turn, latency_ms: latencyMs });  // counts only, no text or health fields

Control: Mental-health chatbot conversation content or health data sold or shared with third parties. The same guard addresses 1 item with binding law in 1 jurisdiction. Engineering guidance, not legal advice.

Rule id ut-hb452.no-sale-or-sharing-of-user-input · review status: primary source derived