Staff Pasted Customer Data into ChatGPT: What Four Thai Rulebooks Say

Picture this: late on a Friday, a collections officer copies 200 rows of customer data (names, phone numbers, overdue balances) and pastes them into a free AI chatbot account registered to a personal email. The prompt: "Write a polite payment reminder for each of these people." The job takes a minute, and nobody else in the company ever finds out.

This happens daily in Thai offices, and malice is rarely involved. The trouble is that a single Ctrl+V is judged by four official texts at once. Between them they cover personal data protection, cross-border transfers, AI governance and business confidentiality. This article goes through each source, quotes what it actually says, and ends with a table and a short policy template you can adopt this week.

Is pasting customer data into public ChatGPT a PDPA problem?

Yes, it is a serious risk. The PDPC's AI guideline answers this exact question in Annex C, item 4.1, and calls it high risk, possibly an unlawful disclosure of personal data. The same answer offers two ways out: ban the input, or move to an enterprise AI service backed by a contract. The guideline has no official English version, so the Thai original is quoted below.

In plain English, the passage says: it is high risk and may be an unlawful disclosure; the organisation must have appropriate security measures; if the data is used to train a public model it may leak; organisations should ban entering personal data into public AI, or consider a closed enterprise AI service backed by a data protection agreement or contract.

Executives often miss who carries the responsibility. Section 2.3 of the same guideline separates personal use of AI, which PDPA Section 4(1) exempts, from use on behalf of an organisation. It gives the example of an employee who enters customer data or internal meeting minutes into a public platform. That is processing by the organisation, even when the employee uses a personal account.

The passage describes staff entering such data as a prompt into a public generative-AI platform to summarise reports or draft business emails, and says this counts as processing on behalf of the organisation, which must have strict controls over privacy and confidentiality risks. When something goes wrong, the company cannot easily tell the regulator it was the employee's private business. It needs to show the measures it had in place beforehand: a published policy, training records and a list of approved AI tools.

What does ETDA's generative-AI guideline add?

The 2024 guideline from ETDA's AI Governance Center goes further down to the level of named categories of forbidden data, and explains why free services in particular are a concern. Its annex is a sample policy that ETDA wrote for its own office, so a private company should adapt it rather than copy it wholesale.

ETDA adds three things to the PDPC text. First, concrete examples, from ID card copies to medical certificates. Second, a ban on internal and classified material such as passwords, contracts and internal project files (annex 4.2, item 1). Third, the rule that when work genuinely needs such data, staff may use only services the organisation has approved or provided (annex 4.2, item 3). That third rule is what makes room for enterprise AI.

Does pasting data into a chatbot count as a transfer abroad under PDPA Section 28?

Possibly. It depends on where the provider keeps the data and who can reach it. Section 5.3 of the PDPC AI guideline describes two cases. If the data only passes through a network, or sits in storage that no outsider can access, it is not a transfer. If the provider stores or uses the data in a data centre abroad where someone other than the sender can access it, that may be a transfer.

The passage says that where an AI provider stores or uses personal data in a data centre located abroad, and a person or entity abroad other than the sender can access it, this may be treated as sending or transferring personal data abroad. The line comes from the definition in clause 3 of the PDPC's 2023 notification under Section 28. That definition carves out only pure transit and storage that no outsider can reach.

A chatbot that keeps conversation history, and may use conversations to improve its model as ETDA warns, is not a passive pipe. If the service terms let the provider access or use what you paste, the carve-out falls away and PDPA Section 28 comes into play.

The six exceptions in Section 28 are a poor fit for casual pasting. Consent under item (2) requires telling data subjects in advance that the destination's protection standards are inadequate, and nobody does that before hitting paste. The contract exception in item (3) requires the transfer to be necessary to perform a contract with the data subject, and a payment reminder can be drafted without sending real names anywhere. Have your DPO assess any exception case by case before relying on it.

The route designed for businesses is Section 29 and its 2023 notification. Clause 8 allows transfers without meeting Section 28 where appropriate safeguards are in place, such as recognised contract clauses. Clause 10 then names usable models, including the ASEAN Model Contractual Clauses and the GDPR Standard Contractual Clauses. An employee clicking "I agree" on a personal account puts no such safeguard in place.

If staff paste formulas, cost prices or sales plans into AI, is it still a trade secret?

The Trade Secrets Act B.E. 2545 (2002) does not protect everything a company labels confidential. Section 3 sets three conditions, and public AI touches the last one directly.

Now imagine suing a former employee for taking your product formula. The other side can ask whether you really took appropriate measures to keep it secret, given that any employee could paste that same formula into a public chatbot with no rule against it. That is how a missing AI policy becomes a weak point in a trade secret case, even if nothing actually leaked when the data was pasted.

What was pasted, which rule applies, how risky is it and what is the fix?

The table covers the cases seen most often in offices. Each row ties back to a source quoted above, so a DPO can take it straight into a meeting with department heads without translating legal language.

How does public AI differ from an enterprise AI service with a data protection agreement?

The difference is the contract, not the price. A paid account an employee buys personally is still a contract between that employee and the provider. With an enterprise service, the company itself is the contracting party and can negotiate how data is used. Annex B of the PDPC AI guideline says what that agreement should contain.

In English: prepare a full data processing agreement under PDPA Section 40 that forbids the provider from using the organisation's personal data for any purpose or on any terms outside the agreement unless permitted.

If an enterprise licence is not in the budget yet, item 6.3 in Annex C of the PDPC guideline sets a floor: read the service's terms of use and privacy notice, and adjust the privacy settings rather than keeping defaults that are not safe enough. For drafting the agreement, see our processor agreement guide, and for transfers, the cross-border transfer guide.

What should a short AI acceptable-use policy contain?

Annex B item 1 of the PDPC guideline sets the bar: the policy must state clear prohibitions and must come with staff training, not just an announcement.

In English: adopt an Acceptable Use Policy with clear prohibitions, for example no entering personal data into public AI, and train staff on the risks of AI hallucination and data leakage.

1. Scope: applies to employees, contractors and interns on every device used for company work, including personal phones.
2. Approved list: only AI services on the list approved by IT and the DPO may be used; no personal accounts for company work.
3. Forbidden in unapproved services: customer and staff personal data, sensitive data (ID cards, health, biometrics), contracts, cost prices, formulas, source code, passwords and API keys.
4. In approved services: enter only the personal data the task needs, and replace names with codes where possible.
5. Review first: check AI output before it reaches a customer or the public; never let AI alone decide anything that affects a person's rights.
6. Settings: use the privacy settings IT specifies, not the defaults.
7. Report at once: if forbidden data has been entered, tell your manager and the DPO immediately; prompt self-reporting counts in your favour.
8. Train and test: training at onboarding and every year, with a short quiz; breaching the policy is a disciplinary matter under the work rules.
9. Review: the DPO reviews the approved list and this policy at least every 6 months.

Someone has already pasted the data. What comes first?

Do not start by looking for someone to blame. Start by containing the damage. ETDA's annex 4.3 item 3 tells users to report immediately up the chain of command and follow the security incident procedure. A workable order is:

1. Record what was pasted, into which service, from which account and when, before deleting anything.
2. Delete the conversation and switch off history or training, to the extent the service terms allow.
3. If passwords or API keys were included, change or reissue them immediately.
4. Have the DPO assess whether this is a personal data breach that must be reported under PDPA Section 37(4), which runs on a 72-hour clock from awareness.
5. Fix the system: review the approved-tools list and retrain the team involved.

In AIPDPA, staff can log the incident straight away. A 72-hour countdown starts from when the organisation became aware, and a decision helper matches the incident against the PDPC's 10 published examples, with a person confirming every decision. On the prevention side there is an AI registry, a workplace AI tools policy and a staff quiz. To see where your organisation stands, start with the free 8-question AI risk check.

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)