The PDPA AI guidelines are guidance issued by Thailand’s Personal Data Protection Committee (PDPC) in October 2026 on how the Personal Data Protection Act B.E. 2562 (PDPA) applies when organisations develop or use artificial intelligence. They are advisory and do not create new legal obligations. The PDPA itself is in force, and the guidelines show how the regulator reads it for AI systems.
Prompts, logs, embeddings and AI outputs can all be personal data. A model trained on personal data is not treated as anonymous unless the organisation can show it meets the anonymisation criteria. Roles follow real decision-making power, consent is not the default lawful basis, and technical limits in an AI system do not remove PDPA duties.
What Are the PDPA AI Guidelines?
The PDPA AI guidelines are a handbook that the PDPC issued under Section 16(3) of the PDPA, which empowers the Committee to set measures and guidance for compliance. Thai reports state that the PDPC Office prepared the document with the Electronic Transactions Development Agency. It follows a draft that the PDPC released for public comment in February 2026.
The guidance follows the full life of an AI system: planning, data preparation, model training, deployment and decommissioning. It covers analytic AI, generative AI and agentic AI, meaning systems that carry out several steps towards a set goal. Annex A contains a checklist for AI development, and Annex B contains a checklist for AI use.
The document states that it has no binding legal force and does not decide questions of liability. Even so, it records the regulator’s reading of the PDPA. Companies should therefore read it together with the Act, its subordinate notifications and other PDPC guidance.
Do the PDPA AI Guidelines Reach Companies Outside Thailand?
The guidance follows the reach of the PDPA. Under Section 5, the Act applies to controllers and processors located in Thailand, wherever the processing takes place. It also applies to controllers and processors outside Thailand when they offer goods or services to data subjects in Thailand or monitor their behaviour in Thailand.
Consequently, a foreign software provider whose AI tool serves Thai users, or a regional group that profiles Thai customers from an overseas hub, should treat the guidance as relevant. Section 37(5) adds a further duty for an overseas controller within Section 5: it must appoint a representative in Thailand in writing.
Which AI Data Counts as Personal Data?
Section 6 of the PDPA defines personal data as information that can identify a person, directly or indirectly. The PDPA AI guidelines apply this test to every layer of an AI system. Prompts, usage logs, vector embeddings and outputs can each be personal data if a person can still be identified from them.
The guidance also addresses trained models. A model trained on personal data is not anonymous by default. Unless the organisation can demonstrate anonymisation against the criteria in the guidance, the model remains within the PDPA. In other words, training does not end the duty to protect the data that went into it.
As a result, data mapping for an AI project must cover inputs, data held during use and outputs, not only the source database. Companies that mapped their data before deploying generative AI should revisit that work.
Controller or Processor Under the PDPA AI Guidelines
The guidance assigns roles by asking who decides the purposes and means of processing in each AI activity. A label in a contract or a technical job title does not settle the question. A company that chooses which personal data to put into an AI tool and how to use the results acts as a controller for that activity.
The key risk sits with AI vendors. If a provider uses a client’s data to train its own models for its own purposes, it may become a separate controller for that processing. The guidance therefore asks companies that use external AI services to review terms on model training, access to data and transfers abroad.
This reading matches the Act. Under Section 40, a processor must act only on the controller’s instructions, and a processor that departs from them is deemed a controller for that processing. Accordingly, a vendor contract that is silent on model training leaves the allocation of duties open on precisely the point the PDPC has singled out.
Which Lawful Basis Applies to AI Processing?
The guidance asks organisations to review every lawful basis before turning to consent. Section 24 lists the bases for general personal data, and Section 26 sets stricter conditions for sensitive data. Where no exception applies, consent is required, and sensitive data needs explicit consent under Section 26.
The PDPC explains why consent should not be the first choice. A data subject can withdraw consent, and a withdrawal can disrupt an AI system that depends on the data. Where an organisation relies on legitimate interest, the guidance recommends a documented legitimate interest assessment. However, legitimate interest is not a basis for processing sensitive data, which must meet Section 26 on its own terms.
Reusing existing data to train a model raises a separate question. The organisation must check whether training fits the purposes it notified. If training is a new purpose, the conditions of the Act apply to that new purpose. Holding the data already does not authorise its use for training.
When Do the PDPA AI Guidelines Call for a DPIA?
The PDPA AI guidelines recommend a data protection impact assessment before any AI project that may affect data subjects’ rights. Two examples receive particular attention: automated decisions with legal or similarly significant effects, and training models on sensitive personal data. The assessment should identify the risks and the safeguards for each.
The safeguards named include controls on inputs and outputs, limits on the permissions and scope of AI agents, and activity logs that allow later review. For decisions that affect individuals, the guidance calls for human oversight. The person overseeing the system must hold real authority to review and change the AI’s decision.
The guidance also speaks to senior management. Before approving an AI project, executives should confirm that roles and lawful bases are settled and that the risk assessment is adequate. They should also check that human oversight exists wherever the system may affect a person’s rights. Channels for rights requests and a breach response plan should be ready before launch.
AI Vendors, Breaches and Cross-Border Transfers
Most companies use AI through outside providers, often on overseas cloud infrastructure. The PDPA provisions below then apply to the vendor chain. Each one is in force.
| PDPA provision | What it requires | Point for AI use |
|---|---|---|
| Section 28 | Transfers abroad must meet the PDPC’s standards for the destination, unless an exception applies | Prompts and outputs sent to an overseas AI provider are transfers |
| Section 37(4) | Notify the PDPC Office of a breach without delay and within 72 hours of becoming aware, where feasible; notify data subjects without delay where the risk is high | A leak through an AI tool or vendor follows the same clock |
| Section 40 | A processor acts only on instructions, keeps security measures, reports breaches to the controller and keeps processing records | Vendor terms should reflect these duties |
| Section 39 | The controller keeps a record of processing activities | Disclosures to AI providers belong in the record |
For further detail on the notification duty, see our guide to data breach notification in Thailand.
How Should Data Subject Rights Work in an AI System?
The guidance is direct on this point: technical complexity does not remove legal duties. Data subjects keep the rights to access their data under Section 30, to object under Section 32 and to request erasure under Section 33. Under Section 30, the controller must act on an access request without delay and within 30 days of receiving it.
The PDPC asks organisations to design for these rights from the start. It distinguishes data in a knowledge base that a system retrieves, as in retrieval-augmented generation (RAG), from data absorbed into the model through training. For RAG, the organisation can remove or de-index the data so the system no longer retrieves it.
Removing data from a trained model, known as machine unlearning, is harder. The guidance suggests interim measures such as output filtering until the model is updated. It adds that filtering alone does not mean the data has left the model. Organisations must still assess whether their measures satisfy the request and the law.
Applying the PDPA AI Guidelines: Steps for Foreign Companies
The PDPA AI guidelines translate into a short sequence of actions for any company that develops or deploys AI touching Thai personal data.
- Map personal data across prompts, logs, embeddings, outputs and trained models.
- Record the controller or processor role for each AI activity, based on who decides purposes and means.
- Choose and document the lawful basis under Section 24 or Section 26, with a legitimate interest assessment where relevant.
- Update privacy notices for AI processing, including any new purpose such as model training.
- Run a data protection impact assessment for high-risk projects and set human oversight with authority to override.
- Review AI vendor terms on model training, access, security, breach reporting and transfers abroad.
- Build processes for access, objection and erasure requests, including the RAG and model distinction.
Frequently Asked Questions
Are the PDPA AI guidelines legally binding?
No. The guidance states that it has no binding legal force and does not decide liability. The PDPA itself is binding, and the guidance shows how the PDPC reads the Act for AI systems.
Can an AI prompt be personal data in Thailand?
Yes. Under the guidance, prompts, usage logs, embeddings and outputs can be personal data where a person can be identified from them, directly or indirectly, which follows the definition in Section 6 of the PDPA.
Should a company rely on consent to train AI on personal data?
The PDPC recommends reviewing every lawful basis first, because consent can be withdrawn. Legitimate interest needs a documented assessment and cannot cover sensitive data, which falls under Section 26.
What happens if an AI vendor trains its models on client data?
The guidance states that a provider using client data to train its own models for its own purposes may become a separate controller. Under Section 40, a processor acting outside instructions is deemed a controller for that processing.
Conclusion
The PDPC has not created new obligations for AI. Instead, it has applied the existing PDPA to every stage of an AI system, from prompts to trained models. The practical message for foreign companies is clear: AI data is personal data unless proven otherwise, roles follow real control, and vendor contracts must address model training. For related reading, see our analysis of the draft Thailand AI Act or our PDPA compliance services. Official information is published by the Office of the Personal Data Protection Committee, and the Thai text of the Act by the Office of the Council of State.
Speak with our partner
Arrange a consultation to review an AI deployment, a vendor agreement or a data protection impact assessment under the PDPA.