Does Your Chatbot Have to Say It's AI?

In most US states there is no general law requiring a business chatbot to announce that it is AI. Four states regulate it, and the useful thing to know is that none of them share a trigger. Maine requires notice whenever a reasonable consumer could be fooled. Utah requires a truthful answer when the customer asks. California only bites when a bot is used to deceive someone into a purchase or a vote. Colorado's rewritten law, in force January 1, 2027, attaches to automated systems that drive a consequential decision.

That difference matters more than the state list, because a disclosure banner satisfies exactly one of the four. The other three are things your bot has to do at runtime.

This is a description of what the statutes say as of July 2026, not legal advice. Rules in this area moved twice in the last twelve months alone.

The four laws and what actually triggers each one

State	What triggers the duty	What satisfies it	In force
Maine (10 M.R.S. 1500-DD)	Using a chatbot in trade or commerce in a way that may mislead a reasonable consumer into believing they are talking to a human	Clear and conspicuous notice that the consumer is not engaging with a human being	Since September 2025
Utah (AI Policy Act, SB 149 as amended by SB 226)	The consumer makes a clear and unambiguous request to know whether they are dealing with AI. Separately, proactive disclosure for high-risk interactions by state-licensed occupations	A truthful answer at the moment of the question. Up-front disclosure in the high-risk case	Amendments effective May 2025
California (SB 1001)	Using a bot with intent to mislead about its artificial identity, to incentivize a sale or influence a vote	Disclosing that it is a bot, which is written as a safe harbor from liability	Since July 1, 2019
Colorado (SB 26-189)	Automated decision technology used in a consequential decision	Clear and conspicuous notice at points of consumer interaction, plus an understandable explanation within 30 days of an adverse outcome	January 1, 2027

Read the trigger column top to bottom and the design implication falls out. Maine is a notice requirement. Utah is a conversational behavior. California is an intent standard. Colorado is a logging and explanation requirement. Only the first one is a banner.

Maine's is the one to build to. It has no company-size threshold, no intent element, and a violation is a violation of the Maine Unfair Trade Practices Act, with the Attorney General able to seek civil penalties. If your funnel accepts customers from anywhere in the US, you cannot reliably know that the person in the chat window is not in Portland.

The California law everyone cites is probably not your constraint

Search for chatbot disclosure law and you will get California SB 1001, usually described as requiring businesses to tell users they are talking to a bot. That description is too broad in two directions.

First, the prohibition has an intent element. The statute makes it unlawful to use a bot "with the intent to mislead the other person about its artificial identity for the purpose of knowingly deceiving the person about the content of the communication in order to incentivize a purchase or sale of goods or services in a commercial transaction or to influence a vote in an election." A support bot that answers shipping questions without pretending to be Karen from customer service is not doing that.

Second, the law is scoped through a definition of "online platform" that means a public-facing site or application with 10,000,000 or more unique monthly United States visitors for a majority of the preceding twelve months. Commentators read that threshold as keeping the law off small business websites, which was the stated intent. Where it gets read more broadly is for bots that a business operates on someone else's large platform, since the size carve-out was aimed at platform providers rather than everyone using them.

So the practical takeaway inverts the usual advice. The famous law is the one least likely to bind a small or mid-sized operator. The quiet one from Maine, with no threshold and no intent test, is the one that sets your build. Disclosure is cheap enough that arguing about SB 1001's scope is not worth an hour of anyone's time.

What a banner does not cover

Here is where most compliance write-ups stop and most real builds break. Five failure modes we have hit or designed around.

The bot that denies being a bot. Utah's trigger is the customer asking directly. If your system prompt says to be warm, personable, and to stay in character as a member of the team, the model will do exactly that when someone types "wait, am I talking to a real person?" A friendly persona instruction and a truthful-disclosure obligation are in direct conflict, and the persona usually wins because it is the more specific instruction. Fix it in the prompt with an explicit override, and test that exact question as a case before launch.

The silent handoff back. A live agent takes over a conversation, resolves the hard part, and the session returns to the bot for follow-up. The customer's belief about who they are talking to is now stale, and they formed it from a human's messages. This is precisely the "may mislead a reasonable consumer" scenario Maine describes, and the opening banner did nothing about it because the conversation changed underneath it. Re-disclose on every transition back to automated handling.

The channel jump. Your widget shows the disclosure. Then the bot sends the follow-up by SMS, or emails the quote, or places a callback. None of those carry the widget. Each channel needs its own disclosure at the point of contact, and for outbound voice or text it belongs at the start of the message, not appended at the end where it arrives after the persuasion.

The bot that is only sometimes a bot. Hybrid queues where automation drafts and a human approves, or where the bot handles nights and humans handle days, produce a conversation whose nature changes by hour. Whether disclosure is required depends on what is actually generating the message being sent, so the disclosure has to be driven by the same flag that routes the message. If you are already building an approval step, this is the natural place to attach it. Our write-up on when an automation should require human approval covers the routing side of that.

No record to explain the decision. Colorado's replacement law drops the algorithmic discrimination duty from the original AI Act but keeps a consumer-facing obligation: after an adverse outcome from a covered automated decision, an understandable explanation within 30 days. You cannot write that explanation a month later from a chat transcript alone. You need the inputs, the model and prompt version, and the decision the system reached, which is the same run record that makes any automation debuggable. Our 8-field run record is a reasonable starting shape.

The common thread: disclosure is a state variable in your system, not a line of copy. It has a value at every turn of the conversation, it changes at handoffs and channel boundaries, and something has to be responsible for keeping it true.

What to build

Five things, none of which take long.

1. Disclose on first message in every channel, in the message body, in the same font as the surrounding text. Not in a tooltip, not in the privacy policy, not below the fold.
2. Add an explicit prompt rule that the bot must confirm it is an AI assistant whenever asked, and that this rule outranks any persona instruction. Add "are you a real person?" to your test set.
3. Re-disclose whenever control returns from a human to the bot, and whenever the conversation moves to a new channel.
4. Log the disclosure state alongside the rest of the run record, so you can answer "what did this customer see, and when" without reconstructing it.
5. Skip the geo-gating. Conditionally disclosing based on a guessed location adds a failure mode and saves you nothing, because the compliant version is one sentence.

If your bot books appointments, moves money, or touches health or financial data, treat the bar as higher. Utah's high-risk category covers exactly that: interactions involving sensitive personal information plus personalized advice someone could reasonably rely on for a significant decision. The architecture for an appointment-booking bot is worth reading alongside this, because a bot that acts is a bot that creates records worth being able to explain.

Where to start this week

Open your bot's system prompt and ask it, in production, whether it is a real person. That single test tells you more about your exposure than any state-by-state chart, because it exercises the one obligation a banner cannot satisfy. If the answer is evasive, in character, or claims to be a person, fix that before you fix anything else.

Then check the two boundaries: what happens when a human agent hands the conversation back, and what the customer sees when the follow-up arrives by text instead of in the widget. Those are the two places we most often find the disclosure quietly missing.

If you want the disclosure logic and the run record built into a bot rather than bolted on afterward, that is the kind of thing we handle in custom software platforms, or you can tell us what your bot does today and we will tell you which of the five items above you are missing.