Your AI did it. The record says you did.
Thailand's draft AI law would hold you liable whether or not you were careless. Only 19% of Thai organisations have extended their AI rules to the departments actually using AI
- A proposed Thai AI law would make organizations strictly liable for damages caused by AI, shifting the legal defense from proving carefulness to proving what actually happened via system records.
- Most organizations are unprepared for this, as their AI systems often operate using a human employee's credentials or a shared login instead of a unique digital identity.
- This practice creates a critical liability issue where an AI's actions are officially logged under a person's name, making the individual and their company legally responsible for the AI's behavior.
By Asst. Dr. Tanwa Arpornthip, Senior Advisor, Venture Capital, SCB 10X
Thailand's draft AI law would hold you liable whether or not you were careless. Only 19% of Thai organisations have extended their AI rules to the departments actually using AI.
The most useful question I ask in a diligence meeting has stopped being about accuracy. It is now this: when your software does something, whose name appears in the log? The answers have got worse over the past two years, because software stopped only saying things and started doing them.
Two Thai items from July belong in the same sentence, and are not yet being read that way.
The first: Amazon Web Services' Unlocking Thailand's AI Potential study found 43% of surveyed Thai organisations now use AI continuously, up from 32% a year earlier. More than 70% of frequent users sit outside IT, in sales, marketing and human resources. Only 19% of organisations have extended their AI governance policies to those users.
The second: on 2 July, the Electronic Transactions Development Agency opened public consultation on a draft Act on Artificial Intelligence. Among its provisions is joint liability for AI-related damage regardless of wilful act or negligence, with defences limited to force majeure, the victim's own conduct, or compliance with an official order.
The short version: the draft law makes carefulness stop counting and records start counting, and most Thai deployments cannot produce the record.
What strict liability actually changes
Under a negligence standard, the argument is about whether you behaved reasonably. You can win that argument with process, training logs, and a well-drafted policy.
Under the standard in the draft, that argument is not available. Liability attaches to the damage, not to your conduct around it. Being careful remains worth doing, and it stops being a defence.
What replaces it is narrower and more mechanical. If your conduct cannot excuse you, the live questions become what actually happened, which system did it, and whether anyone can establish that months later.
That is a record question. Records are the thing nobody bought.
Why the record is usually missing
The mechanism is duller than people expect.
When a person uses a system, they log in as themselves, and the log says so. When an automated system acts, it needs credentials too, and the cheapest way to give it some is to let it borrow a person's, or to issue one shared login that several systems use.
Both work immediately. Both are invisible in a demo. Both mean every action the software takes is recorded under a human's name, or under a shared name belonging to nobody.
Research published in April by the Cloud Security Alliance with Zenity found roughly 18% of organisations give an automated agent its own distinct identity. The rest run on shared credentials or a person's permissions. Palo Alto Networks' Unit 42 reported that identity weaknesses featured in 89% of more than 750 incidents it investigated during 2025.
Two limits I would rather state than bury. Those figures come from firms selling products that address the problem they measured, and they are survey and incident-response data rather than audited counts. Treat them as direction, not as decimals.
The direction holds anyway, because the Thai number arrives at the same place by a different road. AWS found 19% of Thai organisations extending governance to the people using AI most. The Cloud Security Alliance found 18% giving software its own name. Different populations, different questions, roughly one in five either way.
Three questions
First: does the AI act under its own name, or under somebody's? If it borrows a staff login, then in your own records that member of staff did everything the software did.
Second: is each action checked as it happens, or was permission granted once? Permission granted once and held indefinitely is not a control. It is a standing arrangement nobody revisits.
Third: could you reconstruct a single afternoon, six months from now, for somebody who is not obliged to believe you? A regulator, an insurer, a court.
If the third answer is no, the first two are where to look.
The cost of waiting
None of this is expensive at the start. All of it is expensive afterwards.
Giving software its own identity is a configuration decision, made once, when the system is deployed. Reconstructing who did what across two years of shared logins is forensic work, done under time pressure, usually while somebody is asking about damages.
A widely used work tool disclosed a fault in 2025 that exposed data across customer boundaries for 34 days, reaching roughly 1,000 customers before anyone noticed. The number that matters there is not 1,000. It is 34. That is how long a problem runs when the records cannot tell one actor from another.
The inversion
Thai firms are preparing for AI regulation as though it were a quality problem. The conversation is about accuracy, bias, and whether the model is good enough. Those matter, and they are not what this draft turns on.
The bill as written says your care is not a defence. That converts the question from "were we responsible" into "can we show what happened", and the second is answered by plumbing installed long before anybody needed it.
Here is the falsifiable version, with its condition stated plainly. If the Act passes broadly in this form, then by 31 December 2027 at least one Thai enforcement action or civil claim will turn on the adequacy of a defendant's records rather than on whether the AI system was defective. If the first wave turns instead on model quality or on labelling duties, I was wrong about where the pressure lands.
If the bill does not pass, that prediction cannot be scored either way, and I would rather say so now than claim a hit later on a test that never ran. The plumbing argument survives regardless. The record gap exists whether or not a statute cares about it. The only thing the statute changes is who else gets to ask.
AWS figures are from Unlocking Thailand's AI Potential 2026. Agent-identity data is Cloud Security Alliance with Zenity, April 2026; incident data is Palo Alto Networks Unit 42 for 2025. Draft Act provisions are published for consultation on 2 July 2026 and may change before enactment.
Asst. Dr. Tanwa Arpornthip is Senior Advisor to the Venture Capital Team at SCB 10X, where he provides insights on emerging technologies, innovation ecosystems, and startup development. He is also a lecturer at the Faculty of Technology and Environment, Prince of Songkla University, Phuket Campus.
About SCB 10X
SCB 10X is the disruptive technology investment arm of SCBX Group. With an investment track record since 2016, SCB 10X has deployed over USD 500 million globally into startups in AI, blockchain, and fintech. SCB 10X has backed exceptional companies such as Together AI, Pagaya, Ripple, Fireblocks, Anchorage Digital
Beyond capital, SCB 10X partners with our portfolio founders to test, grow and scale their solutions through SCBX’s network, unlocking commercial opportunities into Thailand and Southeast Asia. Mandated as the group’s speedboat, we discover and ship state-of-the-art technologies and solutions into SCBX group.
For more information, please visit https://scb10x.com/
