Thailand's Draft AI Act: Five Questions to Ask Developers Before You Sign an AI System Contract

An organization's procurement team is drafting a contract to develop a customer intake system. One bidder attached a function that uses AI to help answer messages automatically. The legal team asks: we heard there is a draft Thai AI law, does the contract we are drafting need to provide for anything?

The straightforward answer is that nobody can answer fully yet, because a draft is not law. But that does not mean nothing can be done. This article is written from the viewpoint of a team that delivers and maintains systems, and it is not legal advice. We describe what the sources we could open state, then translate the structure of the draft into questions a client can put to a developer starting today, without waiting for when the draft passes or what its final form looks like.

What the draft is, and what we actually know about it

A Thansettakij report dated 17 July 2569 (2026) says the Electronic Transactions Development Agency (ETDA) is preparing a draft Artificial Intelligence Act B.E. ...., citing a push by the Ministry of Digital Economy and Society. The same report states the draft has seven chapters (see the Thansettakij report).

1. General provisions, including definitions.

2. Promotion of AI development and use, such as testing in controlled environments, data sharing, standards and certification.

3. Risk control, including prohibited uses such as unfair discrimination, high-risk AI systems, use in the public sector, transparency of AI-generated content such as deepfakes, and consumer protection.

4. Enforcement, under which the regulator can order corrections and, for non-compliance, may suspend a service or its use.

5. Serious incidents, which open the way to temporary suspension or recall of a system.

6. Oversight in cases not under a single sector-specific authority.

7. Penalties, including civil liability and administrative fines.

The limits of this information need to be stated clearly. The report does not state the amount of fines, does not say what stage of the legislative process the draft is at, and does not give an effective date, and we could not open ETDA's full draft ourselves. Our search also found that ETDA has held several rounds of public hearings on the draft principles of an AI law, and a later revised draft may differ from earlier rounds. We therefore include no statement predicting when the draft will pass or what any article in the final version will say.

Why people commissioning systems should care though it is only a draft

The reason is not that a law is coming. The reason is that the structure of the draft shows what a regulator will ask when something happens, and those questions are all things a client should know about their own system anyway, whether or not a law is issued.

Read chapters four and five from the systems team's viewpoint. The regulator can order corrections, suspend a service, or recall a system. Translated into a systems question, that is: if there were an order to stop using one AI function, can our system stop just that one, who has the authority to do so, how long would it take, and what would other systems that depend on its output do next?

Chapter three talks about transparency of AI-generated content and consumer protection. That translates into: does the end user know they are encountering AI content, and if a customer complains, can we trace back what the system answered and why?

Five questions to ask the developer before signing

We translate the structure of the draft into questions that do not wait for the final text. Each can be used with an external developer and with your own internal team.

Question one: where does this system have functions that use AI, and what does each do? The answer should be a list, not a broad sentence that the system uses AI to help with work. A developer who can answer with a list knows what they put in. A developer who cannot may be calling external services without the client knowing, which is why we suggest keeping an AI function inventory in the handover documents.

Question two: is the AI output used for further automatic decisions? A function that drafts a reply for staff to review before sending carries different risk from one that sends the reply straight to the customer, and from one that scores or screens people in a way that may affect someone's rights. The report names categories of prohibited and high-risk uses. We do not know what the final criteria will be, but knowing where the output goes next is basic information anyone needs for assessment.

Question three: what model or service is behind it, and what data is sent out? A system that calls an external model provider's API sends the user's text out of the system. If that text contains personal data, this also touches the PDPA. We wrote about data location in our article on cloud regions and the PDPA. The answer you should get is the service name, the types of data sent, and the contract the developer has with that provider.

Question four: can this function be switched off individually, and who can do it? This follows directly from the enforcement and serious-incident chapters. A system whose AI function is tied to the core process so tightly that it cannot be switched off turns a suspension order into an order to stop the business. We suggest asking about a feature flag or equivalent mechanism, and asking the developer to rehearse switching off before handover, in the same spirit as the restore rehearsal we wrote about in our article on RPO, RTO and restore testing.

Question five: if something abnormal happens, who records it, who reports it, and what evidence is kept? The serious-incident chapter says the law is thinking about events, not only design. The system should keep logs showing what data went in, what output came out, and the version of the model or prompt used at that moment, so it can be traced back. Details on retention periods and keeping personal data out of logs are in our article on log retention.

Writing it into the contract without the risk of writing the draft wrong

While the law itself is not settled, writing contract clauses that cite articles or definitions of the draft may bind you to wording that has already changed. We think the contract should be tied to things that can be verified in the system, not to the name of a law.

• The developer must deliver an AI function inventory stating the work each does, the external providers, and the types of data sent out, as part of the handover documents, updated whenever a function is added or changed.

• AI functions must be switchable individually without affecting other core functions, and the client holds the right to switch them off.

• The system must record the working traces of the AI according to an agreed list and keep them for the period the client specifies.

• The developer must notify the client when the underlying model or provider changes, because the behavior of the system can change without a single line of the client's code changing.

• When a relevant law or announcement takes effect, the parties will discuss adjusting the system as needed, with the way of sharing the workload agreed in advance rather than left as a later dispute.

The last clause is the one we see as most important for procurement, because nobody knows what the law will look like. A good contract is not one that predicts correctly but one that says what each party does if the prediction is wrong. This is in line with what we wrote in our article on what to check before signing an annual maintenance contract, which is about writing contracts that can handle the unknown.

What developers should be able to answer too

From the developer's side, a draft with chapters on civil liability and administrative fines means that whoever builds the system might also be asked, not only the user. We do not know how the final law will divide liability, and that has to wait for the text. In practice, though, a developer who can answer the five questions above clearly, with an inventory, a switch-off mechanism and logs, is in a better position than one who has to take the system apart to find the answers.

As a development team, we think being transparent with the client about where the system has AI benefits both sides, and should not be information the client has to dig out alone.

Limits we should state plainly

If the system you are commissioning or using has no AI function at all, and no plan to add one in the next couple of years, there is nothing you need to do with this article now. Our advice is to keep it and come back when a bidder attaches an AI function to a proposal, which may happen sooner than you think, because a lot of software adds this kind of function in routine updates.

Also, the five questions in this article are our opinion, not a list the draft law sets. We took the seven-chapter structure the report describes and translated it into the language of systems work. Someone who reads the actual draft may translate it differently, and if the final draft changes structure, some questions may not match what the regulator asks, which is why we suggest tying the contract to what the system can do and not to article numbers.

Finally, the report we used is the only one whose content we could fully confirm. If you are making a high-value decision, read the draft directly from ETDA or the Ministry of Digital Economy and Society, and have legal counsel read it with you.

Objections we often hear

A common objection is that the draft can still change a lot, so doing it now is wasted. That is right if the work is to modify the system to match a particular article of the draft. But the five questions are not tied to any article. They are information a system administrator should already have: which external services the system calls, whether a function can be switched off, whether there are logs. If the draft changes completely, the work is still useful for maintaining the system, answering customer questionnaires, and handing the system to a new team.

Another is that the off-the-shelf software vendor says they take care of the AI part, so there is nothing to worry about. That may be true, but the five questions can still be asked, and the answers should be in writing. If the vendor can say clearly where the AI is, what data leaves, and how to switch it off, that is a good sign. If the answer is only not to worry, the client still lacks the information to decide.

Where to start

1. Gather the contracts and proposals that contain AI functions, both those being drafted and those in use. Do not forget off-the-shelf software that added new functions in an update.

2. Send the five questions to each developer or vendor and ask for answers in a document, not in a meeting.

3. Try switching off one AI function in a test environment and see whether the other systems keep working. Note what breaks.

4. Check whether the system keeps logs of AI functions and, if so, how much personal data is in them.

5. Arrange for legal to read the full draft together with the table of answers, and set a review date for when news of the draft's progress arrives.

Summary

Thailand's draft AI Act is still a draft, and we do not know what the final version will be. If you take one thing from this article, change the question from what the law will require to whether our system can switch AI functions off one at a time and whether there are traces to check afterwards. The second question can be answered from today, and it is useful whatever form the law takes.

If you would like to talk through the details of a project, you can reach us at 088-983-9386 or [email protected]. Our office is in Bang Kapi, Bangkok. For organizations still drafting a scope of work, we are glad to arrange a conversation to understand the problem first, without needing complete documents. And if we find that the problem is not yet at the point of needing a new system, we will say so plainly, because starting a project at the wrong time costs more than waiting another quarter.