When a Customer-Service Bot Has to Say It Is a Bot

Consider one returns workflow. A retailer’s website has a chat bubble labeled “Support.” It asks for an order number, generates answers from the return policy, offers store credit and, if the customer objects twice, places an outbound callback using a synthetic voice. A human takes over only when the bot cannot authenticate the order.

That ordinary setup crosses several legal boundaries. The first chat may be routine service, the store-credit offer can become a sales interaction, and the callback invokes telephone rules that do not apply to the website. If the retailer records the call or keeps a transcript for model training, separate consent and privacy questions appear.

The practical mistake is to put one “AI disclosure” switch in the settings screen. The retailer needs a policy engine, meaning code that selects a rule from facts about the interaction, plus a fallback for facts it cannot determine. This is a product checklist, not legal advice; state amendments, sector rules and specific facts still need review.

The federal baseline is not a universal introduction

No generally applicable federal law currently says that every commercial chatbot must open with “I am an AI.” Federal consumer-protection law still matters. The Federal Trade Commission can challenge unfair or deceptive conduct under Section 5 of the FTC Act, and hiding automation could contribute to deception when the interface, language or surrounding claims lead a reasonable customer to believe a person is speaking.

That is a context test, not a mandatory script. A chat window labeled “Automated assistant” is easier to defend than a named agent with a stock portrait, typing pauses and statements such as “I checked with my manager.” The underlying model may produce those phrases without anyone designing an explicit impersonation feature, which is why teams need to test outputs rather than inspect the label alone.

The FTC’s Business Impersonation Rule also prohibits materially and falsely posing as a business or misrepresenting affiliation with one. It does not turn every undisclosed company chatbot into a violation. It becomes relevant when a system falsely presents itself as another company, such as a bank, delivery carrier or government office, rather than merely failing to identify its automated nature.

Proposed federal bills, agency consultations and voluntary AI frameworks may recommend broader transparency. They are not the same as an enforceable disclosure duty. Procurement requirements can bind a government contractor through its contract without establishing a rule for every private customer-service deployment.

State rules change the answer inside the same chat bubble

California’s BOT Act is narrower than its name suggests. It makes certain online bot use unlawful when a person intends to mislead someone in California about the bot’s artificial identity, knowingly deceives that person about the communication’s content, and does so to influence a commercial transaction or a vote. The statute provides a disclosure route when the disclosure is “clear, conspicuous, and reasonably designed to inform persons” that they are communicating with a bot.

Our returns bot may sit outside that fact pattern while it reports shipping status. The analysis changes when it proposes exchanging a refund for credit, recommends a replacement product or otherwise tries to influence a purchase. A tiny terms-of-service reference, placed away from the conversation, is a weak implementation of a requirement aimed at informing the person during the interaction.

Utah’s Artificial Intelligence Policy Act, enacted in 2024, uses a different structure. In a general commercial interaction, a person using generative AI must clearly and conspicuously disclose that use when the consumer asks or prompts for the information. For services connected to a regulated occupation, the enacted law requires prominent disclosure at the start of an oral exchange or before a written exchange. Teams should verify current amendments and whether their service falls within the law’s defined occupations.

Colorado’s enacted AI law contains a broader requirement for a deployer to tell a consumer that the consumer is interacting with an AI system unless that fact would be obvious to a reasonable person. That obligation was written for a future compliance date rather than immediate enforcement when enacted, and Colorado lawmakers have revisited the timetable. It should sit in the retailer’s implementation roadmap, with the operative date checked before launch, rather than being described as either a current nationwide rule or a discarded proposal.

A universal label can be cheaper than reliable state detection. IP location is imperfect, customers travel, phone numbers move, and a known shipping address may not describe where someone is chatting. Showing “Automated assistant” to everyone removes that routing failure, though the business may accept some loss of engagement from customers who would rather wait for a person.

An AI callback creates separate duties

Return to the callback. The Federal Communications Commission has confirmed that AI-generated voices count as “artificial or prerecorded voice” messages under the Telephone Consumer Protection Act. Depending on the call’s purpose, destination and relationship with the customer, the business may need prior consent; telemarketing calls generally face stricter consent requirements than nonmarketing service calls.

The FCC’s identification rule for artificial or prerecorded voice messages says the caller must:

“At the beginning of the message, state clearly the identity of the business, individual, or other entity that is responsible for initiating the call.”

That requires the responsible caller’s identity. It does not, by itself, use the words “artificial intelligence,” so “This is North Street Retail calling about your return” and “I am North Street Retail’s automated assistant” perform different compliance jobs. The second script is often the safer product choice where state AI disclosure rules or interface design make artificial identity material.

Recording is another switch. States differ on whether one participant or all participants must consent to recording, and an interstate call can create a choice-of-law problem. The recording notice should run before audio capture where required; disclosing after authentication may be too late. Transcribing the call, retaining the text, sending it to a model vendor and using it to improve a model also raise privacy and contract questions that the spoken bot label does not answer.

The retailer should therefore preserve separate fields for permission to place an artificial-voice call, disclosure of the responsible business, disclosure that the agent is automated, and consent to recording. Combining them into one database flag makes it hard to prove what the customer agreed to and almost impossible to change one script without disturbing the others.

A decision checklist for the support workflow

Map the interaction before choosing words. Record whether the bot answers inbound chat, initiates messages, places calls or hands conversations between channels. Mark where it makes offers, collects payment, discusses a regulated product or communicates a decision affecting the customer. “Customer service” is an internal department name, not a legal category.

Determine which location rule will control. Use the best available customer location, but document its confidence and choose a fallback. A nationwide disclosure is usually easier to operate than state-specific suppression; jurisdictional routing may reduce disclosure friction, but it adds testing work and creates errors at state borders or when location data is missing.

Place the disclosure where the customer encounters the system. For the chat bubble, label the launcher and repeat the point in the opening message if the label can disappear on mobile. For voice, put the business identity and automated-agent statement at the beginning, before the model starts authentication or delivers an offer. Do not rely on a privacy policy link to repair a human-looking interface.

Separate service from promotion. The returns bot should detect when a generated response moves from explaining an existing order to encouraging another purchase. That transition can activate a state bot law or stricter calling rule even though the conversation began as support. The safe fallback is to disclose before presenting the offer, or transfer to an approved flow whose script and consent status are known.

Design a real human handoff. U.S. law does not give every customer a general right to a human agent, but industry rules, contractual promises and complaint-handling duties may require a person to review particular disputes.

The interface should state whether live help exists, preserve the transcript, transfer authentication results, and report an honest wait estimate rather than letting the model claim that no supervisor is available.

The retailer’s “two objections” trigger is too crude for that job. A customer reporting fraud, disputing a debt or requesting an accommodation should not need to phrase the issue twice. Intent classification, where software assigns the conversation to a category, can route those cases earlier, but it will miss unusual wording; visible commands such as “human agent” provide a deterministic fallback.

Test the generated language, not only the opening script. Run conversations that ask whether the bot is human, request a manager, reject store credit and switch from chat to voice. The expected behavior should include a direct answer about automation, no invented human actions, and a transfer record. Model updates can change these answers even when the surrounding application code stays fixed.

Keep the receipt

For each version of the returns workflow, retain the disclosure text, where it appeared, the policy rule that selected it, the customer-location signal and the consent state used for a callback. Logs should also show when the conversation crossed into a promotional flow, when recording began, and whether the requested human transfer connected or failed.

That audit trail costs storage and engineering time, while a live handoff adds staffing expense and queue delay. The cheaper alternative is not zero cost. Without versioned receipts, a company facing a complaint may know what its current bot says but be unable to establish what the customer saw, heard or requested several months earlier.

Questions people ask

Does a website chatbot always have to identify itself as AI?

No general U.S. federal rule requires every website chatbot to do so. State law and deception analysis can change the answer when the interface is designed to look human, the bot is trying to influence a purchase, the customer asks directly, or the interaction concerns a regulated occupation.

Is saying the company name enough on an AI phone call?

Not for every purpose. FCC rules require an artificial or prerecorded voice message to identify the entity responsible for the call, but state AI rules or the surrounding presentation may also call for an automated-agent disclosure. Consent to receive the call and consent to recording remain separate issues.

Must a customer-service bot offer a human agent?

There is no broad U.S. right to human support for every transaction. A handoff may still be required by sector-specific duties, accessibility needs, contractual promises or the procedure governing a dispute, so teams should route those cases by issue type rather than waiting for the model to fail repeatedly.

What should the disclosure log contain?

Keep the exact text or audio played, its version, placement and timestamp, along with the policy rule, location signal, channel, consent status and later escalation attempts. For a generated conversation, retain enough output to show whether the bot answered identity questions accurately without collecting more customer data than the stated retention policy permits.