The Three-Layer Design Behind HR Inquiry AI — Why an Internal FAQ Bot Cannot Simply Be Reused

The Three-Layer Design Behind HR Inquiry AI — Why an Internal FAQ Bot Cannot Simply Be Reused

Using generative AI to cut down the volume of internal inquiries is no longer unusual at Japanese-owned factories in Thailand. HR inquiry AI, however, is the one place where a bot that works well for another department will not deliver when it is carried across unchanged. The reason is simple. Most of the questions that land on HR have a different answer depending on who is asking. Work rules read the same to everyone, but a leave balance and a payslip belong to one person only. Reuse a bot without designing around that structural difference and one of two things happens — nobody uses it, or somebody sees another employee’s data.

This article separates the difference into layers, then uses an in-house model calculation built around a Japanese-owned manufacturing site in Thailand to show, in numbers, which layer pays back and which one does not. Automation of internal inquiries in general is covered in Automating Internal Helpdesk Inquiries. The argument here is that HR alone requires a different design.

Internal Inquiries Come in Two Kinds — Shared Knowledge and Individually Linked

Splitting inbound internal inquiries into two groups by the nature of the answer clears up the design discussion immediately.

Shared-knowledge inquiries return the same answer no matter who asks. How a clause of the work rules should be read, how many days a leave entitlement runs to, the cut-off date for expense claims, how to operate an internal system. The answer is written down somewhere, and the identity of the person asking has no bearing on it. Inquiries directed at general affairs or IT sit almost entirely in this group.

Individually linked inquiries are ones where the answer is determined by the asker’s own record. How many days of paid leave do I have left right now, what is this deduction line on last month’s payslip, why is one of last week’s clock-ins missing, why did my social security contribution change this month. The same sentence produces a different answer depending on who typed it. And that answer is information nobody but the individual concerned is allowed to see.

Published case studies of internal chatbots skew overwhelmingly toward the shared-knowledge type, because “search the documents and answer with the source attached” is the easier thing to build. What HR teams actually experience is the reverse — more than half the inquiry volume is individually linked. Deploy an HR FAQ bot that automates only the shared-knowledge half and the workload left on the HR team’s desk barely moves. That is the direct consequence of the asymmetry.

A Work Rules Chatbot Is the Entrance, Not the Building

What people describe as a work rules chatbot falls, in this classification, squarely on the shared-knowledge side. It is easy to build, hard to get badly wrong, and easy to explain internally. As a first step it is a reasonable choice.

At Japanese-owned factories in Thailand, though, plenty of questions remain unanswerable even when the model has the work rules in front of it. Thailand’s Labour Protection Act obliges employers to grant at least 6 days of annual paid leave per year to employees who have completed one year of continuous service, but it contains no mechanism that automatically increases the statutory entitlement with length of service. Whether it increases is a matter for each company’s own work rules. Separate provisions cover sick leave, paid for up to 30 days per year, and personal business leave, paid for up to 3 days per year.

So the thing employees genuinely want to know — how many days can I actually take right now — is a figure that comes neither from the statute nor from the work rules. It only appears once the individual’s usage history is reconciled against the company’s own granting rules. A chatbot that reads policy documents never reaches that last step.

Why a Design Built to Reduce General Affairs Inquiries Does Not Transfer to HR

The standard way to reduce shared-knowledge inquiries is to make internal documents searchable, retrieve the relevant ones when a question arrives, pass them to the model, and have it answer strictly from those documents. This is the pattern known as RAG, and in the context of reducing general affairs inquiries it delivers perfectly good results.

The reason it does not transfer cleanly to HR is that three things bite at once.

First, the unit of retrieval is different. Shared-knowledge RAG searches across a company-wide document set. Everyone hits the same index and gets the same documents back. In the individually linked case, what has to be retrieved is one row belonging to the person asking. That is not a document search across a corpus, it is a lookup against a specific record in the HR and payroll system. This is a permissions and API problem, not a search problem.

Second, the granularity of permissions is different. Shared-knowledge RAG applies access control too, but usually at the level of department or job grade. Keeping board-level material away from general staff is sufficient. In the individually linked case, the unit of permission drops all the way down to the individual. Two people in the same section holding the same grade must not be able to see each other’s leave balances. No amount of refinement to a department-level permission model reaches this row-level, person-by-person access control. The design concept itself has to change.

Third, the strength of authentication is different. If all the system does is read out a policy published on the intranet, the strength of the login is not heavily scrutinised. Open an endpoint that returns payslip contents, however, and unless you can confirm that the person asking really is who they claim to be, there is nothing to discuss. It presupposes that the chat account is reliably bound to the employee number in the HR system, and that this binding is reliably updated when people transfer or leave.

Extend an existing RAG deployment onto HR data without settling these points and the failure takes a predictable shape. Data extracted from the HR and payroll system gets loaded into the same index as the policy documents. Retrieval does not distinguish between askers, so depending on how a question is phrased, another employee’s salary information or leave balance ends up mixed into the answer. Start your design from the assumption that the seemingly obvious property of “only the individual can see their own data” is simply not present in an existing internal inquiry bot.

The idea of drawing a line around what the system is allowed to answer is not unique to internal use. The design of tiered answering authority is covered in detail in Designing a Customer Service Chatbot. What differs in HR is that the line is drawn by who owns the data rather than by what topic is being discussed.

HR Data Seen Through Thailand’s PDPA — Ordinary Personal Data Versus Sensitive Data

For a company with a site in Thailand, this design question becomes a Personal Data Protection Act (PDPA) question directly. Stopping at the coarse view that “all HR data is dangerous” makes it impossible to tell necessary investment from unnecessary investment. Two lines are worth drawing.

The first line separates ordinary personal data from sensitive personal data. Section 26 of Thailand’s PDPA defines sensitive personal information to include ethnicity and racial origin, political opinions, religious or philosophical beliefs, sexual behaviour, criminal records, health information, disability, trade union information, genetic data, and biometric data. Collection of these categories is prohibited in principle and permitted only under exceptions, such as where the data subject has given explicit consent.

The second line asks whether there is a lawful basis for handling the data without consent. GVA Professional Group’s commentary on Thai labour law states that salary information may be disclosed to external parties such as an accounting firm without the individual’s consent where this is necessary for the performance of the employment contract. Sensitive information such as health check results, on the other hand, cannot in principle be collected without the employee’s clear consent. The same commentary notes that, given the power imbalance between employer and employee, the validity of consent obtained in that setting can itself be open to challenge.

Applying both lines to HR inquiries produces the following picture.

The rows that matter most in practice are the fourth and fifth. Leave balances and payslips can be handled provided you build a proper “visible to the individual only” design. Reasons for sick leave and information tied to medical certificates, however, run into a separate requirement — explicit consent — that no amount of design work removes. The realistic approach is therefore to deliberately place sensitive inquiries outside the scope of the initial design and provide only an escalation path to a human.

It is also worth registering that Thailand’s PDPA is actively enforced. Commentary published by One Asia Lawyers describes penalty cases including 153,120 baht imposed on each of several organisations in a government agency matter, 1,210,000 baht on a hospital and 16,940 baht on an employee in a private hospital matter, a total of 7,000,000 baht on a technology retailer, 2,500,000 baht on a cosmetics company, and 500,000 baht on a retailer plus 3,000,000 baht on its vendor in a toy retailer matter. More useful than the amounts themselves, for building internal consensus, is the fact that penalties are actually being handed down under this regime.

How to write generative AI use into internal policy is covered in Writing a Generative AI Usage Policy. Where HR data is in play, treat that policy as needing two additions — the technical measures that prevent data being returned to anyone but its owner, and the scope of sensitive information placed out of bounds.

A Three-Layer Model for Back Office Inquiry Automation — Layers A, B, and C

The next step is to break all of the above into units you can actually make investment decisions about. Applied to HR, back office inquiry automation splits into three layers, and once split, cost and effect can be decomposed layer by layer.

Layer A can be delivered as an extension of an existing internal helpdesk bot. Because it handles no personal data, the PDPA questions it raises are limited. A site in Thailand will need the same answers returned in Japanese, Thai, and English, but the multilingual design itself can follow the approach set out in Chatbot Implementation Costs and Rollout Steps.

Layer B is the centre of this article. Everything described as a leave balance lookup AI or a payslip lookup AI belongs to this layer. The moment you step into it, what you need changes from document preparation to system integration and permission design. On choosing a technical architecture, the three-configuration framework in Building a Secure Generative AI Environment is a useful reference, but note that where HR data is involved, tenant-level controls are not enough. Per-individual permissions remain the last problem standing.

Layer C covers operations that write data, such as first-line acceptance of leave requests or the creation of attendance correction requests. Unlike read-only Layer B, a mistake here damages live records. Connection to the approval workflow, plus cancellation and send-back paths, become mandatory.

These three layers are also, directly, three layers of cost. The mapping below is worth fixing in mind before moving into the numbers.

An In-House Model Calculation — How Much HR Inquiry Work a Thai Site Can Remove

From here on the numbers. What follows is a model that TOMAS TECH assembled for illustration, not measured results from any particular company. Change the assumptions and the conclusions change with them, so read it with your own figures substituted in.

Next, current inquiry volumes and the time going into them.

The formulas are “monthly volume multiplied by minutes per inquiry, divided by 60, equals monthly hours” and “monthly hours multiplied by 12 equals annual hours”. Converting 2,268.0 annual hours at an hourly rate of 150 baht gives 340,200 baht.

Those 189.0 hours a month represent 17.9% of the 1,056 combined scheduled monthly hours of the six HR and general affairs staff. In late January 2026, Gourica Inc. ran a survey of how HR professionals at large Japanese companies spend their time, finding a split of 47.5% core work, 29.0% specialist routine work, and 23.5% routine work, with non-core work accounting for 52.5% overall. The 17.9% in this model sits comfortably inside that 23.5% of routine work. If anything, treat it as a conservative setting.

Hours Removed, Layer by Layer

Automated answer rates are set per layer at the level expected once usage has settled. Layer A is set higher because the answers are written down in the policy documents, Layer B slightly lower because identity checks and exceptions intervene, and Layer C at half because the approval decision stays with a human.

Taking Layer B as the worked example — 780 multiplied by 70% gives 546, then 546 multiplied by 10 minutes divided by 60 gives 91.0 hours per month, 91.0 hours multiplied by 12 gives 1,092.0 hours per year, and 1,092.0 hours multiplied by 150 baht gives 163,800 baht per year.

One conclusion is already visible in this table. 72.5% of the hours removed come from Layer B. Layer A accounts for 17.6% and Layer C for 10.0%. That distribution is exactly why a design that automates only the shared-knowledge half struggles to produce results in HR.

Cost, Layer by Layer

Costs are set as increments, on the assumption that Layer B is stacked on Layer A and Layer C on Layer B.

Annual running cost covers model usage fees and hosting, plus document updates when rules change, periodic review of the permission tables, and retention of audit logs. HR is an area where rule changes occur every year, so a thin estimate of running cost collapses in the first year.

Net Benefit and Payback Period

For each cumulative scope, here are annual net benefit (annual value removed minus annual running cost) and simple payback period (upfront investment divided by annual net benefit).

Viewed as increments, the difference in character between the layers becomes sharper still.

Three points should be read out of these two tables.

On its own, Layer A has almost all of its savings eaten by running cost. Against 39,780 baht of annual value removed sits 30,000 baht of annual running cost, leaving a net benefit of 9,780 baht. Recovering the 180,000 baht of upfront investment takes 18.4 years. Put a work rules chatbot forward as a standalone capital request and, on the numbers alone, it does not get approved. That is what the model says. Layer A should be positioned as the foundation for reaching Layer B, not as a layer that argues its own return on investment.

Layer B is the most efficient layer when judged on its own increment. Against 420,000 baht of incremental upfront investment sits 103,800 baht of incremental net benefit, and payback arrives in 4.0 years. It is the only one of the three layers whose effect matches the scale of the investment.

Adding Layer C actually makes the overall payback period worse. The 5.3 years for Layer A plus Layer B stretches to 8.1 years once Layer C is stacked on. Layer C’s incremental net benefit is -7,500 baht, because its 30,000 baht of annual running cost exceeds the 22,500 baht it removes.

Why Layer C Is the Asymmetric One

Three reasons combine to make Layer C the exception.

First, submitting a request is already a fast operation. Leave requests are typically completed through a form today, and HR time per case runs to 5 minutes, half the 10 minutes of an individually linked lookup. There is simply less raw material available to remove.

Second, the automation rate does not climb. Even where AI handles first-line acceptance of a request, the approval decision remains with a person. Automating that step introduces a separate control problem, so raising the rate is not an objective in itself.

Third, the upfront investment is heavy. Connecting to the approval workflow, building the request creation API, and designing cancellation and send-back paths for mistaken operations all take more implementation and verification effort than read-only Layer B. Because a failed write damages live data, the test coverage has to be finer as well.

Layer C therefore lands in the combination of a small pool of removable work and a large implementation cost. It does carry value that is hard to monetise, such as preventing missed submissions and accepting requests around the clock, but it cannot be justified on payback period alone. The sensible sequence is to complete Layer B first and revisit the decision once operations there are stable.

Sensitivity Analysis — Adoption Moves the Payback Period by More Than Double

The most uncertain input in the model above is Layer B’s automated answer rate. Varying that alone across 50%, 70%, and 85% gives the following. Layer A stays fixed at 65%, because the completeness of a policy FAQ answer is easy to judge and the variance in adoption is small. Layer C is excluded from this analysis because its incremental net benefit is negative.

Whether the automated answer rate lands at 50% or 85% splits Layer B’s incremental payback between 7.4 years and 3.0 years. The variable that moves the result by more than double is neither the size of the investment nor the technical architecture — it is whether the thing actually gets used. This is the most commonly underrated variable in an HR inquiry AI investment decision. Measures that lift adoption, such as concentrating announcements around payday, providing an access route from shop-floor terminals, and getting Thai-language answer quality solid first, have a bigger effect on payback than any additional system spend.

Across Multiple Sites, the Conclusion Changes

Looked at one site at a time, even the base case for Layer A plus Layer B pays back in 5.3 years. For a company that applies a three-year payback threshold, the proposal fails right there.

For a group operating three sites of comparable size, the conclusion changes. From the second site onwards, design assets such as the document structure, the permission model, the PDPA consent flow, and the API integration specifications can be reused, so upfront investment is set at 40% of the first site. Running cost, by contrast, is set at 70% from the second site onwards, because work rules differ from site to site.

Upfront investment across three sites is 600,000 plus 600,000 multiplied by 40% multiplied by 2, giving 1,080,000 baht. Annual running cost is 90,000 plus 90,000 multiplied by 70% multiplied by 2, giving 216,000 baht. Annual value removed is 203,580 multiplied by 3, giving 610,740 baht. Payback is 1,080,000 divided by 394,740, or 2.7 years, which clears the three-year threshold.

The same Layer B investment fails at a single site and succeeds across three. HR inquiry handling repeats the same structure at every site, so once the design exists, the marginal cost of extending it falls. For groups with several sites in Thailand, or with sites elsewhere in ASEAN, it is worth designing for that horizontal rollout from the outset. Conversely, a single-site company will find Layer B hard to justify on labour cost savings alone and should evaluate it alongside the risk-reduction value of having a mechanism that does not return other people’s data.

When Starting Small Makes the Payback Worse

There is one more counterintuitive result worth confirming. If Layer B is too heavy for a single site, narrowing the scope seems like the natural response. So here is the model for a variant that limits Layer B to leave balance lookups only, skips the payroll system entirely, and integrates with the time and attendance system alone. Assume that leave balance lookups account for 330 of the 780 individually linked inquiries, with an upfront investment of 240,000 baht, an annual running cost of 42,000 baht, and an automated answer rate of 70%.

330 multiplied by 70% gives 231, then 231 multiplied by 10 minutes divided by 60 gives 38.5 hours per month, 38.5 hours multiplied by 12 gives 462.0 hours per year, and 462.0 hours multiplied by 150 baht gives 69,300 baht per year. Annual net benefit is 69,300 minus 42,000, or 27,300 baht, and payback is 240,000 divided by 27,300, or 8.8 years.

Against the 4.0-year incremental payback of building Layer B in full, narrowing the scope makes matters worse. The reason is that the costs of identity verification, row-level permissions, and PDPA consent management do not fall proportionally when the scope shrinks. Most of Layer B’s upfront investment goes not into the number of data items handled but into the mechanism itself — returning an individual’s data to that individual and nobody else. Once you are building that mechanism, putting payslips, attendance records, and social security contributions on the same foundation alongside leave balances improves the return per unit.

None of this argues against starting small. What should be narrowed, though, is the set of departments or the number of users, not the range of data items. Build the authentication and permission foundation to the full design from day one, then widen the user base department by department, and you can launch without damaging the payback.

How to Sequence the Rollout — With Layer B as the Real Target

Given the model, the sequence works out as follows.

• Log one month of current inquiries, sort them into shared-knowledge and individually linked, and measure volumes and handling times for real
• Break the individually linked group down by item and confirm which tables in the HR, payroll, and attendance systems would need to be read to answer each one
• Identify the inquiries that touch sensitive information, exclude them from the initial scope, and design the escalation path to a human
• Decide how chat accounts will be bound to employee numbers, and how that binding will be updated on joining, transfer, and departure
• Build Layer A as the foundation while running the Layer B permission design and consent management requirements definition in parallel
• Run Layer B in a limited set of departments and measure the automated answer rate and the incidence of wrong answers
• Use those measured figures to decide on the company-wide rollout and on extending to other sites
• Revisit Layer C’s return on investment only after Layer B has been running stably for a year or more

The critical point in this sequence is to begin the Layer B permission design while Layer A is still being built. Complete Layer A first and only then start defining Layer B requirements, and the way identities are bound and audit logs are captured has to be reworked, which means rebuilding the Layer A implementation as well. The model puts Layer B’s incremental upfront investment at 420,000 baht, and that figure assumes Layer B was anticipated at the point Layer A was designed.

Frequently Asked Questions (FAQ)

What is HR inquiry AI?

It refers to a mechanism in which generative AI provides the first-line answer to inquiries employees send to the HR department. The design differs, however, from an internal FAQ bot built for general affairs or IT. HR inquiries split into a shared-knowledge type, where the answer is the same for everyone, as with work rules, and an individually linked type, where the answer is determined by the person’s own record, as with leave balances and payslips. More than half the volume falls into the latter. Handling the individually linked type requires API integration with the HR and payroll system, identity verification, and row-level access control, none of which is achievable as an extension of document search.

How much does an HR FAQ AI cost to deploy?

It varies widely with the scope handled. In the model used in this article, covering one Japanese-owned manufacturing site in Thailand with 800 employees, Layer A covering policy FAQs alone is set at 180,000 baht upfront and 30,000 baht per year to run, Layer B extending to lookups of the individual’s own data adds an incremental 420,000 baht upfront and 60,000 baht per year, and Layer C covering request creation adds an incremental 260,000 baht upfront and 30,000 baht per year. These are figures from an illustrative model and will move with how easily your existing systems can be integrated and how many languages are in scope. Build the numbers you take into a capital request from a month of measured inquiry volumes at your own site.

Could a leave balance lookup AI or a payslip lookup AI end up exposing another employee’s data?

It can if the design is wrong. The most dangerous pattern is loading data extracted from the HR and payroll system into the same search index as the policy documents. In that configuration retrieval does not distinguish between askers, so depending on how a question is phrased, another employee’s information can be mixed into the answer. Preventing it requires binding chat accounts reliably to employee numbers and then implementing row-level access control that restricts the lookup to the individual’s own row. Keeping an audit log of who accessed whose data and when also lets you determine the scope of any incident that does occur.

What should be decided first to avoid breaching the PDPA in Thailand?

Decide what stays out of scope. Section 26 of Thailand’s PDPA defines categories such as health information and trade union information as sensitive personal information, prohibits their collection in principle, and permits it only under exceptions such as explicit consent from the data subject. Reasons for sick leave and information tied to medical certificates may fall within that definition, so the realistic approach is to keep them outside the initial scope and provide only an escalation path to a human. Salary information, by contrast, may be handled without the individual’s consent to the extent necessary for performing the employment contract. Whether you may handle data and whether you have a mechanism preventing its disclosure to anyone else are separate questions, so confirm both.

How far has internal use of generative AI actually progressed?

In a survey of corporate trends in generative AI conducted by Teikoku Databank in March 2026, with 10,312 valid responses, 34.5% of companies said they were using generative AI and 36.9% said they were not. The most frequently cited concern was the accuracy of information at 50.4%, with the risk of information leakage cited by 33.5%. Narrowing to HR departments, the HR Department Trend Survey 2026 from Persol Research and Consulting puts the share of companies using AI routinely within HR at 39.2%, with 34.8% citing the risk of confidential information leakage as a challenge in AI adoption. The reading is that HR is ahead of other departments in adoption while carrying an equally high level of concern about leakage.

Summary — In HR, the Answer Depends on Who Asked

Here is the article in short.

Internal inquiries split into a shared-knowledge type, where everyone gets the same answer, and an individually linked type, where the answer is determined by the person’s own record. Internal FAQ bots built for general affairs and IT handle only the former, and carrying one into HR leaves most inquiries unanswered. What HR needs is not a search across documents but a mechanism that reads the individual’s own row in the HR and payroll system.

That difference shows up in three places — the unit of retrieval, the granularity of permissions, and the strength of authentication. Permissions in particular have to drop from the department level down to row level, meaning the individual. Extend an existing RAG deployment straight onto HR data and another employee’s leave balance or salary information can end up mixed into an answer.

From a Thai PDPA standpoint, draw two lines. Salary information and leave balances are ordinary personal data and can be handled on the basis of performing the employment contract. Reasons for sick leave and information tied to medical certificates may fall under the sensitive categories in Section 26, so feeding them into generative AI without explicit consent is itself the risk. Keep sensitive information out of scope in the initial design.

In the illustrative model, 72.5% of the hours removed came from Layer B, the lookups of an individual’s own data. Layer A on its own takes 18.4 years to pay back, and Layer C has a negative incremental net benefit, pushing the overall payback from 5.3 years out to 8.1 years when added. The numbers point to a clear order — Layer B is the real target, Layer A is its foundation, and Layer C waits.

And the same Layer B investment fails at 5.3 years for a single site while succeeding at 2.7 years across three. Because most of Layer B’s cost goes into the foundation that returns an individual’s data to that individual alone, narrowing the data in scope does not improve the return — the narrowed case is worse, at 8.8 years — whereas efficiency rises as you extend across sites and users. The sensitivity analysis split Layer B’s incremental payback between 7.4 years and 3.0 years depending on whether the automated answer rate lands at 50% or 85%. Adoption moves the outcome far more than the size of the budget.

Which layer your own inquiry volume sits in and in what quantity, whether your existing HR and payroll system exposes an interface that can retrieve data per individual, and where you draw the line on sensitive information. Sorting out those three points before you request quotations will save rework later. We are equally happy to talk with companies still at the early stage of asking whether they should step into Layer B at all. Get in touch through our contact form and we can cover the specifics of a Thai site and the design for rolling out across several of them.

References

1. Corporate trends survey on generative AI

Source for the findings that 34.5% of companies use generative AI and 36.9% do not, and that the accuracy of information was cited as a challenge by 50.4% and the risk of information leakage by 33.5%. The survey ran from 17 March to 31 March 2026 with 10,312 valid responses.

Survey on Corporate Trends in Generative AI | Teikoku Databank

2. HR Department Trend Survey 2026

Source for the findings that 39.2% of companies use AI routinely within their HR department and that 34.8% cited the risk of confidential information leakage as a challenge in AI adoption. The survey ran from 4 March to 16 March 2026 with 2,000 respondents, covering companies of 300 or more employees and respondents at section-chief level or above.

HR Department Trend Survey 2026 | Persol Research and Consulting

3. Survey on how HR professionals at large Japanese companies spend their time

Source for the finding that HR working time splits into 47.5% core work, 29.0% specialist routine work, and 23.5% routine work, with non-core work accounting for 52.5% overall. Conducted in late January 2026 with 1,020 responses from business professionals at large companies of 1,000 or more employees.

Survey on the Working Realities of HR Professionals at Large Japanese Companies | Gourica Inc.

4. Leave entitlements in Thailand

Source for the points that Thailand’s Labour Protection Act requires at least 6 days of annual paid leave per year for employees with one year or more of continuous service, that there is no statutory obligation to increase this with length of service, and that sick leave is paid for up to 30 days per year and personal business leave for up to 3 days per year.

Holidays and Leave under Thai Labour Practice | Avance Legal Group

5. Sensitive personal information under Thailand’s PDPA

Source for the point that Section 26 of Thailand’s PDPA defines ethnicity and racial origin, political opinions, religious and philosophical beliefs, sexual behaviour, criminal records, health information, disability, trade union information, genetic data, and biometric data as sensitive personal information, prohibiting collection in principle and permitting it only under exceptions such as explicit consent from the data subject.

Overview of Thailand’s Personal Data Protection Act | Business and Law

6. Practical commentary on Thailand’s PDPA

A supplementary reference consulted on the classification of sensitive personal information and the role of explicit consent.

Commentary on Thailand’s PDPA | Bigbeat Thailand

7. Enforcement cases under Thailand’s PDPA

Source for the penalty cases of 153,120 baht imposed on each organisation in a government agency matter, 1,210,000 baht on a hospital and 16,940 baht on an employee in a private hospital matter, a total of 7,000,000 baht on a technology retailer, 2,500,000 baht on a cosmetics company, and 500,000 baht on a retailer plus 3,000,000 baht on its vendor in a toy retailer matter.

Enforcement Cases under Thailand’s PDPA | One Asia Lawyers

8. Handling of employee personal information

Source for the points that salary information may be disclosed to external parties such as an accounting firm without the individual’s consent where necessary for performing the employment contract, that sensitive information such as health check results cannot in principle be collected without the employee’s clear consent, and that the validity of consent obtained under the power imbalance between employer and employee can be open to challenge.

Thai Labour Law and Practice vol.14 – Handling of Employee Personal Information | GVA Professional Group