AI Implementation and Data Protection for Businesses in Thailand
Most businesses in Thailand adopting AI have made a data protection decision without realising they made one. It usually happens the first time someone pastes a customer list into a chatbot to tidy it up.
This page sets out how Anglo Siam Advisory handles client data in AI and automation work, and what any business should ask of whoever builds those systems for them.
The decision nobody remembers making
AI adoption in a small business rarely starts with a project. It starts with one person finding a tool that saves them an hour.
Within a few months the same tool is handling guest lists, booking records, supplier contracts, staff details and customer complaints. Nothing visibly goes wrong, so the practice spreads. Nobody logged when it started.
The problem is not the tool. It is that personal data has moved somewhere nobody chose, under terms nobody read, with no record of what went where. That becomes a live issue the first time a customer asks what you hold on them, or a system is breached, or a client's own compliance team asks you to describe your processing.
Where this becomes a legal question
We are business advisors, not lawyers, and we are clear about which side of that line a question sits on. Advising a business to operate within the law is squarely our job. Telling you what the law means for your particular circumstances is not, and we will say so rather than guess.
On our side of the line: Thailand's Personal Data Protection Act applies to your business, AI tools routinely move personal data outside Thailand, and most SMEs using those tools have addressed neither. Recognising that, and building systems that do not make it worse, is ordinary commercial judgement.
On the other side: whether your specific processing has a lawful basis, whether a particular transfer needs a particular safeguard, whether you need a Data Protection Officer, and what to do if the regulator contacts you. Those are questions for a qualified Thai lawyer, and we will tell you when you have reached one.
For scale, because this tends to get overstated by people selling compliance: there is no blanket exemption for small companies, but most SMEs are lower risk than the marketing suggests, and most do not need a Data Protection Officer. Enforcement is real without being indiscriminate. The regulator has issued fines across eight orders totalling more than THB 21.5 million, for ordinary failures rather than exotic ones.
One of those cases matters if you are hiring anyone to build systems for you. A service provider was fined THB 3 million while the client that engaged it was fined THB 500,000. Engaging someone does not move the exposure off your desk, and it does not put all of it on theirs either. Worth knowing how a provider works before the build rather than after.
How ASA handles data in AI and automation work
Scope first
A build collects only what it is scoped to collect. Processing details are identified in the Statement of Work before it is signable, which means the question of what the system touches is answered in writing before anything is built.
Pseudonymise by default
Most analytical and automation work does not require personal data at all. Job records, invoices, pricing, utilisation and financial data can generally be pseudonymised before they reach us, which removes the question rather than managing it.
The SOW names who holds what
Some engagements run entirely on the client's own accounts, with ASA configuring the systems and handing them over, after which we have no production role and are not processing your data. Others involve ASA processing on the client's behalf. Which applies is stated in the Statement of Work rather than left to assumption.
Human review where decisions matter
Where an AI service or an automated rule affects people, the engagement states what is reviewed by a person and which decisions the system is not permitted to make on its own.
A data handling record at handover
You receive a written record of what the system collects, where it goes, who can access it and how long it is retained. That record is acknowledged before the system goes into unrestricted production use.
Documented handover
Builds are handed over against a security checklist, with the client's own privacy notice confirmed in writing. Everything is documented so your team can maintain it, and so a future hire inherits working systems rather than starting again.
Records, not verification
ASA records and organises the information supplied to it. Unless expressly agreed in scope, we do not independently verify or certify insurance, qualifications, licences, tax status or regulatory compliance. Those decisions remain yours.
What we do not do
ASA does not undertake regulated work. We are not lawyers, accountants, auditors or licensed data protection practitioners, and we do not present ourselves as any of them.
We also do not build everything ourselves. Where an engagement needs regulated or specialist input, ASA brings in licensed Thai professionals and properly registered Thai firms, and that work sits with them. In practice that means a lawyer for anything turning on legal interpretation, an accountant for anything touching tax or statutory filings, and sector specialists where a build reaches into a regulated domain. More on partner coordination and referrals.
The honest version of this is a selling point rather than a limitation. An advisor who tells you when to call a lawyer is more useful than one who has a go.
What to ask anyone building AI or automation for you
These apply to us as much as anyone. If a provider cannot answer most of them, that is itself the finding.
Where does our data go?
Physically, and through which countries.
Who is controller, who is processor?
And is that written down anywhere.
What exactly does this collect?
And does a written list of that exist.
Can this run pseudonymised?
Instead of on the real thing.
What happens in a breach?
Who notices, and who notifies the regulator inside 72 hours.
What do we get at handover?
Documentation, or a system only they understand.
What if you stop trading?
Could our own team maintain this tomorrow.
I have sat in enough Phuket businesses to know how this actually goes. Nobody decides to put customer data into an AI tool. Someone just does it, because it saves an hour on a Tuesday, and then it quietly becomes how the job gets done.
I am not going to pretend that is a scandal. It is a reasonable thing for a busy person to do with a tool that works. But it is a decision, and most businesses cannot currently tell you what they decided, which is the part that matters when somebody eventually asks.
ASA's position is not that you should use less AI. It is that you should be able to describe what your systems do with people's information, in a sentence, without having to go and find out first. That is a low bar. Most businesses are not currently over it.
UK clients
For UK businesses, the equivalent obligations sit under UK GDPR, and transfers to Thailand require a specific safeguard which we put in place before any data moves. Our approach to pseudonymisation, documentation and handover is the same. See UK data analytics for how the work itself is structured.
Not sure what your systems are touching?
If you are already using AI tools and cannot fully describe what they touch, that is the normal starting position and a sensible thing to fix before it grows. A first conversation costs nothing and is spent working out what you actually have.