Customer-service chatbots under the PDPA: what to tell users and how long to keep chats

Online shops, hospitals, insurers and banks now put a chatbot in front of their service desks. Customers type names, phone numbers, addresses and order numbers. Some send a photo of their ID card or describe symptoms without being asked.

Each of those messages is collection of personal data under Thailand's Personal Data Protection Act B.E. 2562 (2019), the PDPA. The data controller is the business running the bot, not the software vendor. This article goes through what the law requires and what the Personal Data Protection Committee (PDPC) guidance adds.

Do you have to tell customers they are talking to a bot?

No PDPA section says so in terms. The PDPC AI guideline, however, answers the question directly in its FAQ annex: organisations should tell users, from the start, that they are communicating with an automated system.

In English, the passage says the organisation should inform users from the outset that they are dealing with an automated system, so they understand its limits and risks. In practice that is the first line of the bot: "This is our automated assistant. It can help with orders and delivery. Type 'agent' to reach a person." Short, honest, with a way out.

A friendly bot name is fine. A name, photo and tone designed to make customers believe they are chatting with a human employee works against the transparency principle the guideline relies on.

What must the privacy notice add for a chatbot?

The binding duty is Section 23 of the PDPA: the controller must inform the data subject before or at the time of collection. A chatbot collects from the first message, so the notice has to be reachable before the customer starts typing, not buried in a site footer.

The PDPC AI guideline builds on Section 23 in its checklist for organisations that buy or deploy AI, recommending that the notice also say AI is used, including to interact with people.

That checklist item asks organisations to update the notice to cover AI purposes, such as training on personal data, and to say that AI is used to process data, generate content or interact with humans.

The retention cell is left blank on purpose. The law sets no number for chatbots; the organisation picks one based on need and writes it into the notice. For the full notice, see the privacy notice guide.

Can you use customer chats to train or fine-tune a model?

The PDPC AI guideline separates two uses: feeding data in to get an answer (inference), and using data to make the system smarter (training or fine-tuning). The notice should name both clearly.

The passage singles out disclosure that data will be used for inference, to produce the answer the user asked for, and for training or fine-tuning, to make the model more capable or accurate. A bot that only answers questions is doing inference. Reusing past transcripts to tune the model is a new purpose. The guideline's FAQ (Q2.1) says this may fall outside the original purpose unless a Section 21 exception applies; otherwise, notify the new purpose and seek consent.

The same guideline (Annex C, Q4.1) prefers enterprise AI services backed by a data protection agreement over public tools. For staff pasting customer data into public AI, see our article on ChatGPT at work.

How detailed should chat logs be?

The PDPC AI guideline answers this in two places that look, at first, like they disagree. Section 8.1, on breach handling, asks for logs that capture both user input and the system's output, so investigators can trace which prompt caused a leak.

That sentence says the logging system should record input data and generated output for each transaction. The FAQ annex of the same document (Q6.5) then advises logging only what is necessary and avoiding personal data from prompts or outputs in logs, or masking it first.

Both can be met with a two-layer design. Layer one is metadata: time, conversation ID, model version and the system prompt in force, kept every time. Layer two is the conversation text, with ID numbers, phone numbers and sensitive details masked, access restricted and a deletion date set. This design is the AIPDPA team's suggestion, not wording from the guideline.

Whatever period you choose must match what the notice says under Section 23 (3). If another law requires you to keep logs, see 90-day logs versus erasure.

Is it a breach if the bot reveals another customer's data?

It can be. ETDA's Generative AI guideline describes an HR chatbot that used one employee's personal data to answer another employee's question. A customer bot that pulls records from back-office systems carries the same risk.

For outsiders who type crafted instructions to make the bot spill data (prompt injection), the PDPC AI guideline says this may be a personal data breach and points back to the statutory notification duty.

The passage says prompt injection may count as a breach if it causes the AI to disclose other people's personal data without authorisation, and that the organisation should assess the risk and notify if Section 37(4) conditions are met. That section requires notice to the PDPC Office without delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to result in a risk to individuals. The step-by-step process is in the first 72 hours of a breach. Metadata logs are what let you say what the bot told whom, and when.

What if the bot says something wrong about a customer?

Section 35 of the PDPA requires the controller to keep personal data accurate, up to date, complete and not misleading. The PDPC AI guideline explains that AI output about an identifiable person is personal data too, and that technical fallibility does not excuse the controller from the accuracy duty.

The guideline recommends telling users clearly about the accuracy limits of outputs, and giving data subjects a way to correct or suppress inaccurate outputs about them, for example through an output filter while fixing the model itself is not yet technically possible. In practice: state the bot's limits in its greeting, give customers a button to flag a wrong answer, and route that flag to a person who fixes the source. If the bot answers from your own knowledge base (RAG), fixing the source document is usually faster than fixing the model.

ETDA classifies this set-up as the "Customizer" model: the organisation combines its own data with a pre-trained model. That gives the organisation more control over answers than it often assumes, because it controls the documents the bot reads.

What should you check before the bot goes live?

1. The first message says it is automated, what it can handle and how to reach a person.
2. A link to the privacy notice sits in the chat window before the customer types, and the notice covers Section 23 in full, including chat retention.
3. Decide whether chats will be used to train or tune a model, and set the vendor options to match the notice.
4. Have a Section 40 data processing agreement with the chatbot platform and the model provider.
5. Split logs into metadata and conversation text, mask identifiers and set a deletion date.
6. Limit the bot to data of customers who have verified their identity, and test that asking about someone else returns nothing.
7. Offer a way to flag wrong answers and to exercise rights, such as a copy or erasure of chats.
8. Rehearse who assesses and who decides on notifying the PDPC Office within 72 hours if the bot leaks data.

The PDPC AI guideline (Annex B item 1) also recommends a DPIA where AI is used for automated decisions, sensitive data or large volumes of children's data, so a hospital or clinic bot should be assessed first. If the bot starts deciding things that affect customers, such as approving or rejecting requests, read customers asking for human review of automated decisions.

In AIPDPA, teams register the chatbot in the AI registry and work through the PDPC AI-guideline checklist in one place; if something goes wrong, the breach register counts 72 hours from the time of awareness. You can start with the free AI risk check, no sign-up needed.

Who stands behind this guide?

Written by the AIPDPA legal team · Content owner: Phuwara Krobtaku, Attorney-at-law · Thai Barrister-at-Law · technology & intellectual property counsel

Lawyer's licence no. 477/2558 · Thai Barrister-at-Law · LL.M. in Intellectual Property & IT Law (Gold Medal)