SMS Chatbot Privacy Policy: What to Include in Yours

Important: This is not legal advice, and this article is not a fill-in-the-blanks template you can paste into your site. It is a checklist of what your SMS chatbot privacy policy needs to address, and why each item matters. Laws change, carriers update their rules, and your bot collects different data than your neighbor’s. Have a lawyer draft or at least review the final policy before you publish it.

Checklist of ten items every SMS chatbot privacy policy should cover, from data collection and AI disclosure to retention and opt-out rights.
A chatbot privacy policy should cover what data is collected, how AI processes it, how long it is kept, and how users opt out.

Why a chatbot privacy policy is not just a website policy

Most businesses already have a privacy policy on their website. That document talks about cookies, forms, and email signups. Then they add a chatbot that texts people, and suddenly the policy is missing everything that matters.

A chatbot conversation is different from a web visit. On a website, a visitor controls what they type into a form. In a chat, the conversation is open-ended. People volunteer their phone numbers, their order details, their names, sometimes even payment info or health details, all in free text. Your bot has to interpret it, store it, and often send it to a third-party AI service to generate a reply.

That changes the privacy picture in three ways. First, the data you collect is broader and less predictable than a form submission. Second, the data often travels through more hands, including the messaging platform and the AI provider. Third, carriers treat messaging programs as a separate compliance surface, and 10DLC registration needs a privacy policy URL with messaging-specific language. A generic website policy usually does not qualify.

So you need a dedicated section (or a dedicated policy) for the SMS chatbot program. Here is what it should cover.

1. What data you collect via text

This is the foundation. Your policy should list every category of data the chatbot program collects, in plain language.

At a minimum, that includes:

  • The recipient’s mobile phone number.
  • The content of messages the person sends to the bot, and the bot’s replies.
  • Consent records: when and how the person opted in, and any opt-out requests.
  • Metadata around the conversation: timestamps, delivery status, and which campaign or number the person interacted with.

Be honest about the unpredictable part too. Because chatbots accept free text, people may share things you never asked for, like an account number in the middle of a support chat. Say you collect message content generally, and discourage people from sending sensitive information the bot did not request.

2. How AI or LLM processing is disclosed

This is the item most chatbot policies skip, and it is the one regulators are starting to care about most. If an AI model reads or generates your bot’s replies, say so in plain language.

Your disclosure should answer three questions:

  • Who processes the conversation? Name the AI provider or platform that runs the model, the same way you would name any other service provider.
  • What happens to the data? Is it stored by the AI provider or used to train models? Major AI API providers currently offer business tiers where data is not used for training, but their policies change, so your disclosure must match what your provider actually does right now.
  • Where does the data go? State the regions or infrastructure involved if you know them, especially if conversations cross borders.

You do not need to publish your system prompt or model weights. You do need to tell a normal person, in normal language, that an AI reads their messages and what happens to those messages afterward.

3. How long you keep the data, and how it gets deleted

State a retention period. “We keep chatbot conversation records for X months” is far better than silence. The period should match your actual data cleanup practices. If your database keeps conversations forever, your policy must say that, and you should probably reconsider the practice.

Cover these points:

  • How long you retain phone numbers, message content, and consent records.
  • What triggers deletion: a time window, an opt-out request, or account closure.
  • Whether deletion means removing the data from your systems only, or also requesting deletion from the messaging platform and the AI provider.

Watch for a conflict with consent recordkeeping. Industry practice is to keep consent records for several years after opt-out, because that is your evidence if someone claims they never agreed to receive texts. Your policy can keep retention short for conversation content while keeping consent records longer.

4. Opt-out and data-subject rights

People who text with your bot have two separate sets of rights, and your policy should address both.

The first is messaging opt-out. Every outbound message should tell people how to stop the texts, usually by replying STOP. Your policy should repeat this: “Reply STOP at any time to opt out of text messages.” Carriers and reviewers look for this language in the policy itself, not just in the messages.

The second is data rights under privacy laws. Under laws like California’s CCPA and CPRA, residents have the right to know what personal information you hold about them, the right to delete it, and the right to opt out of its sale or sharing. Even if your business is too small to fall under a specific state law, building these rights into your policy is good practice as more states pass similar laws.

Give a real contact method for rights requests. A privacy email address or a request form works. Do not make people call a sales line to exercise a privacy right.

5. The mobile-number sharing statement carriers require

This one is non-negotiable if you register a 10DLC campaign. The Campaign Registry and the carriers require your privacy policy to state, in so many words, that text messaging opt-in data and consent status are not shared with third parties.

The standard language reviewers expect looks like this in spirit: “Mobile opt-in data will not be shared with third parties or affiliates for marketing or promotional purposes.” If the rest of your privacy policy allows data sharing with partners, you must carve SMS opt-in data out of it explicitly.

The only permitted sharing is with vendors that help deliver the service, like your messaging platform or carrier. Name those vendors. This statement is one of the most common reasons 10DLC campaigns get rejected at registration, so keep it worded consistently with your actual data flow.

6. Children’s data

If your bot is not directed at children, say so and set an age floor. The typical line is that the program is intended for users 13 or older (or 18 or older, depending on your industry), and that you will delete any children’s data you become aware of.

If your audience could include minors, your policy needs a real plan for this, not a boilerplate line. Talk to your lawyer about it.

7. Security measures

You do not need to list your exact security stack, but your policy should describe the safeguards around message data in general terms. Reasonable language covers encryption in transit, access controls that limit who inside your company can read conversations, and audit practices.

Be careful not to overpromise. “We protect your data with industry-standard measures” is honest. “Your messages are completely secure” is not, because no system is. Overstating security can come back to haunt you if there is ever an incident.

8. Contact information

A chatbot privacy policy needs a named point of contact for privacy questions. Include an email address and, if you have one, a mailing address. This contact should reach someone who can actually answer privacy questions, not a general support queue.

9. Where the policy must be published

Writing the policy is only half the job. Carriers and registries require it to be findable:

  • On your website. The policy should be reachable from your main site, typically linked in the footer and on any page that collects a phone number.
  • From the initial call to action. When someone opts in, the signup flow must link to the privacy policy before they submit. This is checked during campaign registration.
  • In your 10DLC registration. You submit the policy URL as part of the campaign registration, and reviewers will open it. If the page sits behind a login or returns an error, the campaign can be rejected.
  • In the bot’s own behavior. If someone asks the chatbot what it does with their data, the bot should point them to the policy.

10. Keeping the policy consistent with what the bot actually does

This is the hardest item on the checklist, and the one lawyers care about most. A policy that describes a data practice you do not follow is worse than no policy at all.

Every time you change the bot, check the policy. Added a new AI provider? Update the disclosure. Started storing conversations to train your own model? Update retention and the AI section. Changed messaging platforms? Update the vendor list. Set a recurring review, quarterly at minimum, and assign it to a named person.

One practical trick: keep an internal data map of the chatbot program listing what data is collected, where it flows, and how long it lives. The policy can then be checked against the map in minutes.

Want this set up for you?

I build SMS chatbots and API integrations for businesses. If you would like what this guide describes, done for you, get in touch.

Hire Me: setup from $500

Frequently asked questions

Do I really need a separate privacy policy for my SMS chatbot?

Not necessarily a separate document, but you need a messaging-specific section. A generic website policy that mentions cookies and forms usually fails 10DLC registration review, because reviewers look for SMS opt-in data, message content handling, and the mobile-number sharing statement.

Can I copy a chatbot privacy policy template I find online?

That is what this article is telling you not to do. Generic templates rarely match your data flow, your AI provider, or your retention practices, and they go stale as laws and carrier rules change. Use a checklist to know what to cover, then have counsel draft the actual text.

What do carriers require in the privacy policy?

For 10DLC registration, you need a publicly accessible policy URL, and the policy must explicitly exclude SMS opt-in data and consent status from any third-party data sharing for marketing. A rejected policy statement is one of the most common reasons campaigns get sent back for fixes.

How do I disclose AI processing in a privacy policy?

Name the AI provider, explain what happens to conversation data during processing, and state clearly whether conversations are used for model training. Match the disclosure to your provider’s current terms, since those terms change. If you switch providers or tiers, update the policy.

How long should I keep chatbot conversation records?

There is no single legally required period for conversation content, but consent records should be kept for several years as evidence of opt-in. Keep conversation content only as long as you have a business reason, state the period in your policy, and run a defined deletion schedule rather than storing data open-endedly.

Does my chatbot need to ask for consent to collect data?

If your chatbot sends marketing texts, you already need prior express consent before sending them (see our article on TCPA consent for SMS chatbots). Privacy consent for data collection is a separate question that depends on the state privacy laws covering your audience. When in doubt, link the privacy policy in the opt-in flow so people can review it before agreeing.

The bottom line

A good SMS chatbot privacy policy answers the questions a careful customer would ask: what do you collect, where does it go, who sees it, how long do you keep it, and how do I stop it. Add the carrier-required mobile-number sharing statement, disclose the AI processing honestly, keep the document in sync with the bot, and let a lawyer turn this checklist into final language. That is the whole job.