When a customer asks a human to review an AI decision: what Thai businesses must do

An online lending system replies in three minutes: "does not meet criteria". A claims engine flags one claim as likely fraud. A marketplace suspends a seller because of a low score. In each case the customer asks much the same thing: who decided, on what data, and can a person look again?

Most service desks can only say "the system decided". That is not enough, either under the rights Thailand's Personal Data Protection Act B.E. 2562 (2019) already gives, or under what the Personal Data Protection Committee (PDPC) now expects through its AI guideline.

Does the PDPA give a right to human review of automated decisions?

Not directly. We searched the PDPA text in our corpus and found no section on automated decision-making or a right to human intervention. The word for "automatic" appears only in Section 31, about data formats readable by automatic tools, which is a different matter.

Readers used to European law should be careful here. A stand-alone right not to be subject to solely automated decisions is not written into the PDPA as it stands. In Thailand today, a human-review channel comes from the PDPC's recommendations, combined with the other rights the PDPA already provides.

What does the PDPC AI guideline recommend when a customer asks for review?

The guideline addresses this in its chapter on data subject rights, section 9.3, as a caution for systems that decide with no human involvement where the effect is legal or similarly significant.

In English: where an AI system makes automated decisions, including profiling, without human involvement, and the outcome has legal or similarly significant effects, such as loan approval, hiring or insurance risk assessment, the organisation should, on request, have a documented process that lets the person ask for the decision to be checked and reviewed. The trigger is a request, so not every case needs a human, but there must be a way to ask and evidence that it works.

The FAQ annex of the same guideline answers the most common case, a refused service.

The answer is that organisations should provide this right: based on transparency and data accuracy, they should have a human-in-the-loop mechanism so the person can ask for a human to review the decision, for fairness and so the reasons can be explained.

Must customers be told in advance, and how much must be explained?

Section 5.4 of the PDPC AI guideline recommends advance notice and sets the depth of explanation: enough for the person to understand which of their data was used and how it affected the result. Source code need not be disclosed, but trade secrecy cannot be used to refuse any explanation at all.

The binding duty is PDPA Section 23: notify purposes, data collected and data subject rights before or at collection. If a loan application will be scored by a system, that purpose belongs in the privacy notice from the start.

For questions asked after the decision, Annex C, Q3.4 sets the line.

It says access should extend as far as the person needs to protect their rights: the sources and meaningful information about the logic involved in automated processing that affects them, but not trade secrets or algorithm source code.

Which PDPA rights can the customer use right now?

Even without an automated-decision section, an unhappy customer has at least two statutory tools. The first is the right of access in PDPA Section 30.

A customer who obtains a copy of the data used to score them can see whether stale or wrong data was in it. The organisation must respond within 30 days. For the full process see answering rights requests within 30 days.

The second is the accuracy duty in Section 35 and the correction route in Section 36. Automated results that are wrong because the input data was wrong usually end up here.

The right to object in Section 32 is narrower: it applies to processing based on Section 24 (4) or (5), to direct marketing and to research. A scoring system run on a contractual basis may fall outside Section 32, so check the basis each system actually uses.

What counts as genuine human review?

The PDPC AI guideline wants more than a name in the workflow. Section 9.3 says the reviewer must have enough authority and information to change the outcome.

The passage recommends a human-in-the-loop mechanism for high-risk or customer-affecting AI, letting the person request human intervention or review, and stresses that the reviewer must have the power and information to actually change the AI's decision, not merely confirm it. Section 5.4 adds three conditions: the reviewer weighs other information after the system's output, has the authority and competence to reverse it, and is trained to resist automation bias. Rubber-stamping, the guideline says, leaves the decision automated in fact. We cover this in more depth in what the board should ask before approving AI.

How should the review process be set up?

One recommended practice in section 5.4 sums up the whole job: provide a channel, let the person contest and add facts, record every request and outcome, and feed the statistics back into the system.

In English: the controller should give data subjects a channel to request human review, contest the decision and present further facts, record review requests and reversals as evidence, and use those statistics to improve the system.

1. Before launch
   State in the privacy notice that an automated system takes part, what data it uses and how to request human reviewPDPA Section 23; guideline 5.4
2. When giving the result
   Give the main reason briefly, plus a link or number to request review, not just "criteria not met"Guideline Annex C, Q3.2
3. On receiving a request
   Log the date and classify it as review, access or correction, because the deadlines differPDPA Sections 30, 35, 36
4. Review
   Route to someone with authority to reverse, consider the new facts, record reasons for upholding or reversingGuideline 5.4 and 9.3
5. Within 30 days
   If the customer also asked for a copy of their data, deliver it on timePDPA Section 30, paragraph four
6. Every quarter
   Check how often humans reverse the system and on what, and send it to the team that maintains the modelGuideline 5.4

The quarterly cycle is the AIPDPA team's suggestion. The guideline only says to use the statistics to improve the system; it sets no frequency.

Which systems need a DPIA before launch?

For systems whose decisions have legal or similarly significant effects, the PDPC AI guideline recommends a data protection impact assessment before processing starts, and avoiding the activity or adding human oversight if the risk is significant.

That bullet says: if automated decisions have legal or similarly significant effects, a DPIA should be done before processing, and if the assessment shows significant risk, the activity should be avoided or human oversight put in place. The clearest cases are the guideline's own examples: lending, credit scoring, staff selection and insurance. Hiring has its own article, AI in hiring and staff evaluation; for the method, see the DPIA guide.

In AIPDPA, customer rights requests arrive through a public portal with a 30-day clock, and decision systems sit in the AI registry with the PDPC guideline checklist. Together they give you evidence that review actually happened when someone asks.

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)