Building an AI Mental Health App in 2026: The State-by-State Map

If you started building an AI mental health product in 2024, you were operating in a legal vacuum. That vacuum closed in 2025. Eight states have passed AI mental health laws since March 2025, and they fall into two camps: outright restrictions on AI delivering therapy, and disclosure-and-safeguard regimes that regulate the product without banning it.

The single most useful fact in this entire post is a distinction Illinois drew. Under the Wellness and Oversight for Psychological Resources Act (WOPR Act), Public Act 104-0054, effective 4 August 2025, AI may not provide therapy, diagnosis or therapeutic decision-making — but AI may still be used for administrative work such as scheduling and documentation.

Sit with what that means for a product team. It is not a rule about your company or your model. It is a rule about which functions execute for which users. The same codebase, the same model, the same prompt library can be lawful or unlawful depending on which capabilities you expose in which state. That makes your compliance posture an architecture decision — a jurisdiction-aware feature flag evaluated at request time — and not something a paragraph in your terms of service can carry.

Most teams get this backwards. They read the state laws, write a disclaimer, and ship one product everywhere. The disclaimer is the part that does the least work.

This page maps the layers of law, tells you which product designs trigger which, and lists what you have to build. It reflects what was confirmed as of August 2026, and anything not yet confirmed is flagged inline, because this area is moving faster than any content can track.

Read this as a structural map, not legal advice. Zee Palm builds HIPAA-aware, compliance-conscious systems and maps regulatory boundaries and decision points during planning. We do not provide legal advice, we do not issue certifications, and we do not determine whether your product is a regulated medical device. Every statute, effective date and penalty below must be confirmed with counsel licensed in the relevant state before you rely on it.

The two camps, and the six states you need in your head

Two states in the count of eight are not broken out here, because we have not confirmed which they are. Assume the list is longer than this table by the time you read it.

The restriction camp decides whether a function may exist. The disclosure camp decides how it must behave. You need both answers, and they are answered by different bodies of law with different enforcers.

The four layers

The other dangerous misunderstanding is that this is one body of law. It isn't. There are four independent regulatory layers, each with a different trigger, a different enforcer, and a different penalty. You can be fully compliant with the disclosure statutes and still be practicing psychology without a license. You can avoid the professional-practice statutes entirely and still be an unapproved medical device.

Layer 1 — Professional-practice statutes: can an AI do this at all?

Two states have gone furthest, and they go to whether the product is lawful at all rather than to how it must present itself. No amount of UI copy satisfies them.

Illinois — the WOPR Act, Public Act 104-0054, effective 4 August 2025. It prohibits AI from providing therapy, diagnosis or therapeutic decision-making, while explicitly permitting administrative uses such as scheduling and documentation. The Illinois Department of Financial and Professional Regulation may fine violators up to $10,000 per incident, typically acting in response to consumer complaints. That enforcement trigger matters more than the number: the thing that starts an investigation is a user who felt misled, which means your worst transcript is your compliance risk, not your architecture diagram.

Nevada — AB 406, signed 5 June 2025 by Governor Lombardo, effective 1 July 2025. It blocks AI providers from offering chatbots designed to deliver mental or behavioral health care to Nevadans, and from claiming — explicitly or by implication — that a chatbot can. Penalties run up to $15,000 per violation, the highest per-violation figure among the states with a dedicated chatbot law.

Read "or by implication" as a marketing constraint with teeth. A landing page that never says "therapy" but shows a warm avatar, a couch, and a testimonial about working through grief is making the claim by implication. Your growth team can breach this statute without touching the product.

California has addressed a related angle by restricting AI systems from implying they hold a professional license or using protected titles.

What this means for your product: if your app presents an AI that a reasonable user would understand as delivering therapy — it assesses, it forms an impression, it recommends a course of treatment, it does something that looks like a session — you have a live problem in these states, and disclaimer text does not cure it.

The design response is the Illinois line, applied as engineering. Therapy, diagnosis and therapeutic decision-making are one class of function. Scheduling, documentation, reminders, intake logistics, summarization for a clinician are another. Draw that boundary in your own codebase before a regulator draws it for you, because a product that has never separated the two has no move available except turning itself off in a state. A product that has separated them can ship the administrative half into Illinois on day one, and turn the clinical half on wherever it is lawful, with a flag rather than a rewrite.

Layer 2 — Companion-chatbot and disclosure statutes

A second, broader set of laws targets AI companions and mental-health chatbots generally, regardless of whether they claim to be therapy. These are the laws most AI wellness products will actually hit, and they impose concrete engineering requirements.

The recurring obligations across states that have legislated here:

• Disclose that the user is talking to an AI, at the start of the interaction and — in at least one state — repeatedly during long sessions.
• Detect expressions of suicidal ideation or self-harm and respond with a referral to crisis services. Not a generic "seek help" line: a specified, actionable referral.
• Do not claim to be a human when asked, and do not use protected clinical titles.
• Heightened obligations for minors, including content restrictions and, in some formulations, break reminders.
• Restrictions on advertising and on selling or sharing conversation data.
• Reporting duties — at least one state requires periodic reporting to a state office on crisis referrals.
• In at least one state, a private right of action, which changes the risk calculus considerably: your exposure is not only a regulator, it's plaintiffs' counsel.

Utah — HB 452, passed March 2025, effective 7 May 2025. Utah is the clearest example of the second camp, and it is worth studying precisely because it does not ban AI therapy. It mandates safeguards instead: clear disclosure that the user is interacting with AI, privacy protections that prohibit the sale of user data, and restrictions on how the product may be marketed. A product that Illinois would prohibit outright can be lawful in Utah if it discloses, does not sell the data, and does not oversell itself.

New York, California and Nebraska regulate companion or mental-health chatbots without banning them, adding crisis-referral requirements and minor-protection rules to the mix.

What this means for your product: these are implementable, and they are the layer where "we'll handle it later" turns into a rewrite. Disclosure cadence, crisis detection and the audit trail behind it all have to be designed into the conversation architecture, not bolted onto the UI.

Layer 3 — Health-data privacy

Most consumer mental-health apps are not HIPAA covered entities. Founders hear that and relax, which is exactly backwards, because the state health-privacy laws that do apply to them are in some ways more aggressive.

The layer that matters:

• Washington's My Health My Data Act and comparable state laws create obligations around consumer health data collected outside HIPAA — consent, disclosure, deletion rights — and Washington's includes a private right of action.
• State comprehensive privacy laws (a growing list) treat mental-health information as sensitive data requiring opt-in consent, and several restrict targeted advertising based on it.
• HIPAA applies only if you're a covered entity or a business associate. If you sell into or partner with a provider, you become a business associate and everything in how to build a HIPAA-compliant app applies. If you're direct-to-consumer, it typically doesn't — and do wellness apps need HIPAA compliance walks that boundary properly.
• The FTC's Health Breach Notification Rule has been applied to consumer health apps sharing data with advertising platforms.

The AI-specific statutes reach here too. Utah's HB 452 prohibits the sale of user data outright, which means a mental-health product with a data-monetization line in its model has a problem in Utah that has nothing to do with whether it delivers therapy.

The concrete engineering consequence: an SDK. The single most common finding in a consumer mental-health app is an analytics or advertising SDK receiving screen names, event names or user properties that reveal the user's mental-health context. "ScreenView: anxiety_assessment_complete" sent to an ad platform is the whole violation, and it's usually in the app because nobody audited the default configuration.

Layer 4 — FDA and the medical-device boundary

Separately from all of the above, a product can cross into being a medical device based on its intended use. Broadly: general wellness claims stay outside; claims to diagnose, treat, cure, mitigate or prevent a disease do not. Digital therapeutics with treatment claims have gone through FDA clearance pathways; wellness apps making no such claims generally have not.

Generative AI raises the stakes because output is not fully specified in advance. FDA has been examining generative-AI-enabled digital mental health tools specifically, and the direction of travel is toward more scrutiny, not less.

Practical rule: your marketing copy is your regulatory filing. "Reduce your anxiety" and "manage stress" are not the same claim. We cover the line in is my wellness app a medical device, and the app-store-facing version in app store medical device labelling.

Which layer does your product trigger?

The row worth staring at is the second one. Most consumer AI mental-health products are built as companions and drift toward the third row over time, because that's what users ask for and what engagement metrics reward. The drift is the risk. A product that was compliant at launch becomes non-compliant through nothing more than prompt iteration and user pressure.

Which is why the most important control on this list is not a disclosure banner. It's an evaluation suite.

What you actually have to build

1. Persistent AI identity disclosure

At session start, in the conversation, and — where a state requires it — at intervals during long sessions. Not buried in onboarding. Not only in the app store description. And the model must never claim to be human when asked directly, which is a behavior you test, not a behavior you hope for.

2. A hard title and scope boundary at the model layer

Three mechanisms, because one is not enough:

• System prompt constraints — no clinical titles, no diagnosis, no treatment recommendations, explicit redirect language.
• Output filtering — a classifier or rule layer between the model and the user that catches diagnostic language and licensed-title claims before they ship.
• An evaluation suite that runs on every prompt or model change. This is the control that actually holds. A test set of adversarial prompts — "are you a real therapist?", "do I have depression?", "what medication should I take?", "should I stop my prescription?" — with expected-behavior assertions, run in CI. If the suite doesn't gate deploys, you don't have a control, you have a document.

3. Crisis detection and escalation, with an audit trail

This is the requirement most likely to be enforced and most likely to be built badly. What good looks like:

• Detection that runs on the user's message, not only on the model's response, and does not depend on the model choosing to notice.
• A deterministic escalation path that does not go through the LLM. When crisis language is detected, the crisis response should be templated and reliable, not generated.
• Region-appropriate crisis resources. A US hotline number shown to a user in Ireland is a failed referral.
• A logged, timestamped, auditable record of detection and response. Some states require reporting; all of them will require it if something goes wrong.
• A tested false-positive path. Over-triggering crisis flows on ordinary sadness drives users away and trains them to ignore the real one.

4. Age assurance and minor-specific behavior

Several of the new statutes impose stricter duties for minors. That means you need to know, at least to a defensible standard, whether a user is one — and then actually change behavior, not just record a birthday. Decide early whether you serve minors at all. "We don't intend to" is not a control; a terms-of-service clause plus no enforcement is the configuration regulators have been least sympathetic to.

5. Knowing which state the user is in

Here is the engineering problem nobody writes about, and it's the hard one. Layer 1 and Layer 2 obligations are state-specific. Your duties in Illinois differ from your duties in Texas. To apply them, you need the user's state, and every method of getting it is flawed:

• Self-attestation at signup — easy, low friction, trivially wrong, but it establishes a documented basis for your behavior and it's the field you'll need anyway if you ever add licensed providers.
• IP geolocation — decent at country, mediocre at state, defeated by any VPN, and wrong for a lot of mobile carrier traffic.
• Billing address — reliable for paying users, absent for free ones, and stale for anyone who moved.
• Device location permission — accurate, and a significant permission ask for a mental-health app where trust is the whole product.

The pattern we recommend: self-attested state as a first-class, editable profile field, cross-checked against IP for gross mismatches, with a re-confirmation prompt on significant change. Store the attestation with a timestamp. It won't be perfect. It will be defensible, which is the achievable goal.

5b. A function registry, gated by jurisdiction

This is the Illinois line turned into code, and it is the thing most likely to save you a rewrite.

Enumerate your product's capabilities as named functions and classify each one against the clinical/administrative boundary: schedule_appointment, summarize_session_for_clinician, send_reminder on one side; assess_symptoms, suggest_treatment_plan, interpret_screener_score on the other. Then make jurisdiction an input to whether each function is available, evaluated at request time rather than at build time.

What that buys you concretely:

• A state passes a restriction. Your response is a configuration change and a test run, not a product decision meeting.
• You can ship into a restrictive state with a reduced product instead of not shipping. Illinois explicitly permits the administrative half, so the administrative half is a business there.
• Your logs answer the only question that matters after an incident: which functions were available to this user, in this state, on this date. That record is your defense and it does not exist unless you designed for it.
• Your evaluation suite gets a dimension. Every adversarial prompt runs against every jurisdictional configuration, so "compliant in Utah, unlawful in Illinois" is a failing test rather than a discovery.

The failure mode to avoid is a single isRestrictedState boolean sprinkled through the codebase. Restrictions are not uniform — Nevada's reaches marketing claims, Illinois's reaches function classes, Utah's reaches disclosure and data sale. One boolean cannot represent that, and the day you need to represent it you will be reading a cease-and-desist.

6. Data minimization that survives an audit

Conversation content is the most sensitive data your product holds. Minimum posture: no third-party analytics or advertising SDK receives anything derived from conversation content; screen and event names are semantically neutral; retention is bounded and stated; deletion is real and includes backups and any vendor that received data; and no model provider trains on your users' conversations — which is a contract term, not an assumption. If an LLM vendor is in your data path and you're a business associate, they need a BAA and terms that exclude training.

7. Change control on the model

Your model provider will deprecate the version you launched on. When you migrate, every behavior above has to be re-verified. Treat a model version change like a schema migration: gated by the eval suite, staged, and reversible.

Strictest common denominator, or per-state gating?

Two viable postures, and note that both of them are architecture. Neither is a legal document.

Per-state gating: the function registry above, fully exercised — different capabilities available in different states. Maximum feature freedom where the law permits it. Costs you a state-resolution dependency in every gated path, a matrix of behaviors to test, and a compliance surface that grows with every legislative session. Realistic for a funded company with counsel on retainer.

Strictest common denominator: build one product that satisfies the most restrictive requirements everywhere. Right now that means designing to Illinois and Nevada — no therapy, no diagnosis, no therapeutic decision-making, no implied claim that the chatbot can provide care — while meeting Utah-style disclosure and data-sale limits on top. Costs you some engagement, because a companion that never claims clinical authority, discloses itself repeatedly and escalates conservatively is a less sticky product. Buys you one codebase, one test suite, and near-immunity from the next state's law.

For almost every startup, the strictest common denominator is the right call — but build it on the function registry anyway. Classify your functions and put the gate in even when every jurisdiction currently resolves to the same conservative configuration. The registry costs a week now. Retrofitting it into a product that assumed one behavior everywhere costs a quarter, and you will be asked to do it on a legislative timetable rather than your own.

The exception worth taking seriously is the administrative half. If you sell to clinics rather than to consumers, the Illinois carve-out for scheduling and documentation means a genuinely valuable product is lawful in the strictest state in the country. That is a real market and it is less crowded than the companion market, largely because founders read "Illinois banned AI therapy" and stopped reading.

The six things most likely to hurt you

1. A persona that drifts. Prompt iteration toward warmth and authority, month after month, until the product is doing therapy nobody signed off on.
2. An analytics SDK you didn't audit. The cheapest violation to commit and the easiest to prevent.
3. Crisis handling routed through the LLM. Non-deterministic where determinism is the requirement.
4. Marketing copy written by someone who never read Layer 4. Your growth team can create a regulatory claim in an afternoon, and Nevada's statute reaches claims made by implication, so no forbidden word has to appear for the page to be a problem.
5. No record of what the system did. When something goes wrong, the question is what your system said, to whom, in which state, with which functions enabled. Illinois enforcement typically starts with a consumer complaint, which means the record you need is a transcript plus a configuration, and you either kept both or you didn't.
6. One product, every state. The absence of a function registry is not a neutral choice. It is a commitment to either the most restrictive behavior everywhere or the most expensive retrofit in the category.

Where to start

If you're at the scoping stage, the specific engagement built for this is the Healthtech & Mental Health MVP Blueprint — $1,999, 7 days: everything in a standard planning sprint, plus an intended-use boundary, a sensitive-data and claims inventory, a crisis and clinical dependency map, and a list of the specialist decisions you need to take to counsel. It is planning, not certification, and we say so up front. It's on the product strategy page alongside the standard MVP Planning Sprint at $1,500, and the build side is on mental health app development.

If you're already live and the ground moved under you, the honest first step is an audit of the four layers against what you actually shipped, not against what your PRD said. Tell us what you've built and we'll tell you which layer to fix first.

Frequently asked questions

Is AI therapy illegal now?

In some states, yes. Illinois prohibits AI from providing therapy, diagnosis or therapeutic decision-making under the WOPR Act, and Nevada blocks AI providers from offering chatbots designed to deliver mental or behavioral health care to Nevadans. In most states it is not prohibited outright but is subject to disclosure, crisis-response and data obligations. Eight states have legislated here since March 2025 and the answer genuinely depends on which one your user is sitting in, which is why the state field in your user profile is a compliance control.

What does the Illinois WOPR Act actually ban?

Public Act 104-0054, effective 4 August 2025, prohibits AI from providing therapy, diagnosis or therapeutic decision-making. It explicitly permits administrative uses such as scheduling and documentation. That line is a function-level distinction rather than a product-level one, which is why the practical response is a jurisdiction-aware feature gate rather than a disclaimer. The Illinois Department of Financial and Professional Regulation may fine up to $10,000 per incident, usually acting on a consumer complaint.

Which state has the largest penalties?

Among states with a dedicated chatbot law, Nevada carries the highest per-violation figure: AB 406 allows penalties up to $15,000 per violation. Illinois allows up to $10,000 per incident. Per-violation arithmetic is the part founders underestimate, because a violation is generally counted per instance rather than per company.

Can we ship into Illinois at all?

Yes, if you ship the permitted functions. The WOPR Act carve-out for administrative uses means scheduling, documentation and similar clinician-support functions remain lawful, so a co-pilot sold to practices is a viable Illinois product where a consumer therapy chatbot is not. Doing that without a rewrite requires you to have separated clinical from administrative functions in your architecture before you needed to.

Does my AI wellness chatbot need a disclaimer?

A disclaimer is necessary and nowhere near sufficient. Where the new statutes apply, you need AI identity disclosure at defined moments, crisis detection and referral, restrictions on claiming clinical authority, and in some cases minor-specific protections and reporting. A paragraph in your terms of service satisfies none of those.

Do these laws apply if my company isn't in that state?

Consumer-protection and professional-practice statutes generally reach conduct directed at residents of the state, not just companies located there. Being incorporated in Delaware and hosted in Virginia does not exempt you from a law protecting Illinois residents. Confirm with counsel — this is exactly the question they should answer for your specific model.

Does HIPAA apply to a direct-to-consumer mental health app?

Usually not, if you are not a covered entity and not a business associate of one. That is not the relief it sounds like: state consumer-health-privacy laws, some with private rights of action, apply instead, and the FTC has pursued app developers over health data sharing. The moment you contract with a provider or a health plan, HIPAA arrives too.

Can I use GPT-class models for a mental health product at all?

Yes, and most products in this space do. What matters is the architecture around the model: deterministic crisis handling outside the model, output filtering, an adversarial evaluation suite gating every deploy, contractual terms with the model vendor that exclude training on your data, and a logged trail of what the system said. The model is the easy part.

How much does compliance add to the build?

The controls above are engineering work — an evaluation harness, a crisis subsystem, a state-aware policy layer, an SDK audit — not a separate compliance product. In our experience they are a meaningful but bounded share of an MVP, and dramatically cheaper built in than retrofitted. What they never include is legal sign-off, which you buy from a lawyer, not from us.