What the board should ask before approving an AI project is the PDPC's six questions, answered in writing: controller or processor status, lawful basis, the DPIA result, a human who can genuinely overturn the system, a channel for data subject rights, and a 72-hour breach plan. Directors and executives get a ready checklist. Both PDPC and ETDA documents are guidance, not law.
- The PDPC lists six questions a board should put to management before approving any AI project, from legal role to a 72-hour breach plan.
- ETDA's executive guideline puts an AI Governance Council in charge, directly responsible for AI outcomes and for setting risk appetite.
- High-risk AI, such as staff screening or approving money, should not be approved until a DPIA is complete (PDPC guideline, section 6.2).
- A reviewer who can only click confirm is not oversight. The PDPC calls that rubber-stamping.
- Both documents are guidance, not statute, but they show clearly what Thai regulators expect from management.
When an AI project reaches the board agenda, directors usually see a cost-saving figure and a polished demo. What they rarely see is a written answer to two plain questions. Who is accountable when the system gets it wrong? And how will the company explain itself to the customer or employee on the receiving end?
Thailand now has two official guidelines that answer those questions for executives. The first is the AI Governance Guideline for Executives from the Electronic Transactions Development Agency (ETDA), now in its second revision. The second is the Guideline on Personal Data Protection in the Development and Use of AI, version 1.0, issued by the Personal Data Protection Committee (PDPC) under Section 16(3) of the Personal Data Protection Act B.E. 2562 (2019).
This article reads the two side by side and turns them into the questions a director or CEO should ask, the documents worth requesting, and a one-page checklist you can attach to a board paper.
Who answers for it when an AI system gets a decision wrong?
Under ETDA's guideline, the answer is an AI Governance Council, not the IT department and not the vendor. The guideline builds governance on three components: a governance structure, an AI strategy, and oversight of AI operations across the whole lifecycle.
The AI Governance Council is directly responsible for the results of the operation or decisions of AI
A mid-sized company does not have to create a new committee. The same guideline lets organisations reuse bodies they already have, for example a data governance council for data quality and personal data protection, or the committee under a governance, risk and compliance (GRC) structure for AI risk.
The example structure places C-level executives at the top, with legal or compliance, technical and business representatives below them, plus outside experts where needed. Two things must be written down without ambiguity: who may approve a model for production use, and who decides how much risk is acceptable.
the AI Governance Council also has the duty to consider which risks are acceptable risks (Risk Appetite), together with overseeing appropriate Risk Management, in order to control the risk within an acceptable scope.
What are the PDPC's six questions for the board?
One page of the PDPC's AI guideline is addressed to directors and senior executives. It lists six questions to put to management before approving an AI project. None of them asks how clever the system is; every one asks whether the company is ready to answer for it. Because the PDPC published this guideline in Thai only, the wording below is the original Thai text. Question 4 is the one boards most often skip.
4) มีมนุษย์กำกับดูแล (Human Oversight) ที่มีอำนาจกลับคำตัดสินของระบบได้จริง ในจุดที่กระทบสิทธิส่วนบุคคลหรือไม่The table turns all six questions into documents a board can actually ask for. The right-hand column is the author's view of which answers should make a board pause before approving.
| PDPC question (summarised) | Documents to see | Reasons to pause |
|---|---|---|
| 1. Are we controller or processor here, and does the AI vendor contract forbid training on our data? | Map of roles in the AI value chain · data processing agreement | The only answer is that the vendor's standard terms apply, and nobody has read them |
| 2. What is the lawful basis, and if it is legitimate interest, is there a complete LIA or consent? | Lawful basis recorded in the RoPA · legitimate interest assessment | Consent is the sole basis, even though it can be withdrawn at any time |
| 3. Does the project meet the high-risk threshold for a DPIA, and is the result acceptable? | DPIA report with mitigation measures | Not done yet, approval requested anyway |
| 4. Is there a person with real power to overturn the system where rights are affected? | Process map naming the reviewing role · statistics on overturned decisions | The reviewer can only confirm |
| 5. Is there a channel for data subjects to exercise their rights? | Request channel · response procedure covering data inside the AI system | Nobody knows how data would be removed from the model or vector store |
| 6. If data leaks, do logs and a response plan let us notify the PDPC Office within 72 hours? | Logging policy · incident response plan · named decision-makers | Logs do not capture prompts or model versions, so the cause cannot be traced |
Question 6 is tied to a hard legal duty. The guideline's executive summary repeats that notifying the Office of the PDPC within 72 hours of becoming aware of a breach is required by Section 37(4), and that executives should make sure a system exists to do it. For what happens in the first hours, see the first 72 hours after a breach.
On what logs should contain, Annex B of the PDPC guideline is specific: the prompt input, model version, system prompt and output, so that evidence exists if prompt injection or a leak occurs. Annex C, item 6.5, balances this by advising that logs hold only what is needed and that personal data in prompts be masked before it is recorded.
How much should an AI system be allowed to decide alone?
ETDA's guideline describes three levels of human involvement and asks organisations to choose by the severity of the possible harm. The level with the most human control is called human-in-the-loop.
This is a level of involvement where humans control all of the work or decisions, with AI serving to provide advice or information but unable to work or make decisions on any action without a human.
The other two levels are human-over-the-loop, where the AI acts on its own but a person monitors it and can stop it, and human-out-of-the-loop, where nobody can intervene. The guideline offers four factors for choosing: the level of risk, the severity of the harm, whether the harm can be reversed, and whether human intervention is practical.
The outcome affects a person's chance of employment, and the PDPC guideline names employment screening as a high-risk use that should have a DPIA.
ETDA uses this very example. The system sorts without waiting for a person, but someone must be able to halt it when it sorts wrongly.
ETDA says to offer a route to a human member of staff, and the PDPC advises telling users at the start that they are talking to an automated system.
The most common trap is placing a person in the workflow without the authority or the time to disagree with the system. Section 5.4 of the PDPC guideline addresses this directly.
การให้มนุษย์เพียงยืนยันผลของระบบ (Rubber-stamping) ไม่ควรถือเป็นการทบทวนที่มีความหมาย และทำให้การตัดสินใจนั้นยังคงมีลักษณะเป็นการตัดสินใจอัตโนมัติตามข้อเท็จจริงThe same section sets three conditions for meaningful human review. The reviewer must weigh other information after the system produces its result. The reviewer must have the authority and competence to reverse or change that result. And the reviewer must be trained to recognise automation bias. A board can put each of these as a yes-or-no question.
Which AI projects should a board not approve yet?
The shortest answer sits in the box headed "key recommendation for executives" at the end of the DPIA section of the PDPC guideline.
ไม่ควรอนุมัติโครงการ AI ที่มีความเสี่ยงสูง เช่น อนุมัติเงิน หรือคัดกรองพนักงาน จนกว่าจะมีการทำประเมินผลกระทบ (DPIA) เพื่อตรวจสอบและอุดช่องโหว่ความเสี่ยงเฉพาะที่เกี่ยวกับ AI ให้แน่ใจก่อนThe high-risk criteria in the same section reach further than the box. They include automated decisions with legal or similarly significant effects on people, training models on sensitive data under Section 26 or on large volumes of children's data, systematic monitoring of people in public spaces, and generative AI that could produce distorted content damaging a person's reputation.
If a project meets any one of these, the author's view is that the approval paper should come with the DPIA attached, every time. A step-by-step method is in the DPIA guide. For an ethics review alongside it, read EIA or DPIA: which comes first.
A one-page checklist for the AI approval paper
This table combines both guidelines and can be attached to a board paper as it stands. The source column shows which document and section each line comes from, so the company secretary or DPO can check the original.
| # | Question that needs an answer | Who answers | Source |
|---|---|---|---|
| 1 | Which business goal does the project serve, and which indicators will measure it? | Project owner | ETDA 4.4 |
| 2 | Who may approve production use, and who is accountable for the AI's decisions? | AI Governance Council | ETDA 5.1 |
| 3 | What risk appetite applies to this project? | AI Governance Council | ETDA 5.1 · 6.2 |
| 4 | Controller or processor, and does the contract bar the vendor from training on our data? | Legal / procurement | PDPC Q1 · 3.1 |
| 5 | Lawful basis, and an LIA if legitimate interest is used | DPO | PDPC Q2 · 4.5 |
| 6 | DPIA result and residual risk after mitigation | DPO | PDPC Q3 · 6.2 |
| 7 | Level of human involvement, and a reviewer who can genuinely overturn the outcome | Process owner | ETDA 6.2 · PDPC 5.4 |
| 8 | Does the privacy notice say AI is used and what the data is used for? | DPO | PDPC 4.4 |
| 9 | Data subject rights channel, including deletion inside the AI system | DPO / IT | PDPC Q5 · chapter 9 |
| 10 | Traceable logs and a 72-hour breach notification plan | IT / security | PDPC Q6 · Annex B |
| 11 | Staff AI use policy and training | HR / DPO | PDPC 7.1 · Annex B |
| 12 | Reporting cycle back to the board: accuracy, complaints and errors | Project owner | ETDA 5.1 |
If some answers are still "in progress", a board could approve with conditions, for example a pilot on de-identified data first, with live personal data switched on only after the DPIA is finished. That approach is the author's suggestion; neither guideline prescribes a staged approval of this kind.
How binding are these two guidelines?
Not binding in themselves, and both say so. ETDA's guideline states in its section on scope and limitations that
failure to comply with these practices or recommendations does not constitute a violation of or non-compliance with the laws and regulations relevant to artificial intelligence in Thailand.
The same document says it is not a certification standard; organisations wanting certification must follow ISO/IEC 42001:2023, summarised in our ISO 42001 starter guide. The PDPC guideline says on its first page that it is preliminary advice:
อนึ่ง แนวทางการดำเนินการฉบับนี้มีวัตถุประสงค์เพื่อเป็นคำแนะนำในชั้นต้น เพื่อประโยชน์ของผู้ควบคุมข้อมูลส่วนบุคคลหรือผู้ที่เกี่ยวข้องในการนำไปปรับใช้เท่านั้น ไม่มีสภาพบังคับตามกฎหมายและไม่มีผลผูกพันในการพิจารณาความผิดDo not read this as optional. Most of what the PDPC guideline asks for is simply how to meet duties the Personal Data Protection Act already imposes: a lawful basis, notice of purpose, security measures and breach notification. If something goes wrong, this is the document that shows what the regulator expected the organisation to have done beforehand.
What can a board start this month?
- Ask management for an inventory of every AI system actually in use, including tools staff signed up for on their own. The PDPC guideline calls the latter shadow AI and advises banning it from company data. A sample policy is in our generative AI policy guide.
- Appoint or designate an AI Governance Council. An existing risk committee can take the role.
- Decide which projects must come to the board, at minimum anything meeting the PDPC's high-risk criteria.
- Use the 12-point checklist above as the standard attachment to AI approval papers.
- Set a reporting cycle, for example quarterly, covering accuracy, complaints and system errors.
To see where your organisation stands before the meeting, try the AI risk check; it takes a few minutes. For teams that maintain an AI register and the PDPC checklist as routine work, AIPDPA includes an AI registry, AI Risk Radar and the PDPC AI-guideline checklist; see it in the demo account.
Frequently asked questions
Must the board oversee AI itself, or can it delegate to IT?
ETDA's guideline makes an AI Governance Council, which includes senior executives, directly responsible for the outcomes of AI decisions. IT can do the technical work, but setting risk appetite and approving production use are policy-level decisions. The guideline is guidance, not law.
Does every AI project need a DPIA?
No. Annex C, item 6.1 of the PDPC guideline recommends a DPIA for projects with high risk to rights and freedoms, such as profiling, processing sensitive data or large volumes of children's data, and AI making decisions with legal or similarly significant effects.
Does this apply if we only use ChatGPT or another off-the-shelf tool?
Yes, in a lighter form. Annex C, item 6.3 of the PDPC guideline advises vetting the provider, reading its terms of use and adjusting privacy settings rather than keeping unsafe defaults. For staff use of public AI tools, see ChatGPT at work.
What is the difference between human-in-the-loop and human oversight?
In ETDA's guideline, human-in-the-loop means a person makes every decision and the AI only advises, while human-over-the-loop means the AI acts on its own under a person who can stop it. The PDPC guideline uses the term human oversight and stresses that the person must have real authority to reverse the outcome.
If we follow both guidelines fully, are we certified or free of liability?
Neither. ETDA states that its guideline is not a certification standard; certification requires ISO/IEC 42001:2023. Annex B of the PDPC guideline also says that completing its checklist does not mean legal liability is excluded.
Law and sources
- ETDA AI Governance Guideline for Executives, 2nd revision (guidance, not law) — 4.4 · 5.1 · 6.2
- PDPC Guideline on Personal Data Protection in the Development and Use of AI, version 1.0 (guidance, not law; Thai only) — Clause · 6 · 3.3 · 5.4 · 6.2 · Annex B–
Text in the "The text" boxes is copied word for word from AIPDPA's legal knowledge base, transcribed from the Royal Gazette and official documents; every edit is checked by the system against that base, character by character. English wording is an unofficial translation; the Thai text prevails. This article is general information, not legal advice for a particular case.
Do it in the system
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)