AI Chatbot Compliance for Businesses: The Rules a Website Bot Can Trigger and How to Design for Them

What chatbot compliance means in practice

No single US law governs business chatbots. A chatbot instead inherits the obligations attached to four things: what it tells people, the personal data it collects, who is on the other end and what happens after the conversation. Compliance means deciding each of those deliberately instead of discovering them after launch.

Put four questions to any bot you run or plan to run:

• What does it say? Every answer about prices, services, policies or availability is a statement by your business, subject to the same consumer-protection rules as your advertising.
• What does it collect? Names, phone numbers and free-text messages are personal information under state privacy laws, and some categories are regulated far more tightly.
• Who is it talking to? Patients, borrowers, children and visitors from places with specific AI rules change what is required.
• What does it trigger? Follow-up texts, calls and emails bring consent and opt-out duties that the chat window alone does not.

The compliance map: rules a business chatbot can trigger

The table pairs each area of law with the moment a chatbot runs into it and the design response we build in. Not every row applies to every business; the point is to know which ones apply to yours.

Disclosure: say it is software before anyone asks

Several states now expect businesses to tell people when they are dealing with a bot. California’s bot disclosure law covers bots used to encourage a purchase or influence a vote and requires the disclosure to be clear and conspicuous. Utah has its own AI disclosure requirements, and the EU AI Act adds transparency duties for systems that interact with people. The details differ, and new bills keep appearing.

The practical response is to stop tracking which visitors are covered and disclose to everyone. It costs nothing and removes a whole category of risk. Good disclosure has four parts:

• A plain opening line, such as You’re chatting with our automated assistant; a team member can take over at any time.
• A name that doesn’t pretend otherwise. A human first name beside a stock photo invites exactly the confusion these laws target; Harbor Supply Assistant does not.
• An honest reply to am I talking to a real person? Test that exact question, because some models will play along with a persona unless instructed not to.
• A visible handoff, so the visitor knows when a human has joined.

Whatever the bot says, the business has said

In 2024 a Canadian tribunal ordered Air Canada to compensate a passenger who had relied on its website chatbot’s incorrect description of the bereavement-fare policy, and it rejected the argument that the bot was responsible for its own words. The decision is Canadian, but the reasoning travels: customers treat your chatbot as your business speaking. In the US, the FTC and state attorneys general police deceptive statements regardless of whether a person or software made them.

Design choices that keep a bot’s statements defensible:

• Answer only from approved content. The bot retrieves from your policies, service pages and a maintained FAQ instead of improvising from general model knowledge.
• Keep volatile facts in one place. Prices, hours, service areas and promotions belong in a single source one person updates, not in instructions pasted months ago.
• Forbid commitments. No discounts, guarantees, refunds, delivery dates or contract terms unless a human confirms them.
• Fence off professional advice. A law firm’s bot can explain how to book a consultation, not whether someone has a case. Medical, tax and investment questions get the same boundary.
• Make handing off acceptable. A bot that says it isn’t sure and passes the question on is safer than one that guesses fluently.
• Keep a risky-question test list and rerun it whenever the content or model changes.

Personal data: collect less, keep it shorter, know where it flows

Start by drawing the data flow. A typical chat touches the widget provider, the AI model provider, your CRM, an email or texting service and sometimes an analytics tool. Each hop stores personal information, and each vendor’s terms decide how long it stays and whether it trains anyone’s models.

1. Collect the minimum. If a name and callback number are enough, don’t ask for a home address or date of birth just in case.
2. Give notice. Link your privacy notice from the chat window and describe chat data in it. Laws such as California’s CCPA/CPRA and the Texas Data Privacy and Security Act expect notice, and several state laws require consent before sensitive categories of data are processed.
3. Be able to find and delete it. When someone exercises a privacy right, you must locate their transcripts in every system above, not only the CRM.
4. Set retention on purpose. Configure how long transcripts live in each system rather than inheriting a vendor default of forever.

One risk is easy to miss. Plaintiffs’ firms have filed many suits, a large share under California’s Invasion of Privacy Act, arguing that third-party chat vendors eavesdrop on website conversations. Common mitigations include a clear notice at the start of the chat that conversations are recorded and handled by service providers, and vendor contracts that restrict what those providers do with the data. Ask your attorney to review your specific setup.

Regulated information: health, financial, children’s and card data

Health information

For healthcare providers, health plans and their vendors, conversations linking a person’s identity to their care are likely protected health information under HIPAA. Every vendor that stores or processes it, including the chat platform and the AI model provider, must sign a business associate agreement, and many consumer-grade AI tools will not. The workable designs are a stack where every vendor signs, or a bot kept strictly out of clinical territory that sends anything health-related to a secure channel the practice already uses.

Financial information

Lenders, mortgage brokers and other non-bank financial businesses fall under the Gramm-Leach-Bliley Act and the FTC’s Safeguards Rule, which call for a written information security program and oversight of service providers. A bot that collects income, account or loan details belongs in that program and its documentation.

Children

COPPA restricts collecting personal information from children under 13 on child-directed sites, or once you know you are dealing with a child. A general-audience bot shouldn’t ask for age at all, but if a user says they are a child, it should stop collecting details and suggest involving a parent.

Payment cards

Card numbers never belong in a chat window. Transcripts get stored, forwarded and read by staff, which drags them into PCI DSS scope. Send customers to a hosted payment page, and redact anything shaped like a card number in case someone types one anyway.

After the chat: consent before any automated follow-up

Conversations often end with a promise to follow up, which is where many compliance problems begin. Under the Telephone Consumer Protection Act, marketing texts and calls made with automated systems generally require the recipient’s prior express written consent, and violations carry statutory damages per message. Several states, including Florida and Oklahoma, layer their own telemarketing rules on top. In a chatbot, that becomes four mechanics:

• Ask for permission to text or call as a separate step, with wording that names your business and the kind of messages, never bundled into the quote request.
• Store the consent record: the exact wording shown, the timestamp, the page and the phone number.
• Configure the CRM so no contact enters an automated sequence without that record.
• Honor STOP and similar replies in every tool that can send messages, not only the one that received the reply.

Marketing email follows CAN-SPAM: honest subject lines, a working unsubscribe, a physical postal address and prompt handling of opt-outs. Answering the question someone asked is different from adding them to a newsletter, and the bot should never blur the two.

Accessibility: a chat window everyone can operate

A chat widget is part of your website, and ADA-based suits over inaccessible sites are common in the US. The Web Content Accessibility Guidelines (WCAG) at level AA are the usual benchmark. Plenty of off-the-shelf widgets fall short, so test yours rather than assuming:

• The launcher and every control inside the chat work with a keyboard alone.
• Focus moves into the window when it opens and returns to the launcher when it closes.
• New messages are announced to screen readers through a live region.
• Text and buttons meet contrast requirements, and the window still works at 200% zoom and on small phones.
• The widget never opens by itself and steals focus from someone reading the page.
• A phone number or form remains available for anyone who can’t or won’t use chat.

Logs, ownership and the paper trail

When a customer disputes what the bot said, or a regulator asks how chat data is handled, your logs are the evidence. Plan them before launch: timestamped conversation records kept for the retention period you chose; the version of the instructions and knowledge base live at the time; consent records and opt-outs stored separately from transcripts that may be deleted sooner; handoffs and their outcomes; and redaction of card numbers, government ID numbers and passwords before anything is saved.

Then name an owner. That person samples transcripts on a fixed schedule, updates content the day a policy changes and holds a short written plan for a bot mistake: correct the source, contact affected customers where needed and record the fix.

Worked example: a compliant chatbot for a four-location dental group

Imagine a dental group with four offices that wants a website chatbot to answer questions about locations, hours, accepted insurance and new-patient steps, and to take appointment requests. The compliance decisions shape the build like this:

• HIPAA first. An appointment request ties a named person to a dental practice, so the group’s compliance officer treats it as protected health information. The chat platform, model service and hosting are chosen from vendors that sign business associate agreements, with data retention set to the shortest option offered.
• No clinical conversation. The bot never asks about symptoms. If a visitor describes pain, it gives the office number, directs anyone with a severe problem to urgent care or emergency services, and assesses nothing.
• Minimal fields. Name, phone, preferred office, new or existing patient and preferred times. Requests go directly into the practice-management system’s queue and are purged from the chat platform after transfer.
• Insurance answers with a caveat. Accepted plans come from a list the front-desk manager maintains, and every answer notes that the office confirms coverage before the visit.
• Reminders with consent. Text reminders go only to patients who opted in under recorded wording, and STOP is honored across reminder and marketing tools alike.
• Disclosure, accessibility and sign-off. The first line says the assistant is automated, the widget passes keyboard and screen-reader testing, and the compliance officer and attorney review a written data-flow diagram before launch.

None of these choices made the bot less helpful. They made it narrower exactly where a mistake would be expensive.

How EVOTECH builds compliance into a chatbot project

Working remotely from the Houston area, EVOTECH IT LLC designs, builds and integrates chatbots for businesses across the US; the company has operated for over 20 years and is rated 5.0 on Google. We treat compliance as a design input, not a review bolted on at the end:

1. Discovery on a free call. Your industry, where your customers are, what the bot should do and which systems it feeds.
2. A data-flow diagram showing every system that will see chat data, what it keeps and for how long.
3. Vendor selection on contract terms. Training opt-outs, retention settings and, where required, business associate agreements.
4. Guardrails in the build. Approved-content answers, forbidden commitments, disclosure text, consent capture and redaction.
5. Pre-launch testing. Accessibility checks plus a risky-question set rerun after every change.
6. A review pack for your counsel describing in plain language what the bot collects, says and triggers.

You receive a fixed-scope written quote after the consultation. For protecting the systems themselves, see our chatbot security best practices, or start with our AI chatbot services. Call (832) 359-2425.

Related services

Frequently asked questions