AI Adoption Enablement 2026 – Three Gaps That Kill Usage After Training

Everyone has a licence. Two training sessions have been run. Three months later you look at what is actually happening and only a handful of people are using the tool, while the way the work gets done has not changed in any observable way. That is almost always the moment when AI adoption enablement comes up as an internal topic. If you respond by blaming the tool’s capability or the quality of the training, the next initiative will stall in exactly the same place. What is jammed is one specific thing. You are counting how many licences were handed out, and you are not counting how many pieces of work the tool has been built into. This article sets out the three gaps that stop adoption taking hold, the order in which to close them, and how to measure whether any of it worked.

Where AI adoption enablement becomes necessary

An internal generative AI rollout looks healthiest in its first three months. The contract is signed, accounts are issued, and the kick-off briefing is well attended. The metric reported upward is “100 percent adoption.” The trouble surfaces in the following quarter, when the executive team asks how many hours have actually come out of the business. Nobody can answer. And the reason nobody can answer is not that there was no effect. It is that no material was ever collected that would let anyone judge whether there was an effect.

What “adoption is up but nothing has changed” actually looks like

This condition has three clear symptoms. If even one of them describes your site, it is worth redesigning the enablement plan before doing anything else.

The first symptom is that usage clusters around the periphery of the work. Summarising meeting notes, drafting emails in English, tidying up the formatting of internal documents. All of these are genuinely useful, and every one of them is work where being wrong costs nobody anything. Put the other way round, the work where being wrong does cost something, first-pass quotations, root cause classification on defect reports, drafting technical answers to customers, is the work nobody reaches for. Usage staying at the periphery is not a failure of imagination on the floor. It is the visible result of the sign-off gap described later in this article.

The second symptom is that the same people use it and nobody else does. Of everyone who tried it in the first month, the ones still using it are the same faces, and the rest have not opened it since. What is happening here is not a difference in ability, it is a difference in the shape of the work. Someone who produces the same format of document every day can reuse a prompt, so it becomes a habit. Someone whose work is different every time has to write from scratch each time, the effort exceeds the return, and they drop out. That difference does not narrow by running more training sessions. It is decided by whether the prompt is fitted to the work rather than to the person.

The third symptom is that the benefit stops at individual time saved. You hear “a task that took 30 minutes now takes 10,” and yet the department’s workload plan, its deadlines and its staffing have not changed by one line. The 20 minutes an individual freed up either shaves a little off their overtime or gets absorbed into some other task and disappears. Because it never surfaces as an organisational number, from where the executive team sits it means the same thing as no effect at all. Closing this requires deciding, as a matter of work design, what the freed time gets redirected to, and that is not something training covers.

It is not that nobody uses it, it is that nobody measures it

What all three symptoms have in common is that none of them is detectable through the adoption rate. Adoption rate, meaning licences issued divided by headcount in scope, reaches 100 percent on the day the contract is signed. It is a number that tells you procurement is complete. It is not a number that tells you the work has changed. In capital equipment terms it is close to confusing the fact that a machine has been delivered to the plant with the fact that the machine is producing good parts.

What you need is the real usage rate. The definition is the share of people who used generative AI on the output of actual work at least once in the week. There are two conditions embedded in that. A frequency condition, at least once a week, and a purpose condition, used on the output of actual work. Having a play with it, or making it run during a training session, does not count. Drop either condition and the number becomes easy to make look high, and simultaneously loses all power to tell you whether an initiative worked.

When organisations start measuring the real usage rate, the first figure almost always comes out lower than anyone expected. That is not a failure. It is simply the first time the actual state of affairs has been visible. In fact, unless you agree with the executive team in advance that the number will look low, the month you begin measuring will be read as “this is not working” and the whole activity will be shut down. The switch from measuring rollout to measuring usage has to be made together with the explanation that the number will appear to drop once.

The other thing that matters is that the real usage rate becomes the only shared language you have for judging whether an initiative did anything. You added a training session, you distributed a template, you changed the permission design. Every one of those can be placed on the same ruler. Without the ruler, initiatives can only be described as done or not done, and nothing tells you what to do next. This structure maps directly onto the framework covered in which metrics to build an AI effect measurement around.

The three gaps that stop adoption

Take apart an organisation where the real usage rate refuses to climb and the blockage is almost always in three places. Metrics, sign-off, and write-back. These are not independent problems, they depend on each other from the top down. Without a metric you cannot begin designing sign-off, and until sign-off is settled there is nothing for write-back to act on.

Laid out side by side, each gap has a distinct answer to “what is missing” and “what happens on the floor.”

The point to hold on to in that table is that all three owners are different people. Commission AI adoption enablement as a job for the information systems function and only the first gap gets closed. The second and third require decisions from the departments that own the work, which means neither an external partner nor information systems can act on their behalf. Unless you place three separate owners on these three points when the project structure is set up, the programme will stall in its second half without fail.

Gap 1 the metric gap, distribution rate versus real usage rate

The distance between distribution rate and real usage rate is usually large. As described above, distribution rate hits 100 percent on the day of contract. The real usage rate, by contrast, stays permanently blank unless somebody starts measuring it. The value is not zero. The value does not exist.

What makes this gap awkward is that the absence of numbers itself looks like success. No bad figures come out, so the report says 100 percent adoption and the executive team understands the rollout to be complete. Only six months later, when results are requested, does it emerge that there is nothing to judge against. And by then there is no way to reconstruct retroactively what happened during those first three months.

Timing matters too. The real usage rate has to be defined before licences are handed out, or more precisely from the moment the target work is chosen. Start thinking about what to measure after distribution and, because the target work has not been fixed, you drift toward whatever is easy to collect, such as login counts. Login counts are measurable and they move independently of whether anything has been built into the work. What to measure can only be decided once you know what you want to change.

Gap 2 the sign-off gap, nobody owns the output

The second gap is the hardest to see from the floor and has the largest effect. It describes the state where nobody has decided who guarantees that generative AI output used in the business is correct.

Make it concrete. A quality assurance engineer produces the first draft of a defect report for a customer using generative AI. If that document contains an error, who carries it, the person who wrote it, the section manager who approved it, or the company that introduced the tool. If the organisation has no prepared answer to that question, the rational behaviour for the individual is not to use it. Not using it at least keeps the chain of responsibility where it has always been.

Plenty of internal policies handle this with a single sentence, “AI output must always be checked by a person.” In practical terms that sentence decides almost nothing. Who checks, what they check, where the record of the check is kept, what happens when part of the output cannot realistically be checked. Leave all of that undefined and write only “must always be checked,” and the floor ends up carrying the entire checking burden personally. The consequence is that usage stops in any work where the cost of checking exceeds the cost of doing it the old way. Usage skewing toward peripheral work where errors cost nothing is the result of exactly that calculation.

Designing sign-off means writing down, work by work, what has to be checked and to what depth before something counts as approved. For a first-pass quotation, for instance, cross-checking against the price master and recalculating quantities are mandatory, while the phrasing of the covering text needs no check. Only at that level of granularity can an individual calculate the scope of the responsibility they are taking on. In work where that scope is calculable, people use the tool. This work connects directly to permission design, so it is efficient to run it alongside the exercise of sorting out which job levels can reach which data. There is a practical treatment of the sequence in how to decide permission design and data boundaries for a Copilot rollout.

Gap 3 the write-back gap, nothing returns to standard work

The third gap opens after results have already been produced. Suppose someone reworks the procedure for producing the monthly report and brings a three-hour task down to one hour. Genuinely excellent. But the procedure is written down nowhere. It exists only in that person’s chat history and in their head.

If that person transfers, their successor goes back to the three-hour procedure. The time the organisation gained returns to zero. Worse, on the metrics the real usage rate looked high throughout the period that person was using the tool, so nobody notices the gain has evaporated. Six months later all that remains is the inexplicable impression that results used to be better.

Write-back means moving a success pattern found by an individual across into the standard operating procedure. Concretely, that means rewriting the relevant step in the work instruction, attaching the prompt used, and adding the items to be checked to a checklist. Until that happens, a generative AI rollout tops out at individual productivity and never connects to organisational productivity.

Write-back takes effort. Revising SOPs for 20 pieces of work is itself a task on the scale of several hundred hours. Which is precisely why that effort has to be in the budget from the beginning. The reason the cost estimate later in this article puts THB 320,000 on Layer 4 is that trying to do this work in somebody’s spare capacity guarantees it will be left unfinished. Write-back is not something done with slack. It is something scheduled as a work package.

What the 2026 data says about rolling out generative AI internally

Now check how this structure lines up against actual figures. Every number below comes from published research, and the sources are listed at the end of this article.

The Japanese numbers, 34.5 percent in use, the gap by company size, and the ranking of concerns

According to a survey Teikoku Databank conducted from 17 to 31 March 2026 with 10,312 valid responses, 34.5 percent of Japanese companies use generative AI in their operations. The variation by company size is substantial.

Reading this distribution as “bigger companies are further ahead” is only half right. If the figure for companies with more than 1,000 employees is 63.6 percent, then more than one in three sizeable companies still does not use it in their operations. And from this article’s point of view the important detail is that “uses it” is a yes or no answer at company level, not a real usage rate. A company of 1,000 people where 10 people use it counts as a company that uses it. So what the 34.5 percent figure actually describes is not how far internal rollout has progressed, it is whether anyone has started.

The ranking of concerns in the same survey lines up almost one to one with the three gaps.

The top concern, accuracy of information at 50.4 percent, is the sign-off gap in plain sight. What sits underneath a worry about accuracy is anxiety about the fact that nobody has decided who carries it when something is wrong. Third place, which work it should be applied to at 40.0 percent, means the work inventory has not been done, which corresponds to Layer 1 of the five implementation layers below. And the 18.8 percent who cited widening gaps in how well people use it are describing a phenomenon that occurs inevitably in an organisation that does no write-back. If individual gains stay with individuals, the spread only widens over time.

The people struggling are not the shop floor, they are section managers and team leaders

There is one further figure that changes the design of an internal rollout from the ground up. In a January 2026 survey of 1,008 managers at Japanese companies, conducted by Kore Inc. and reported by CommercePick, the group most often named as unable to use generative AI effectively was section managers and team leaders, at 29.3 percent. Executives followed at 26.8 percent and general staff at 25.6 percent.

The point worth noticing is that general staff come last. Most Japanese rollout plans are built on an unspoken assumption that the shop floor cannot use it and therefore has to be taught. What this figure shows is that the tightest blockage is in middle management. And that is very likely a question of role rather than of ability. Section managers and team leaders produce comparatively few documents themselves and spend their time on the checking side of their subordinates’ output. In other words they sit on the sign-off side of generative AI, not the using side. And yet training content is exhausted by explaining how to use the tool and teaches nothing about how to sign off on its output.

When this layer jams, the whole rollout stops. A subordinate produces a document using generative AI, the section manager cannot check it because they do not know what to look at, and approval takes longer. The net effect is a perverse incentive in which the more a subordinate uses generative AI, the slower their approvals become. Concentrating training on general staff does nothing to improve that structure.

In the same survey the leading obstacle to adoption was security concerns at 33.5 percent, followed by an inability to generate concrete ideas for where to apply it at 26.0 percent, and a lack of understanding and cooperation from the information systems function at 22.4 percent. Second place, no ideas, is the consequence of leaving the work inventory to individual inspiration. Decomposing daily work and listing candidates is not something a busy individual thinks up on the side. It goes faster when it is driven from outside with a defined procedure. Third place, friction with information systems, appears without fail in any organisation that deferred the permission design conversation.

The reversal the global research shows, employees are already using it

Here is a piece of research that inverts the premise. Human Driven AI ran a three-year enterprise AI study covering 22 companies and 2,724 people, including 594 interviews with executives, and reported that 85 percent of professionals already use AI in their work. The study’s conclusion is that AI adoption itself is no longer the challenge, and that the challenge sits on the side of organisational adaptation.

That picture conflicts head-on with the premise a Japanese head office tends to hold. Most rollout plans begin from the problem statement that employees will not use it, and the countermeasures line up as training and awareness campaigns. But if the reality is that people already use it and the organisation has not caught up, then what is required is not training. It is rewriting work definitions, setting sign-off criteria, revising standard work. Organisational work, in other words.

Get the problem statement wrong and the entire direction of the money is wrong with it. Budget was approved to train employees, and no budget was approved to revise SOPs, is precisely that condition. Commissioning adoption enablement as “education” tends to produce exactly that shape. Adoption enablement is not education, it is work redesign, and its deliverable is not an attendance list, it is a set of revised SOPs. Draw that line at the outset and both the content of the quotation and the acceptance criteria become concrete. The question of which layer belongs to whom is also covered in who owns which layer in AI insourcing support.

What changes at a Thai or ASEAN site

Everything so far is country-agnostic structure. At sites in Thailand and elsewhere in ASEAN, several of those premises run the other way. Carry the head office’s assumptions across unchanged and your initiatives will point in the opposite direction to reality, so this section is worth reading carefully.

Laying out the Thailand data from the Microsoft Work Trend Index 2026 shows how far forward Thai workers are leaning on AI.

The core of this section is that the top four rows and the bottom two rows of that table point in opposite directions.

Thai workers lean into AI, Frontier Professionals at 32 percent

What the top four rows tell you is that in Thailand, initiatives designed to get people to use AI are largely unnecessary. Frontier Professionals, meaning people who work with AI at the centre of their job, make up 32 percent, twice the global average of 16 percent. The share who use AI output as the starting point for their work reaches 89 percent, and 85 percent feel they would be left behind without AI, well above the global 65 percent. The share who say leadership has set a clear AI direction is 51 percent, roughly double the global 26 percent. On top of that, one in three Thai executives credits experimentation with AI even when it produces no result.

The external environment points the same way. In the UOB Business Outlook Study 2026, covering Thai SMEs with n=265 in the first half of 2026, more than 70 percent of SMEs have adopted AI, with 58 percent reporting realised cost savings and 44 percent reporting realised productivity gains. Research reported by the Bangkok Post and SME Asia found the share of Thai firms making consistent use of AI rose from 32 percent a year earlier to 43 percent, with digital maturity climbing from 1.56 to 2.12 on a four-point scale.

Which means that opening a Thai rollout with a training session explaining why generative AI is useful spends most of its time on material the audience already knows. That is not just an inefficient use of time, it earns the head office a reputation on the floor for not looking at local conditions. This is the point Japanese head offices get wrong most often.

Quality control and critical thinking rank low

The bottom two rows of the table say something else entirely. The share of Thai workers who consider quality control of AI output important is 53 percent, 5th of 6 Southeast Asian countries. The share who consider critical thinking important is 45 percent, the lowest in the region.

A workforce that leans forward while placing low weight on quality control has a very clear risk shape. While 89 percent use output as a starting point, only 53 percent, roughly half, regard quality control as important. For both of those figures to hold simultaneously over the same population means that a certain volume of output flows into the next step of the process unchecked. In manufacturing back-office terms that means specification translations, technical answers to customers, provisional causes on defect reports, transcription of bills of material. Every one of those is work where an error is expensive downstream.

So at a Thai site the sequence of an adoption enablement programme reverses relative to Japan. In Japan the usual construction is to put usage-promoting initiatives first and add the checking mechanism afterwards. In Thailand you put sign-off first. Concretely, you build the per-work check items and checklists before the hands-on sessions, not after. Usage has already started, so getting ahead of it with discipline creates less rework than chasing it with discipline later.

That reordering shows up in the cost allocation as well. A domestic Japanese rollout tends to weight training heavily, whereas a Thai site is better matched by weighting Layer 2, usage policy and permission design, and Layer 4, write-back into standard work. The reason Layer 4 is the largest line at THB 320,000 in the estimate below is exactly this judgement.

What Japanese head offices get wrong about AI education for local staff

When a Japanese head office designs AI education for a Thai site, there are three assumptions it is easy to get wrong.

The first is the assumption that literacy is low. As the figures above show, at least in terms of appetite and frequency of use, Thai workers are ahead of their Japanese counterparts. Starting with introductory material wastes the participants’ time.

The second is the assumption that delivering training in Japanese is sufficient. Even at a Japanese-affiliated site, the people running the back office day to day are Thai staff, and Japanese speakers are a subset. Run the training in Japanese only and it does not reach the people who actually use AI in their work. That is why the estimate below builds Layer 3 in two languages, Japanese and Thai. In addition, unless deliverables such as work instructions and checklists are also prepared in both languages, write-back ends up confined to the Japanese expatriate population.

The third is the assumption that education is a one-off event. Run the training, collect the feedback forms, issue a report, done. In that shape nobody follows whether the real usage rate actually moved. As described above, what is needed is an operating routine that looks at numbers monthly and adjusts, and a single training event cannot substitute for it. The design thinking for training aimed specifically at manufacturing is set out in how to construct generative AI training for manufacturing.

The five layers of AI adoption enablement

From here on the discussion is about implementation. Splitting adoption enablement into five layers makes gaps and ownership easy to spot. For each layer, here is what has to be decided and what happens if it is not.

The difficult layers among the five are Layer 2 and Layer 4. Layers 1 and 3 progress fine once the procedure is settled, but Layers 2 and 4 involve decisions by the departments that own the work, so neither an external partner nor information systems can carry them.

In Layer 1, the work inventory, narrowing the scope matters more than anything. Cover every process and the inventory alone takes several months, during which the floor loses interest. Practically, selecting around 20 pieces of work from the back office is a manageable size. Prioritise work that satisfies three criteria, high frequency, standard output format, and errors detectable immediately, and exclude from the first round work that is infrequent, different every time, or where errors only surface far downstream. The deliverable of the inventory should not be a list of work names. It should be a table that carries, for each piece of work, the current hours per month and who those hours belong to. Without the hours you cannot measure effect at Layer 5.

In Layer 2, usage policy and permission design, the sign-off design described earlier lives here. What the policy has to contain is not only prohibitions. What matters more is explicit permissions, statements in the affirmative of the form “for this range of this work, you may use it provided you perform this check.” A policy consisting only of prohibitions leaves the treatment of everything unwritten ambiguous, and in the end acts as a brake on usage. On top of that, unless you decide the boundary of what may be entered, whether customer names are permitted, whether drawings are, whether costs are, work by work, the judgement varies from person to person.

Layer 3, the hands-on session, has one principle to protect. Do not use sample data. Participants bring the actual files from the work they will do tomorrow and run the tool on those. Training run on samples scores well on satisfaction and is not reproduced the following week. Work that ran once on the participant’s own data has a high probability of running again next week. The deliverable of training is not a record of attendance, it is a working prompt and a procedure note that the participant takes away. Define the takeaway in advance and the design of the session moves toward real work automatically.

Layer 4, write-back, is scheduled as a work package, as described earlier. Take 20 pieces of work as the scope for SOP revision and place approval of revisions with the head of the owning department. Two details need deciding here. Where prompts are stored, which should be a shared location linkable from the work instruction rather than someone’s personal notes, and what the revision cycle is, for which a mandatory review three months after the first revision works well. Models get updated, so there is no guarantee that a prompt written at the start is still optimal six months later. Unless the review cycle is written into the policy, SOPs freeze around ageing prompts.

Layer 5, ongoing support and monthly review, is the least glamorous part of the implementation and the most effective. Once a month, produce the real usage rate and the three metrics described below, identify one cause for any department where the number has fallen, and decide one action. That is all. What matters is that the head of the owning department attends the review. Held by information systems and the programme office alone, it becomes a status report rather than a decision-making forum. A review that decides nothing quietly disappears by its third occurrence.

How to measure the real usage rate

Running Layer 5 requires numbers to look at. This section decides what to measure and what not to measure.

The first thing to do in designing measurement is to abandon the instinct to measure whatever is available. The easier a number is to pull from a log, the further it usually sits from the reality of the work.

Metrics worth measuring and metrics to avoid

Split metrics into two groups. Metrics that move in step with changes in the work, and metrics that move whether or not the work changed.

The reason the second group is listed explicitly is that these metrics appear constantly in real reports. Attendance and satisfaction in particular produce conveniently high numbers for whoever ran the initiative, so they get placed at the centre of the reporting. But attendance of 100 percent and a perfect satisfaction score are entirely compatible with a real usage rate of 0 percent. As long as a metric is a tool for judging whether an initiative worked, a metric that moves conveniently for the people running the initiative must not be the headline metric.

Total messages sent deserves a further note. The figure appears to indicate heavy use, but people who are not using the tool well rephrase the same question repeatedly, so it can move inversely with proficiency. If you are going to track volume at all, watching whether the number of exchanges per piece of work is falling over time is a far more meaningful proficiency signal.

The three headline numbers, weekly active rate, workflow embedding rate, write-back rate

Keep the headline metrics to three. Go beyond three and the monthly review cannot cover them all, and in practice only the most easily obtained number gets read out.

The first is the weekly active rate. The definition is the share of people who used generative AI on the output of actual work at least once in the week. Determining the numerator by self-declaration is acceptable, provided the declaration is accompanied by the name of the work. A declaration where the work cannot be named is quite likely not use in real work. As a rule of thumb, if this value drops below 50 percent in a month for a department holding target work selected in Layer 1, that department becomes a subject for cause analysis.

The second is the workflow embedding rate. The definition is the share of the target work selected in Layer 1 where use of generative AI is defined in the SOP. The denominator is fixed, at 20 pieces of work for example, so progress reads linearly. If this metric is flat while the weekly active rate climbs, it means individual ingenuity is accumulating and nothing has been fixed at organisational level. It reverts the moment somebody transfers.

The third is the write-back rate. The definition is the share of effective usage patterns found on the floor that have been reflected into an SOP or into the prompt library. The denominator is hard to establish rigorously, so in practice the workable approach is to use the count of improvements reported at the monthly review as the denominator. Continuity matters more than rigour here. What matters is confirming every month that there is a route by which improvements get reported and that somebody exists whose job is to write them back.

These three map one to one onto the three gaps. The weekly active rate makes the metric gap visible, the workflow embedding rate makes the sign-off gap visible, because defining something in an SOP requires the sign-off criteria to have been settled, and the write-back rate makes the write-back gap visible. Which of the three is lowest tells you which layer to work on next.

Cost and payback for a Thai site with 80 indirect staff

On to money. What follows is an estimate for a Thai site covering 80 indirect staff with a 12-month adoption enablement programme. The underlying assumptions vary enormously between plants, so these amounts cannot be applied to your own site unchanged. The hourly rate and the hours saved per person in particular are variables to substitute, and what follows should be read as a framework showing the order of the calculation.

Start with the assumptions.

The 256 THB hourly rate is the average labour cost divided by annual working hours. When you recalculate it for your own site, use total labour cost including social security, statutory benefits and bonuses. Calculate from base salary alone and the rate comes out too low, which makes the benefit look smaller than it is.

Next, build up the cost of the enablement programme along the five implementation layers.

What stands out in that breakdown is that the largest item is not training at THB 240,000, it is write-back at THB 320,000. In a typical “AI training” quotation, Layer 4 is missing in its entirety. A proposal still holds together without it, but as described above the structure that keeps gains inside individuals remains intact. When comparing quotations, checking whether the SOP revision effort is included matters more than comparing headline totals.

Now the benefit side. Below, three scenarios are compared on the basis of different real usage rates. The hours saved per person are placeholder values and need substituting to match your own mix of work.

Scenario A is what happens when you hand out licences and stop there. Put the real usage rate at 25 percent. That means 80 × 0.25 = 20 people actually using it. Assume a saving of 2.0 hours per person per week and the annual saving is 20 × 2.0 × 52 = 2,080 hours per year. In money that is 2,080 × 256 = 532,480 THB per year of benefit. Against that, the cost is licences alone at 1,008,000 THB per year. The net is 532,480 − 1,008,000 = −475,520 THB per year, a loss that repeats every year. In this structure the concept of payback does not apply at all, because it never pays back.

Scenario B is what happens when enablement lifts the real usage rate to 70 percent. That means 80 × 0.70 = 56 people actually using it. Assuming greater proficiency, put the saving at 2.5 hours per person per week and the annual saving is 56 × 2.5 × 52 = 7,280 hours per year, worth 7,280 × 256 = 1,863,680 THB per year. First-year cost is licences of 1,008,000 plus enablement of 1,130,000, giving 2,138,000 THB, so the first-year net is 1,863,680 − 2,138,000 = −274,320 THB, a loss. In year two the cost is licences of 1,008,000 plus ongoing support only of 240,000, giving 1,248,000 THB, and the net turns positive at 1,863,680 − 1,248,000 = +615,680 THB per year. Cumulative break-even lands at 12 + 274,320 ÷ (615,680 ÷ 12) = 12 + 5.3, or roughly 17 months.

And the contrast scenario is the crux of this section. Run the same arithmetic for the case where enablement is purchased and the real usage rate nevertheless stalls at 50 percent. That is 80 × 0.50 = 40 people using it. 40 × 2.5 × 52 = 5,200 hours per year, worth 5,200 × 256 = 1,331,200 THB per year. The first year is 1,331,200 − 2,138,000 = −806,800 THB. From year two onward only 1,331,200 − 1,248,000 = +83,200 THB per year remains. Cumulative break-even is 12 + 806,800 ÷ (83,200 ÷ 12) = 12 + 116, or roughly 128 months, about ten and a half years. Given the pace at which systems become obsolete and organisations reshuffle, that is a level at which you should conclude the investment does not pay back at all.

Setting the three scenarios side by side makes the branching variable obvious.

The only difference between Scenario B and the contrast scenario is the real usage rate. Same tool, same licence cost, the same THB 1,130,000 paid for support. And still the payback period splits between 17 months and 128 months. Which means the question to ask in the investment decision is not which tool to buy, it is what kind of organisation you are, measured by how high a real usage rate you can reach. And the difference between 25 percent and 70 percent is not a difference in model capability, it is the difference between having closed the three gaps of metrics, sign-off and write-back and not having closed them.

If you are not confident that you can run Layers 2 and 4, the alternative is not “do not invest,” it is “start with a narrower scope.” Rather than putting 80 people in scope at once, begin with one department of around 20 people and narrow the work to five to seven processes. At that size the support cost falls proportionally and you can confirm within a few months whether the real usage rate reaches 70 percent. For an investment whose payback is this sensitive, verifying reproducibility before scaling up is the rational sequence.

What to do in the first 90 days

Build the 90 days on the assumption that you do not go company-wide. The objective is not to produce a result, it is to establish whether Layers 2 and 4 can turn in your organisation.

Spend the first 30 days aligning definitions. Narrow to one department, narrow the work to five to seven processes, and measure the current hours for each. In parallel, document the definition of the real usage rate. Settle both the definition, used on the output of actual work at least once a week, and the method of determination, whether by self-declaration, by log, or by requiring the name of the work. No additional licences need buying in these 30 days. Existing accounts are enough.

Use the next 30 days for Layer 2. For each piece of target work, write out the boundary of what may be entered and the items to check on the output. The deliverable here is not policy text, it is a one-page checklist per process. Policies do not get read, checklists get used. At the same time, name the sign-off owner for each process by individual name. Naming individuals rather than job titles matters, and any process for which no name can be entered is better dropped from scope at that point. Work with no owner will not get used regardless.

Use the last 30 days for Layers 3 and 4. Run one hands-on session in which participants work with their own real data. Two weeks later, pick two or three processes where usage has actually continued and rewrite the relevant SOP steps. Put the prompts in a shared location and link them from the work instruction. If even one process gets that far, you have confirmed that the write-back step can turn inside your organisation. If none did, work out why before doing anything else, because widening the scope to 80 people will reproduce the same outcome.

At the end of the 90 days there is one number to look at. The count of target processes whose SOP has been revised. Not training attendance, not satisfaction. If the count of revised SOPs is zero, do not expand.

Frequently asked questions

What does AI adoption enablement actually involve?

It means working through all five layers, work inventory, usage policy and permission design, hands-on with real work, write-back into standard work, and ongoing support with monthly review. Training is one of those five layers. The deliverables are not an attendance list, they are revised standard operating procedures, per-process check items, and the trend data for the real usage rate. Defining the deliverables in that form at the point of commissioning makes the acceptance criteria unambiguous.

Why does generative AI fail to take hold?

It comes down to the three gaps described above. The real usage rate is not measured, so no initiative can be judged. Nobody owns the AI output, so using the tool means carrying risk personally. Success patterns are not written back into standard work, so gains stay with individuals. Cases where the cause genuinely is tool capability or training quality are rare in practice. The fact that the leading concern in the Teikoku Databank survey was accuracy of information at 50.4 percent shows that this problem surfaces as a lack of sign-off design.

How much does adoption enablement cost?

The estimate in this article shows a breakdown totalling THB 1,130,000 for a Thai site with 80 back-office staff over 12 months. Generative AI licences of THB 1,008,000 per year sit on top of that. But those figures depend on scale and on the number of target processes, 20 in this case, so narrowing scope to one department of 20 people and five processes brings the cost down considerably. When comparing quotations, the practical check is whether the Layer 4 SOP revision effort is included rather than which total is lowest. A quotation missing that layer looks cheaper and leaves the structure that keeps gains inside individuals intact.

Is training on its own not enough?

No. Training is Layer 3 of the five. Without Layer 1, the work inventory, there is no material for the session to work on. Without Layer 2, sign-off, participants cannot use what they learned the following week. Without Layer 4, write-back, the gains stay with individuals. This structure is why training can score highly on satisfaction while the real usage rate three months later has not moved. Read the other way, once Layers 1 and 2 are done, the training itself is often short.

How should we teach Thai local staff?

Do not start with introductory material. According to the Microsoft Work Trend Index 2026, 32 percent of Thai workers are Frontier Professionals, twice the global average of 16 percent, and 89 percent use AI output as a starting point. There is a high probability that instructions on how to use the tool are already known. On the other hand, the share who consider quality control of AI output important is 53 percent, 5th of 6 Southeast Asian countries, and the share who consider critical thinking important is 45 percent, the lowest in the region. So the emphasis belongs not on usage but on per-process check items and the sign-off procedure. Prepare materials and checklists in both Japanese and Thai so that write-back does not end up confined to the Japanese expatriate population.

Summary

Generative AI stops being used for reasons that have nothing to do with tool capability or training quality. The cause is that the metric being tracked is how many licences were handed out, not how many pieces of work the tool has been built into. Three gaps derive from that. The metric gap, where the real usage rate is not measured so no initiative can be judged. The sign-off gap, where nobody owns the AI output so the floor stops using it voluntarily. And the write-back gap, where success patterns never reach standard work so gains disappear along with the individual.

And what a three-year enterprise study of 22 companies and 2,724 people showed is that 85 percent of professionals already use AI. The problem is not that employees will not use it, it is that the organisation has not adapted to the employees who already do. Which means adoption enablement is not the work of training employees, it is the work of rebuilding work definitions, sign-off criteria and standard work on the organisation’s side. At a Thai site the picture is sharper still. Against a forward-leaning workforce with Frontier Professionals at 32 percent and 89 percent using output as a starting point, the share treating quality control as important is 53 percent and critical thinking 45 percent, the lowest in the region. Initiatives to make people use it are unnecessary. Putting the mechanism that makes them sign off in place first is the correct order.

The essence of the investment decision sits in the same place. In the estimate above, the same THB 1,130,000 of support cost pays back in roughly 17 months if the real usage rate reaches 70 percent, and takes roughly 128 months, which is to say it does not pay back, if it stalls at 50 percent. What determines the branch is not model capability, it is whether the three gaps were closed. Settle three things internally before you request licence quotations, how the real usage rate will be measured, who signs off on the output, and who revises the SOPs, and every conversation after that becomes far more concrete.

TOMAS TECH works with Japanese-affiliated manufacturers in Thailand and across ASEAN on generative AI adoption enablement, covering work inventory, usage policy and permission design, hands-on sessions with real work, write-back into standard work, and monthly ongoing support. We are glad to help at the early stage of sorting things out, questions such as how to define your own real usage rate or which processes to build sign-off criteria for first. Please use us as material for your evaluation and get in touch through our contact page.

References

• Microsoft unveils 2026 AI work trends for Thailand – Microsoft Source Asia
• Microsoft Work Trend Index, AI usage trends among Thai workers – The Story Thailand
• Corporate survey on generative AI usage, March 2026, 10,312 valid responses – Teikoku Databank
• Survey of 1,008 managers on the reality of generative AI usage – Kore Inc., reported by CommercePick
• Three-Year Enterprise AI Study – AI Adoption Is No Longer the Challenge, Organizational Adaptation Is
• UOB Business Outlook Study 2026, AI adoption among Thai SMEs – ThaiPR
• AI adoption helps Thai firms become digitally mature – Bangkok Post
• Thailand’s AI use surges to 43% but most firms still struggle in adoption – SME Asia