GDPR SMS Chatbot Compliance: What Changes for EU Texting

Not legal advice. This article explains how GDPR and related rules interact with SMS chatbots in plain language. GDPR interpretation keeps evolving, and regulators in different EU countries do not always agree on the details. Have your own counsel review your setup before you launch.

If your SMS chatbot texts people in the EU or EEA, you are processing personal data under one of the strictest privacy regimes in the world. Chatbots collect data people volunteer without thinking and pass messages through AI providers. This guide covers what actually changes: territorial reach, consent in a chat flow, consent records, data-subject rights in conversation, AI data flows, and Schrems II transfers.

When GDPR applies to your chatbot

GDPR applies based on the recipient, not your office. If you process personal data of people in the EU or EEA in connection with offering them goods or services or monitoring their behavior, GDPR follows the data. A US company texting EU residents about its products is inside scope; one texting only US numbers is not. The UK now has its own version: UK GDPR plus PECR covers texting UK residents, so treat the UK as a separate jurisdiction in your compliance docs.

“Processing” means doing anything at all with personal data. A chatbot that receives a name, reads a phone number, logs a timestamp, or sends a reply is processing, and there is no chatbot exception. The question is whether you have a lawful basis, a stated purpose, a retention period, and a deletion path for everything the bot touches.

The two layers: GDPR plus ePrivacy

Sending marketing texts to EU recipients involves two separate legal layers, and both have to line up.

Layer one is GDPR. You need a lawful basis under Article 6, and for marketing texts that is almost always consent. Layer two is the ePrivacy Directive. Article 13 covers unsolicited direct marketing over electronic channels, and SMS sits squarely in it. The general rule is prior consent: no marketing texts without the recipient’s earlier opt-in.

That is why “legitimate interest” rarely saves you here. Recital 47 of GDPR does say direct marketing can be a legitimate interest. But ePrivacy still demands prior consent for electronic marketing regardless. For SMS, consent is the only reliable path.

There is one narrow exception, the soft opt-in. Under Article 13(2), you can text an existing customer about your own similar products without fresh consent if you got their number during a sale or sale negotiations, you gave them a clear chance to opt out at collection, and every message still offers an opt-out. Member states implement this differently, so confirm local rules. Soft opt-in never covers prospects who bought nothing, and consent for one channel never covers another: an “email me updates” checkbox does not authorize SMS.

What valid GDPR consent looks like in a chat flow

GDPR consent must be freely given, specific, informed, and an unambiguous indication of wishes by clear affirmative action. Here is how that translates into a text conversation.

Separate it from everything else. Marketing consent cannot be buried in terms of service or bundled into “by chatting with us you agree to everything.” Article 7(2) says the request must be clearly distinguishable and in plain language. Use a dedicated message: “Want order updates and occasional offers by text? Reply YES to subscribe. Up to 4 msgs/month. Reply STOP to opt out anytime.”

Make the action affirmative. Replying YES or tapping a “Yes, text me” button counts. Pre-ticked boxes, silence, and “we will text you unless you object” do not. The EU’s top court struck down pre-ticked consent boxes years ago.

Say what they are agreeing to. Informed means they know who is collecting the data, which channel, what kind of messages, and roughly how often. “Offers and updates” is vague. “Up to 4 marketing texts a month from [Brand] about new products” is specific.

Double opt-in adds a confirmation text after the YES reply describing the subscription. It is not legally required, but it kills disputes about whether consent happened. Whatever you choose, never gate the service on marketing consent (it would not be freely given), and make withdrawal as easy as giving it: STOP that works instantly, plus HELP, honored immediately.

Consent records: prove it or it did not happen

Article 7(1) puts the burden on you. You must be able to demonstrate consent was given. For each consenting number, store the number with country code, the date and time of consent with timezone, how consent was captured, the exact wording the person saw, the channel covered, and a campaign identifier. Log withdrawals the same way, and keep these records well beyond the life of the subscription, since regulators and carriers both ask for this evidence during complaints.

Data-subject rights, handled inside a chat

Your chatbot is often the front door where people exercise their GDPR rights: access (“show me what you have on me”), erasure (“delete my data”), rectification (“fix my number”), and objection, which for direct marketing is absolute. Once someone objects, you stop.

Teach the bot to recognize rights requests in plain language. “Delete my data,” “remove me,” “forget me,” and “stop storing my chats” should all route to your erasure flow. The reply should confirm what will be deleted, what will be kept and why (for example, a suppression record so you never text them again), and a timeline. Respond without undue delay and within one month. That Article 12(3) clock starts the moment the request arrives.

Train the bot on synonyms, because people rarely say “I invoke my right to erasure.” Keep a suppression list of opted-out numbers so you never re-add them, since deleting the suppression entry is how accidental re-texting happens. Verify identity proportionately: on SMS the number itself is usually enough for a chat-scoped request. Anything the bot cannot fulfill, like access requests spanning multiple systems, goes to a human workflow.

AI and LLM data flows: what the person is agreeing to

Most modern SMS chatbots are not rule trees. The message goes to a model, often hosted by a third-party AI provider, which generates the reply. That creates obligations rule-based bots never had. Start with disclosure: your chat intro should say, in plain language, that messages are processed by automated systems and, where true, by named AI providers. One or two sentences at the start of the conversation is enough. Then get the contracts right.

Sign a data processing agreement. If an AI provider processes personal data on your behalf, they are your processor and you need a DPA meeting Article 28: permitted uses, sub-processor rules, security measures, and help with data-subject requests. “Their terms say they are GDPR compliant” is not a DPA. Get the actual document and file it.

Minimize what goes into prompts. Every field you stuff into a prompt is data you send to a third party and store in logs. Send only what the current turn needs.

Watch for special category data. People volunteer health details, political views, and financial hardship in the first message, unasked. Article 9 puts far stricter rules on that data. Either design the flow so it is not retained, or get proper advice before you keep it.

Do not train models on transcripts by default. Using chat logs to fine-tune a model is a new purpose with its own lawful basis and disclosure requirements. Most providers let you opt out of training on your data. Do that first.

International transfers and Schrems II

If your chatbot provider, SMS gateway, or analytics tool processes personal data outside the EEA, you are making a restricted transfer and need a valid mechanism.

Since Schrems II (C-311/18, 2020), the EU-US Privacy Shield is gone. Standard Contractual Clauses survive but require homework: assess whether the destination country’s laws give protection essentially equivalent to the GDPR, and add supplementary measures where gaps exist. The European Data Protection Board warns that contractual promises alone rarely close a surveillance-law gap; technical measures like encryption where the importer holds no key carry the real weight. If the assessment fails and nothing fixes it, the transfer should not proceed.

The current US adequacy route is the EU-US Data Privacy Framework, adopted in 2023. If your provider is certified under it, that is a legitimate basis today, but it has faced legal challenge, so have counsel confirm the current status before you rely on it.

Practically: list every party that touches message content, note where processing and storage happen and which mechanism covers each transfer, ask your AI provider about EU data residency, and file the transfer impact assessments. Run the model on infrastructure you control inside the EEA, and the transfer question mostly disappears.

Retention: decide it before you log anything

Storage limitation means keeping personal data only as long as necessary for the purpose. Set periods per data type and write them down: chat transcripts tied to the support purpose (many teams land on 90 days to a year, then anonymize or delete), consent records kept well past the subscription because you may need to prove consent, suppression lists kept indefinitely so you never re-contact. Then automate deletion, including backups and logs, because policies that depend on someone remembering a cleanup script do not survive.

Practical compliance checklist

1. Map your data flows. Every system that sees message content, where it sits, and why it needs the data.
2. Pick a lawful basis per purpose. Consent for marketing texts. Contract or documented legitimate interest for support. Separate basis for analytics and training.
3. Write the consent wording. Specific channel, sender, and frequency, in plain language, separate from terms.
4. Build the records. Timestamp, method, wording, version, channel, withdrawal log.
5. Wire up STOP and HELP. Instant, free, no login, confirmed in the reply.
6. Teach the bot rights requests. Access, erasure, rectification, and objection intents with human escalation behind them.
7. Publish the notice. Short in-chat disclosure plus a full privacy policy naming the AI provider and retention periods. Our privacy policy checklist covers the policy itself.
8. Sign the DPAs. Chatbot platform, LLM provider, SMS gateway, analytics.
9. Do the transfer assessment. Residency per vendor, mechanism per transfer, documented.
10. Set retention and automate deletion. Suppression entries survive erasure.
11. Plan for breach and review yearly. Know who notifies whom within 72 hours if message data leaks, and re-check vendors when sub-processors or data regions change.

FAQ

Can I send SMS marketing to EU recipients under GDPR?
Yes, with prior consent that is freely given, specific, informed, and unambiguous. ePrivacy requires the opt-in; GDPR defines what consent is and makes you prove it.

Is legitimate interest ever enough for marketing texts?
No. ePrivacy requires prior consent for electronic marketing messages regardless of any GDPR lawful basis. Consent is the only safe path for SMS marketing.

Does GDPR apply if my company is based in the US?
If you text people in the EU or EEA in connection with offering them goods or services, yes. GDPR follows the recipient, not your headquarters. Our TCPA consent guide covers the separate US rules.

My AI provider processes messages in the US. Is that allowed?
It can be, with a valid transfer mechanism: an adequacy decision like the EU-US Data Privacy Framework if the provider is certified, or Standard Contractual Clauses plus a documented transfer impact assessment and supplementary measures. Check the provider’s EU data residency options first.

The bottom line

GDPR does not ban SMS chatbots in Europe. It bans sloppy ones. Get specific consent before marketing texts, keep records that prove it, make STOP instant, teach your bot to handle “delete my data,” disclose your AI providers, sign the DPAs, sort out your transfer position, and delete data on a schedule.

For the US side of chatbot texting rules, including carrier registration, see our guides on TCPA consent and 10DLC registration.