Generative AI Usage Policy 2026 ｜ Four Gaps the Head Office Version Leaves at a Thai Site

The generative AI usage policy written by the Japanese head office lands in the Thai subsidiary. You open it, and what you find is a list of prohibitions. Yet the first question anyone asks on the ground is the opposite one — so what are we allowed to do? This article takes the position that a usage policy does not protect you by declaring which tools are permitted. It protects two things: the routes by which company data leaves the company, and accountability for signing off on AI output before it is used in the business. On that basis, we work through the four gaps that open up when the head office version is carried into a Thai site.

Why a generative AI usage policy ends up filed and forgotten

More and more managers report the same thing. The policy was distributed, and nothing on the shop floor or in the back office changed. The cause is rarely the quality of the drafting. It is that the document was written as a list of prohibitions before anyone settled what the document is supposed to protect. A list of prohibitions looks comprehensive to the person who wrote it. To the person reading it, it offers no way to work out which line applies to the task in front of them. A document you cannot apply to your own work drops out of practice the moment it is read.

The ranking of concerns shows an inversion

Teikoku Databank ran its survey on corporate trends in generative AI from 17 March to 31 March 2026, sending questionnaires to 23,349 companies nationwide and obtaining 10,312 valid responses, a response rate of 44.2%. Companies that said they are using generative AI came to 34.5%, made up of 4.4% using it heavily and 30.2% using it somewhat. By company size, large enterprises were at 46.5%, medium-sized companies at 32.4%, and small companies at 28.0%.

What deserves attention is not the adoption rate itself but the ranking of the challenges companies named.

Companies naming the risk of information leakage as a challenge came to 33.5%, while those naming rules on where responsibility sits when something goes wrong came to only 25.5%. That order is the wrong way round, and it is the starting point of this article. Leakage can be substantially closed off by technical controls. Accountability cannot be closed off by technology at all. Turning off training use, splitting tenants, tightening account scope — all of that acts on the question of where the data you type in ends up. None of it answers the question of who checked the number the AI produced and decided to use it in the business. There is no settings screen for that. The only instrument that decides it is the policy.

Stated direction has run ahead of operating design

The Ministry of Internal Affairs and Communications published its 2025 White Paper on Information and Communications, carrying the results of a 2025 survey on the progress of information and communications technology. In it, the share of Japanese companies whose stated position on generative AI was to use it actively stood at 49.7% for fiscal 2024, up from 42.7% in fiscal 2023 — seven points in a single year. Close to half of companies now declare an active stance. Read the other way, that means the declaration of intent has run ahead of the design of day-to-day operation.

The problem is that the document meant to bridge intent and operation gets written as a list of prohibitions. A company that has publicly committed to active use hands its staff a sheet that says only what not to do. At an overseas site, that gap widens further because a language barrier sits in the middle of it.

What the policy is actually there to protect

There are only two things a usage policy needs to protect. The first is the set of routes by which data leaves the company. Which class of data may travel by which route, and how far may it go. This is entry-side design, and it takes effect before an incident. The second is accountability at the point where AI output is adopted into the work. Who checked it, whose name it goes out under, and which record you follow if it turns out to be wrong. This is exit-side design, and it takes effect after an incident.

Whether a given tool is allowed is merely a consequence derived from those two. Yet most policies are written with the tool as the subject of the sentence. Because the subject is a consequence, every new tool on the market triggers a revision, and every stretch of time in which revision has not caught up is a blank. How to run the introduction itself is covered in our guide to rolling out generative AI, so this article narrows to what protects the company once the rollout has happened.

Four gaps that open when the head office policy reaches Thailand

A Japanese head office policy is written on three assumptions. It assumes Japanese law, it assumes readers who read Japanese, and it assumes an IT environment that the head office administers. At a Thai site, all three collapse.

Here is the resulting set of gaps in summary. The chapters that follow take each one in turn.

These four are not independent defects. They all descend from one shared cause — the policy imagines a reader who works inside the head office environment, in the head office language, under head office law, using tools the head office knows about. An overseas site falls outside every one of those assumptions, so four gaps open at once.

The gaps produce a policy you can obey and still be exposed

This is easy to misread, so let us be explicit. The four gaps are not about local staff breaking the policy. They are about the company remaining exposed while the policy is being followed to the letter.

Suppose the head office version says that consumer-grade free generative AI must not be used for work, and a local staff member follows that faithfully. That person may instead run an internal quotation through a browser translation extension. The policy says nothing about translation extensions, so there is no violation. The data has still left the company. That is gap 3.

The same pattern appears in gap 4. Someone obeys the line that says output must not be used as-is, reads it over, corrects it, and sends it to a customer. But there is no record anywhere that it was read and corrected. Six months later a complaint arrives, and all the company can produce is the clause itself. The policy was obeyed and accountability is still blank.

A local entity cannot rewrite the head office policy

Most Japanese-owned subsidiaries have no authority to amend a group policy set by the parent. So even when the gaps are visible, the only thing the site can do is add a supplementary document. That is also a sound design choice on its own merits. Rather than waiting for a full revision at head office, leave the head office version in place as the superior document and add a single implementation standard at site level that covers the four items the head office version does not touch.

Those four chapters map directly onto the obligations that Thailand’s draft AI Act would place on a deployer, discussed below. That is why enactment would not force a rewrite. Conversely, a policy assembled by pulling model clauses from somewhere and lining them up tends to need rebuilding the moment the substance of the law is fixed. What has to be decided before the clauses are written is not the clauses. It is the content of those four chapters.

Gap 1 jurisdiction — Thailand’s draft AI Act puts duties on the side that uses AI

Let us settle the facts first. Thailand’s Draft Act on Artificial Intelligence is still a draft. As of 7 August 2026, the date of writing, it has not been enacted. Some commentary online describes it as already in force, but the analyses published by law firms all treat it as a draft. The confusion most likely comes from Vietnam’s AI Law, whose commencement date is discussed in the next chapter. For Thailand, the accurate statement is that a draft has been published and the consultation window has closed.

The responsible authority is the ETDA, the Electronic Transactions Development Agency. It released a new version of the draft on 2 July 2026 and ran a public hearing of roughly 30 days. The consultation window appears to have closed in early August 2026.

Not being enacted, however, is not a reason to defer policy work. The structure of obligation the draft sets out is of a kind Japanese policies simply do not contain, the grace period after enactment is short, and most of what it asks for is sound internal control whether or not a law requires it.

The three risk categories the draft sets out

The draft sorts AI systems into three categories.

The Designated AI band matters most in practice. Even if nothing you run falls inside it today, a single royal decree can bring it into scope for notification or registration. Unless you have worked out in advance what you would be able to produce if that happened, you will be creating records in a hurry on the day of designation.

The draft also contains an extraterritorial provision. Development, provision or use of AI that affects people in Thailand is in scope even where the conduct takes place outside the country. If a system running on a head office server in Japan affects employees or customers in Thailand, being located in Japan is not by itself a reason to be out of scope. Thailand’s wider institutional environment and its position as a regional hub are covered in our overview of AI adoption and regulation in Thailand.

Deployer obligations — the part missing from Japanese policies

What bites an operating company directly is the set of obligations on the deployer, the party that uses AI. The important point is that these fall by name on ordinary companies that buy AI and use it, not only on companies that develop it.

Open the head office policy and check whether it contains clauses answering those five points. In most cases the only thing present is a single sentence close to “comply with the provider’s terms of service”. There is no appointment of a supervisor, no log retention period, no contact point for notifying a regulator. The reason is straightforward: current Japanese law does not require any of it, and what the law does not require does not get written into the policy. That is the jurisdiction gap.

The weight of a six-month log requirement

Of the five obligations, the one that takes longest to prepare for is six-month retention of operating logs. It is the only item you cannot construct retroactively. You can name a supervisor tomorrow and write a risk assessment this week. Logs do not exist for any date before the day you started collecting them.

And for as long as people are using free generative AI on personal accounts, it is structurally impossible for the company to retain logs at all, because no record of who entered what and when sits under company control. That single point is enough to show that quietly tolerating free services is a configuration that cannot satisfy deployer obligations.

Penalties and the commencement sequence

The draft sets administrative fines of 1,000,000 to 5,000,000 baht per violation, and also provides for the possibility of service suspension orders and blocking orders through internet service providers. More important than the absolute figures is the unit — per violation. If the same kind of deficiency turns up across several use cases, each may be counted separately.

Commencement is staged. The core provisions would take effect immediately on publication in the Government Gazette, while the provisions on risk management and supervision would take effect 180 days later. A hundred and eighty days looks generous until you combine it with a duty to hold six months of logs. To hold six months of logs on the day the duty takes effect, you must have started collecting them six months earlier. In other words, 180 days is exactly long enough if you begin collecting logs on day one of the grace period, and not long enough if you start designing after enactment.

The draft also provides for an AI Governance Center under the ETDA and spells out its relationship with the PDPA, Thailand’s personal data protection law. Running a generative AI policy separately from PDPA compliance creates duplicate administration that will not survive contact with reality, so the sensible design is to build it on top of existing PDPA practice.

Gap 1 continued — Vietnam’s AI Law is already in force

Thailand’s act has not been enacted. Vietnam’s Law on Artificial Intelligence, by contrast, has been passed and is in force. Mixing the two up means getting the scope of your policy wrong across the board.

Vietnam’s AI Law was passed as Law No. 134/2025/QH15 on 10 December 2025 and has been in force since 1 March 2026. It applies to foreign entities as well as domestic ones. Existing systems are given a transition period.

Seen from the Japanese parent company’s side, that means chatbots and document generation already running at a Vietnamese site have to be brought into line with the law by 1 March 2027. For anything touching healthcare, education or finance, the date is 1 September 2027. Either way, there is not much time left.

Transparency duties differ between provider and deployer

The duty that bites first in practice is transparency, and its content differs depending on whether you provide the system or use it.

An operating company is normally a deployer. The duty is not “embed a machine-readable marker yourself” but “disclose where there is a risk of misleading people”, which means it cannot be handled as a tool setting. It has to be written as an internal judgement standard. You need to spell out, in terms of the site’s actual work, what counts as a risk of causing confusion. Generated product photography. Images of people in an internal newsletter. Narration audio in an explanatory video for customers. These are the situations where a call has to be made. The same law also provides for a regulatory sandbox and for priority access to national AI infrastructure.

Putting the two countries side by side settles the design

Thailand not yet enacted, Vietnam already in force. That asymmetry has a direct bearing on how the policy should be written, because if you write separate clause sets per jurisdiction, every movement in one of them forces a revision of the whole document.

Instead, separate the common part from the jurisdiction-specific part. The common part holds the four chapters — data classification, route authorisation design, sign-off duty for output, logging and supervision. The jurisdiction-specific part holds nothing but numbers and proper nouns: the minimum retention period, the name of the authority to be notified, the wording of any required disclosure. Split that way, enactment of Thailand’s AI Act means changing a few lines. For a company with overseas sites, ease of revision should itself be treated as a design requirement of the policy.

Gap 2 language — rebuild the policy so it can be applied, not merely translated

Plenty of companies believe that translating the head office version into Thai completes the local rollout. Translation does not put it into practice, and the reason is not translation quality. It is how the original was written.

Japanese policies are typically written with sentences ending in “must not”. Translate faithfully and you get a list of prohibitions in Thai as well. What the local staff member is left holding is a list of forbidden acts. What the work actually needs is the inverse — for this task, which tool may I use, and how far may the data go. So before translation, the subject of the original sentence has to be rewritten from the act to the class of data being handled. Once the subject is the data, the way you reach a judgement stays stable even when the tool changes or the work changes.

The phrases that break in translation

When Japanese policies are actually rendered into Thai or Vietnamese, the expressions that fail to survive follow a pattern.

None of these five looks especially vague while you are reading in Japanese, because the reader fills in the context. Translation removes that room, and what you are left with is a document in which the vagueness sits exposed.

Decide up front which language the policy operates in

At a Thai site, a policy shuttles between three languages. The head office writes in Japanese, expatriate managers read in English, local staff operate in Thai. What has to be decided is which version is authoritative. Keep the Japanese version authoritative and the Thai version becomes a reference translation — but most local staff do not read Japanese, so real decisions are made from the Thai version regardless.

The workable landing point is a two-layer structure. The upper-level policy document stays authoritative in the head office’s Japanese version, and the site’s implementation standard is authoritative in Thai. That implementation standard only needs four things in it: data classification, route authorisation, the sign-off procedure, and how records are kept. If those can be read in Thai, the operation runs.

More models now handle Thai, and that changes the premise

Some policies quietly assume that generative AI will be used in English. That assumption is eroding too.

In Thailand, the National Science and Technology Development Agency, the Ministry of Higher Education, Science, Research and Innovation, and NECTEC are leading ThaiLLM, an effort to build Thai-language foundation models. The budget is 80 million baht. There are two model sizes, 8 billion and 30 billion parameters, trained on more than 100 billion tokens. Four sub-models sit under the programme — OpenThaiGPT from AIEAT, Pathumma from NECTEC, Typhoon-S from SCB 10X, and THaLLE from KBTG — with KBTG, SCB 10X and VISTEC beginning adoption. The intended uses go well beyond chatbots to agentic patterns such as automation, decision support, integration with internal systems, and customer-facing service.

The implication for the policy is clear. Using generative AI in Thai for real work becomes a genuine option. Until now there was an extra step, translating into English before typing anything in, and that step incidentally suppressed how much data left the building. Once people can type in Thai directly, the suppression disappears. A policy written on the assumption of English use means Thai-language use happens outside the policy entirely.

Closing the language gap is not a matter of raising translation accuracy. It is deciding who makes judgements in which language, and then putting enough information into the policy that judgements can be made in that language.

Gap 3 routes — from tool lists to data routes

The most common way to write a generative AI usage policy is to list permitted and forbidden tools. It is easy to administer. It also fails to catch the routes by which data leaves the company.

Here is what writing by tool name misses, set against the routes that actually occur at a site.

Of those six, the number that a permit-and-forbid list of tool names can handle is effectively zero. The reason is common to all of them — none of them comes with any sense of “I am using a generative AI service”. The person pasting into a translation site does not think they are using generative AI. Behaviour that is not consciously registered will not be stopped by a rule that assumes conscious registration. Worse, the more forbidden tools you enumerate, the more shadow AI you get, because people simply move to a service with a different name, and the list itself teaches the reading that anything not on the list is fine.

What changes when you write by route

Make the subject of the sentence the route by which data leaves the company, not the tool name. Three things go into the policy. First, a definition of an authorised route — expressed as a combination of conditions, such as an account the company administers, from a device the company administers, to a service where training use has been excluded by contract. Second, the principle that data does not leave by any route other than an authorised one. Third, where to apply and on what criteria when someone wants a new route added.

Written this way, a new service on the market does not require a revision. Its treatment is already determined by the fact that it is not yet among the authorised routes. A revision is needed only when you add one more route.

Routes are closed by settings, not by prose

The route gap cannot be closed by policy text alone. It is closed by technical configuration, and the policy is the document that gives that configuration its basis. Concretely, that means issuing company-administered accounts, controlling extension installation on work devices, setting the defaults for recording and transcription in meeting tools, and confirming the contractual exclusion of training use at signing. Do those four, and then write into the policy that an authorised route means this configuration. Many companies distribute the policy first and leave the settings for later, which leaves the policy hanging in mid-air. The procedure for taking stock of permissions and accounts is set out in our article on Microsoft Copilot rollout and permission review. Where generative AI reads internal data, existing access rights become the boundary of what the output can contain, so route design and permission review are better treated as one and the same piece of work.

Gap 4 accountability — write the sign-off duty for AI output into the clauses

Of the four gaps, this is the one least often written down. As noted above, only 25.5% of companies named rules on where responsibility sits when something goes wrong as a challenge, fewer than the 33.5% who named the risk of information leakage. And yet the situation in which a company is actually asked to explain itself is the one where faulty output has gone outside.

Most policies contain a sentence along the lines of “generative AI output is for reference only, and the final judgement must be made by a human”. The direction is right, but as a clause it does not function, because it does not settle who, at what point, and on what basis is deemed to have made that judgement. To make it function, four blanks have to be filled.

The fourth item, the record, is the one people resist most. But without a record, all the company can produce after the fact is the clause. As with logs in the previous chapter, records cannot be created retroactively.

Writing the record requirement so it stays light

The trick to sustaining records is to vary the granularity by type of deliverable. Trying to record everything at the same weight does not last.

With those four tiers, the recording burden lands on a subset of the work, and for the people doing it the requirement amounts to adding one line to anything that goes to a customer.

Do not grade by how much the AI did

There is one instinct to avoid when drafting. It is grading accountability by the AI’s contribution — superior approval if the whole text was AI-generated, none if only part of it was. That cannot be made to work in practice. Text gets rewritten, figures get transcribed, and the boundary of what the AI produced disappears after the fact. Put an untestable criterion into a clause and the judgement falls to individual self-declaration, which amounts to having no criterion at all.

Grade by how the output is used instead. Does it stay inside the company, does it go outside, does it carry contractual effect. How something was used remains determinable after the fact. Put only determinable criteria into clauses — that is the governing principle of a sign-off provision.

Note that in Vietnam a deployer is under a duty to disclose that content is AI-generated where there is a risk of confusion about authenticity. If a Vietnamese site produces images or video for customers, the response is twofold: keep an internal sign-off record, and make an external disclosure. Sign-off establishes internal accountability; disclosure protects the external audience. The purposes differ, so they should be written as separate clauses.

Enumerating the items to be checked has a useful side effect. It settles what training has to cover. The content of internal training becomes the practice of matching figures, proper nouns, dates, cited sources and names of laws against primary sources. Better prompting makes output more plausible, and plausibility is not correctness.

The four data classes to settle before drafting

All three of the gaps above depend on the same precondition — how the data you handle is divided up. Write clauses without a classification and undefined words such as “confidential information” and “important information” scatter through the text, and operation stops the moment it is translated.

Four classes are enough. More than that and nobody remembers them; fewer and the judgements get too coarse.

Building that table is the first task in creating a policy. The clauses come afterwards. Reverse the order and you end up trying to define the classification inside the clauses, which makes them long and vague at the same time.

Two principles for when the line is unclear

Two principles help discussions converge. First, when in doubt, classify upward. A classification can be relaxed later; data that has already left cannot be recalled. Second, judge by asking whether it would be a problem if a competitor had the information in front of them. If it would, it is L3 or above. That produces far more reproducible judgements than an abstract debate about confidentiality.

There is one more case that regularly causes trouble in practice — information that becomes sensitive in combination. A counterparty name alone may be L3 and a quantity alone L2, but put the two together and the shape of the business becomes readable. The classification table should always carry a line stating that where a single input mixes several classes, it is treated as the highest class present.

For L4, we recommend the line that it is not entered even after anonymisation, because there is no way to settle who judges whether the anonymisation was adequate. Delete the name, and if the department, job title and year of joining remain, the individual is still identifiable. Leave that judgement to individuals and the variance between them becomes the leakage risk. Simple lines are the ones that get observed. Note also that under Thailand’s draft AI Act the obligations for high-risk AI are stated to include data governance aligned with the PDPA, so data containing personal information should not be handled solely under the generative AI policy. Keep it on the same register as existing PDPA practice.

Where AI reads internal data, classification becomes permission

The classification table really earns its keep once you start letting generative AI read internal documents. In that configuration the system pulls internal documents and composes an answer regardless of what the user typed in. Controlling the input is therefore not enough; the range of documents the system may read has to be controlled by class as well. That means excluding whole L4 storage folders from scope and making L3 searchable only by departments that already hold viewing rights. How to go about it in practice is set out in our article on connecting internal data.

The point to watch is that the permission settings on existing shared folders become the boundary of what can appear in output. Any shared folder that has been running for years almost certainly contains places visible to people who were never meant to see them. It simply never surfaced, because humans do not go looking. Put a search layer on top and it surfaces immediately. Building the classification table is, in substance, the same work as taking stock of permissions. And keep the table to a single A4 page. Criteria that run to several pages do not get consulted, and criteria that are not consulted may as well not exist.

Three secure generative AI environments, costed so you can re-check the arithmetic

Once the four chapters of the policy are settled, the next thing to decide is the environment. We compare three options here. The figures are an estimate under the assumptions this article sets out, not an indication of general pricing. Every assumption is disclosed, so substitute your own numbers and redo the arithmetic.

Option A, quiet tolerance of free services, is the status quo — employees use free generative AI on personal accounts and the company neither forbids nor permits it. Option B, enterprise SaaS, means the company contracts for accounts and distributes them, excludes training use, and can obtain logs from an admin console. Option C, own tenant plus API, means standing up your own tenant in the cloud and calling models through an API, which gives you complete freedom over how records are designed at the cost of build and operating effort.

The assumptions behind the estimate

Start by putting every assumption on the table. An estimate that hides this cannot be re-checked.

The 50 baht per hour rate is the conversion for an hour of shop-floor work; the real rate for administrative and IT staff is higher. Using a low rate understates internal effort and biases the comparison in favour of building your own, so a sensitivity analysis follows below.

Option A — quiet tolerance of free services

The quantity column is a placeholder to be replaced with your own record. On amounts alone, Option A wins overwhelmingly. That table is also a demonstration of the limits of cost comparison, because Option A has an omission that does not appear in money — the company cannot retain operating logs. Thailand’s draft AI Act would require a deployer to retain operating logs for at least six months, and there is no means of satisfying that with personal accounts. Under a draft that sets administrative fines of 1,000,000 to 5,000,000 baht per violation, leaving that omission outside the cost table is not an honest comparison.

Option B — enterprise SaaS

Most of Option B’s cost is the seat charge, and internal effort is small. Cost rises in proportion to headcount while the administrator’s workload barely moves, so it looks expensive while the user base is small and closes the gap on building your own as the user base grows.

Option C — own tenant plus API

The API usage line is not filled in with a number because there is no basis on which to place one. Unit prices vary by model and contract form, and consumption varies by use case. Insert a placeholder figure and that single cell flips the conclusion on its own. Leaving unfillable cells empty is a condition of an estimate that can be re-checked.

Comparing B and C, Option B totals 304,400 baht a year while Option C is 25,600 baht plus X, so the two are level when X equals 278,800 baht. On a monthly basis that is 23,233 baht, and divided across 50 people it is roughly 465 baht per person per month. The reading is therefore that if one person consumes more than about 465 baht of API a month, Option B is cheaper, and below that Option C is cheaper. The figure falls straight out of the assumptions, so swap in your own headcount and effort and recompute.

Sensitivity analysis — moving the labour rate

The labour rate is the most volatile assumption in the set. When you move it, move every monetised item of internal effort on the cost side at the same time. Moving only one side distorts the conclusion.

There is exactly one thing to read out of that. The higher the labour rate, the lower the breakeven X. Option C, where effort dominates, is more strongly affected by a rise in the rate, so the conditions under which building your own comes out ahead get tighter as personnel costs rise. In a company where the real rate for IT staff exceeds the shop-floor conversion, Option C can look cheaper and then reverse the moment the rate is corrected to reality.

Why there is no benefit figure and no payback period

This estimate does not convert time saved into money, because we do not hold measured figures. Stack unmeasured numbers on the benefit side and the conclusion is decided by the placeholder, however precise the cost side is. For the same reason there is no payback period. If the benefit has no basis, the payback period has no basis either, and a payback period without a basis is not an input to a decision — it is decoration to stop the decision stalling.

Choose the option not by cost but by whether it can satisfy the requirements the policy set. Can you retain logs for six months. Can training use be excluded. Do the contract terms allow class L3 data. Pick the cheapest of the options that meet all three. Option A is the cheapest and fails the first, so it drops out, and only once the field is down to B and C does the breakeven calculation start to mean anything. Functional comparison is covered in our comparison of enterprise generative AI tools.

A 90-day order for turning the policy into practice

A policy is finished not on the day it is written but on the day it starts operating. Here is the sequence for producing and running the site-level implementation standard, over 90 days. The order carries meaning, so do not rearrange it.

Not a single clause is written in those 30 days. You only decide. Start writing clauses first and you will be filling what has not been decided with vague words, which collapse the moment they are translated. In the inventory step, make sure to include interviews with local staff, because the tools the administrative function knows about and the tools people actually use are not the same set.

Days 31 to 60 — close the routes

This is the period in which decisions are turned into technical configuration. It is the step most often skipped.

Starting log collection is the highest priority in that list. Logs cannot be built retroactively, so begin collecting them even if the other settings are unfinished. Write the clauses of the implementation standard during the same period. Since it is only a transcription of what has already been decided, the work is light. Write it in the language in which judgements are made at the site. Writing in Japanese and translating is more fragile than writing in the language of judgement and then translating into Japanese to brief the head office.

Days 61 to 90 — put it into motion

Do not read prohibitions aloud at the briefing session. Nobody retains them. Instead, bring three real tasks from the site and ask the participants which class each one falls into and which route could be used. Wherever the answers diverge, the classification table or the route definition is inadequate, so take that point away for revision. This is where the completeness of the policy is measured.

Appoint the supervisor during this period too. It is one of the items that would be required of a deployer if Thailand’s draft AI Act is enacted, and there is no need to wait for enactment. Decide by job title, record the individual’s name, and add one line on the handover procedure when the holder changes. A concurrent appointment is fine; leaving the post vacant is not. What matters at the embedding stage is less the policy itself than whether the scope of permitted use has actually reached the people doing the work — if only the prohibitions get through, usage stops. Ways to raise real usage rates are set out in our article on generative AI adoption and enablement.

Write the review cycle into the policy text as well. We recommend the classification table annually, the route list every six months, and the jurisdiction-specific part as required. It is “as required” because Thailand’s AI Act has not been enacted. When it is, check the minimum retention period and the name of the authority to be notified, and replace only the affected passages. Companies with Vietnamese sites should fix the transition deadlines for existing systems, 1 March 2027 and 1 September 2027 for healthcare, education and finance, into the review plan now.

Frequently asked questions

These are the five questions that come up most often in policy work.

Where should we start when writing a generative AI usage policy

Not with the clauses. The first thing to produce is the single page of four data classes. Without a classification, the clauses end up using undefined words such as “confidential information”, which generate variation in interpretation at every translation and every audit. After classification come the inventory of routes by which data leaves the company, then what is checked at sign-off and the granularity of records, then logging and supervision. Once those four are settled, writing the clauses is transcription. To put it the other way round, obtaining a template first will not fill any of the four, because a template does not know what data your company handles or which routes your site uses.

Should we ban free generative AI outright

We do not recommend a blanket ban. For one thing, banning it does not stop it. The routes by which data leaves the company are not confined to a generative AI screen — translation sites, AI features in chat apps, browser extensions and meeting transcription apps all remain. For another, banning more than you can enforce degrades trust in the whole document. Block even the summarising of class L1 public information and the site concludes that the policy is detached from reality, at which point the other clauses stop being observed too. What should be prohibited is not a tool. It is moving class L3 or higher data by an unauthorised route.

Is translating the head office AI guideline into Thai enough for local rollout

It is not, and the issue is the drafting of the original rather than the quality of the translation. Translate a document written as a list of prohibitions and you get a list of prohibitions in Thai. The reader is left with what must not be done and no answer to what may be done for this task. On top of that, vague expressions such as “as necessary” and “appropriately” become unusable sentences once translated. The practical answer is a two-layer structure — the policy document stays authoritative in Japanese, and the site’s implementation standard is authoritative in Thai.

As a first step against leakage through generative AI, what should we shut off

Order the steps by ease and effect, not by size of risk. First, the model training use setting, since one switch changes the treatment of everything entered. Second, use of personal accounts for work, because until you move to company-administered accounts no logs remain in your hands. Third, browser extensions on work devices, since some configurations send whatever is on screen straight out and the user has no awareness of it. Fourth, the defaults for recording and transcription in meeting tools. All four are closed by settings rather than by the text of the policy.

On what criteria should we pick a secure generative AI environment

Do not start from cost. Fix the requirements first and compare costs among the candidates that meet them. Three requirements are enough. Can operating logs be retained for at least six months. Can training use be excluded contractually. Do the contract terms permit class L3 data. Any configuration failing those three drops out however cheap it is. Quiet tolerance of free services is eliminated first not because it is expensive but because there is no means of meeting the first requirement.

In closing — what the policy protects is routes and sign-off

This article makes only two claims. First, what a generative AI usage policy protects is not whether a tool may be used, but the routes by which data leaves the company and accountability for signing off on AI output before it is used in the business. Second, carrying a Japanese head office policy into a Thai site unchanged opens four gaps — jurisdiction, language, routes and accountability.

The remedies map one to one. Settle the four data classes first, design the outbound routes on a permit basis, decide what is checked at sign-off and how finely it is recorded, and put log retention and a named supervisor in place. Those four chapters correspond directly to the obligations Thailand’s draft AI Act would place on a deployer, so enactment would not force a rewrite. Thailand’s AI Act was not yet enacted as of 7 August 2026, while Vietnam’s AI Law is already in force, with transition deadlines for existing systems of 1 March 2027 and 1 September 2027 in healthcare, education and finance. The fact that jurisdictions differ is something the structure of the policy itself should carry.

We have deliberately not handed out model clauses, because the parts a template cannot fill are the parts that decide the outcome. Which data goes into class L4, which routes are authorised, who signs off. Those three differ from company to company. Settle them and clause writing is transcription; leave them unsettled and any template fills up with vague words. Cost decisions work the same way — decide on the three requirements, not on the size of the number. Reverse the order and you arrive at the familiar result where the configuration that looked cheapest turned out to be the one that could satisfy none of the obligations.

This article draws on the Teikoku Databank survey of corporate trends in generative AI from March 2026, the Ministry of Internal Affairs and Communications 2025 White Paper on Information and Communications, law firm analyses of the AI bill published by Thailand’s ETDA on 2 July 2026, and commentary on Vietnam’s AI Law No. 134/2025/QH15. The content of a draft can change before enactment, so check the current text when revising a policy.

Most of policy work is decided by the sorting that happens before any clause is written. Even at the stage where not a single page of a draft classification exists, we are happy to sit down with a list of the site’s actual tasks and start drawing the lines. If you would like to work through the structure of an implementation standard built for operation at a Thai site, or check the three requirements against the three environment options, get in touch through our contact page. If you already have a policy in place, we can start by identifying which of the four gaps are open.