Direct answer An AI chatbot processes personal data from the very first message, and that means three things: you need a GDPR legal basis (usually consent or legitimate interest, depending on what the bot does), you have to tell users clearly that they're talking to an AI and inform them about the processing, and you need to know where the data goes when the AI provider is a third party. None of this is impossible for a small business. But none of it sorts itself out either.

Why I'm the one explaining this.

I've spent more than 15 years in digital marketing, ran a Catalan agency that was a Google Premier Partner, and now work as a consultant with 4-6 clients a year. I have a master's in AI from UCM, and part of my work is precisely building these systems for small businesses: customer-service chatbots, lead-generation assistants, automations. So I'm not talking to you from the panic of a newspaper headline, but from the trenches.

That said, I'm not a lawyer and this article isn't legal advice: it's the map so you know what to look at and what questions to ask. For the general framework of AI regulation, there's the article on Spain's AI law; here we get into the specific case.

First things first: yes, your chatbot processes personal data.

There's a widespread misconception that does real damage: "it's just a chat, we don't ask for anything". Wrong. The moment someone writes to your chatbot you're already processing the content of their messages and, most likely, session metadata. And people write things you never asked them for: names, phone numbers, health issues. The chatbot doesn't choose what it gets told. So the question isn't "do we process data or not?" It's "on what legal basis, what do we do with it, and who else sees it?"

The legal basis: consent or legitimate interest.

The GDPR requires that all processing of personal data rests on one of the legal bases listed in Article 6 of the Regulation. For a chatbot, the practical debate usually comes down to two:

Consent. The user freely, informedly and unambiguously agrees that you process their data for a specific purpose. This is the natural route when the chatbot is doing lead generation: if it asks for a name and email to send a proposal, consent must be explicit and recordable, just like any form.

Legitimate interest. This can cover processing that users would reasonably expect in context, provided you've carried out a genuine balancing test between your interest and the individual's rights (the balancing test required by the AEPD (Spain's data protection authority) and the European Data Protection Board). A typical borderline example: answering basic support queries without identifying the user.

There's a third route that's often overlooked: if the bot is supporting someone who is already a customer, the performance of your existing contract can also serve as the basis (Article 6(1)(b)). The important nuance, where I see the most errors: the legal basis is tied to the PURPOSE, not the tool. A single chatbot can involve two separate processing activities (answering queries and capturing leads), and each one needs its own basis and its own disclosure. And a classic mistake to avoid: reusing conversations for something else (training models, building profiles) without a basis or disclosure. If you ever want to do that, you document it beforehand. Not afterwards.

Transparency: say it's an AI, and say what you do with the data.

Two rules converge here that are often confused. The first is the AI Act, which imposes a transparency obligation (Article 50) on AI systems that interact directly with people: users must know they're talking to a machine, unless it's obvious from the context. This obligation starts applying on 2 August 2026, so it's no longer future theory. The practical upshot: the bot presents itself for what it is in its very first message. No pretending to be Sarah from the sales team.

The second is the GDPR, which requires you to inform the individual about the processing: controller identity, purposes, retention periods, rights and how to exercise them (the content of Articles 13 and 14), a duty the AEPD recommends delivering in layers in conversational interfaces.

The good news: both are solved with the same design gesture. An honest first message ("I'm an AI, I process your data for X, here's the privacy policy") with a link to an up-to-date policy. And interestingly, telling users it's an AI doesn't put them off. What puts them off is finding out afterwards.

Data minimisation: the chatbot doesn't need to know everything.

The GDPR requires processing only data that is adequate and necessary for the purpose. Applied to a chatbot:

Don't ask for what you don't need. If the bot answers questions about opening hours, it doesn't need anyone's ID number. Every field you ask for has to be justifiable.

Put guardrails around what you don't want to receive. A well-designed bot politely deflects sensitive data ("you don't need to give me that, please call us for this topic") and, where the system allows it, filters data before storing it or sending it to the model.

Decide how long you keep conversations, and why. "Forever, just in case" is not a retention criterion; it's the absence of one.

The point almost everyone misses: where the data goes.

This is where things get serious. Most small-business chatbots run on third-party models (OpenAI, Anthropic, Google and the rest): every message from your customer can end up on that provider's servers. The implications:

The provider is your data processor. You need a processing agreement (Article 28 of the GDPR) that governs what they can do with the data. That said, the provider's role has to be examined case by case: if they use conversations for their own purposes, they may be acting as an independent controller rather than a mere processor. The major providers offer these agreements (DPAs) on their business plans; free or consumer plans often do NOT give the same guarantees.

Transfers outside the EEA. If the provider processes data outside the European Economic Area, a valid transfer mechanism is required. The specific framework changes over time, so you don't need to have it memorised: what matters is that the provider can show you in writing which basis they transfer on.

Training on your data. Some services use conversations to train models depending on the plan. On business plans this can usually be turned off or comes switched off by default. Check it and document it.

My practical rule: if an AI provider can't show you their DPA or explain where they process data, they're not a provider for your customers' data. The fact that the bot looked spectacular in the demo doesn't change that.

Checklist before you switch the chatbot on.

The operational version of everything above. Before putting the bot into production:

1. Purposes in writing. What the bot will do and with which data. One sentence per purpose.

2. Legal basis for each purpose. Consent, legitimate interest or contract performance, decided and documented.

3. AI disclosure in the first message. The user knows they're talking to a machine.

4. Privacy information accessible from the chat. A short layer plus a link to the full, up-to-date policy.

5. Minimisation applied to the script. The bot doesn't ask for data it doesn't need and redirects sensitive topics to a human channel.

6. Processing agreement with the provider. DPA accepted, no training on your conversations, processing location known.

7. Retention defined. How long you keep conversations and leads, and who can see them.

8. Human route always open. To speak to a person and to exercise data rights.

9. Record of processing activities updated, and an assessment of whether a data protection impact assessment is required (mandatory when the processing is likely to result in a high risk to individuals' rights, according to the AEPD's criteria).

10. Periodic review. Every time the bot's purpose changes, run back through this list.

The honest conclusion: this isn't a reason not to do it.

After reading all of this you might think that deploying a chatbot is a minefield. It isn't. It's a project with homework, like accepting card payments or sending newsletters. The companies that get it wrong usually don't fail out of bad faith: they fail because they switch the tool on first and think about it afterwards.

My advice is the same as always: neither hype nor paralysis. A chatbot set up properly, with these bases covered from the design stage, is a perfectly legal and genuinely useful tool. And if your provider or agency can't answer the questions on this list, the answer isn't to give up on the chatbot. It's to change provider.

If you want the general context on applying AI to a small business with a clear head, start with the AI for small businesses hub. And if you'd like to look at your specific case, the method page explains how I work and why I only take on 4-6 clients a year.

Frequently asked questions.

Does an AI chatbot always require user consent?

Not always. Consent is one possible legal basis, but not the only one: depending on the purpose, legitimate interest can cover processing that users would reasonably expect, provided you've documented a genuine balancing test. What is always mandatory is informing users about the processing and making sure they know they're talking to an AI.

Do I have to tell users they're talking to an AI?

Yes. The AI Act (Article 50) imposes a transparency obligation on AI systems that interact with people: users must know they're not speaking to a human, unless it's obvious from the context. This obligation applies from 2 August 2026 and, in practice, is handled by presenting the bot as a virtual assistant in its first message.

Can I use ChatGPT or a similar model for my business chatbot?

Yes, but with conditions: you need a plan that includes a data processing agreement (DPA), guarantees about where data is processed, and assurance that your customers' conversations are not used to train the model. Free or consumer plans typically do not provide these guarantees.

What happens if a customer types sensitive data into the chat without being asked?

You can't control what people write, but you can control what you do with it. A well-designed bot never asks for sensitive data, redirects those topics to a human channel, and where technically possible avoids storing or sending that data to the model provider. Data minimisation is a design decision, not a formality.

Do I need a lawyer to deploy a chatbot?

For a simple customer-service chatbot, with a good provider and the checklist items covered, updating your privacy policy with whatever data protection support you already have is often enough. If the bot handles sensitive data, makes decisions with effects on individuals, or operates in a regulated sector, then yes: get specialist advice before switching it on.

Want to build a chatbot done right from day one?

30 minutes free, by video call. You tell me what you want the bot to do and I'll explain how to set it up so it's useful and compliant, without smoke and mirrors and without panic. No sales agenda.

Book a diagnostic session